Prepare a Web Host for deployment

Configure the listener and limits, then separate Lenso Ingress guarantees from Host-owned TLS, packaging, and topology.

Lenso Web provides a production-oriented HTTP boundary, not a universal deploy command. The application Host still owns the executable or container, TLS termination, process manager, environment, rollout, and network topology.

Start from a private listener

The default Ingress address is loopback with an ephemeral port, which is useful for tests and embedding. Choose a fixed address explicitly for a deployed Host:

bind_address = "127.0.0.1:8080"
max_request_body_bytes = 1048576
max_request_head_bytes = 16384
max_concurrent_requests = 128
request_timeout_millis = 30000

Use 127.0.0.1 behind a same-host reverse proxy. Bind 0.0.0.0 only when the Host’s network policy intentionally exposes the listener. A public bind is valid configuration; it is not proof that firewall, tenancy, or TLS policy is correct.

Put TLS and topology in the Host environment

The maintained Ingress serves HTTP/1.1 and cleartext HTTP/2 prior knowledge. It does not currently terminate TLS. A reverse proxy, load balancer, service mesh, or embedding Host should own certificates and the external HTTPS listener.

Internet -> HTTPS proxy/load balancer -> cleartext private Ingress -> Endpoint Plugins

Deployment policy also decides replicas and external load balancing. In one multi-lane App, Ingress coordinates one bound socket and dispatches only to ready replicas; do not make every lane bind the same port independently.

Know what readiness proves

Before the App Ready Gate opens, Ingress gathers the immutable route tables from its explicitly bound Endpoint providers. Duplicate exact routes and semantic path-shape collisions fail startup. Configuration limits are also validated before serving.

Run the composition checks against the exact Plugin Root that will ship:

lenso plugins list --root ./my-app
lenso app show --root ./my-app
lenso app check --root ./my-app

These commands prove composition, not remote reachability. Lenso Web does not add a universal /health endpoint; the product Host must expose the health and readiness contract expected by its platform.

Preserve shutdown and request bounds

Ingress owns global concurrency admission, request body/head limits, one Endpoint deadline, disconnect cancellation, and cooperative App shutdown. A request that exceeds its configured limit fails at the transport boundary instead of reaching business code.

Your process manager should send the Host’s supported graceful-shutdown signal and allow enough time for its bounded request deadline. Do not kill and restart the listener as a route-registration mechanism: route changes enter through a new ready Generation.

Deployment checklist

• The shipped Host Catalog contains only the intended Endpoint providers and bindings.
• lenso app check passes with production Plugin configuration.
• Public exposure, TLS, forwarded-header policy, and firewall rules are owned and tested by the deployment environment.
• Auth and Secrets are explicit bindings; no credential is embedded in Ingress configuration.
• Body, head, concurrency, and timeout limits match the real workload.
• Real-socket tests cover success, overload, timeout, cancellation, route collision, and graceful shutdown.
• The rollout platform has a product-owned health/readiness endpoint and a rollback path.

There is currently no framework-owned Dockerfile, Kubernetes chart, or generic lenso deploy workflow. Add those artifacts in the product repository where the actual Host, registry, secrets, and topology are known.