Ingress overview

Gateway uses managed nginx nodes as public ingress. A complete public service combines a Domain, certificate, Route, upstream, health policy, and node placement.

Routes can proxy, redirect, or return 404. Proxy upstreams may be manual addresses, standalone containers, Deployments, Compose services, or ready Pages Tags. Additional Routes attach literal path prefixes such as /api to separate upstreams.

Use managed nginx mode when Gateway should own a known-good base configuration. Use integrate mode when an existing nginx installation must retain its base config and load Gateway-managed includes.

Operationally, verify DNS, certificate distribution, generated config validation, Route health, and public behavior after every placement or TLS change. A configuration is not complete merely because it saved successfully.

Resource ownership

Ingress resources have separate lifecycles even when they appear as one public application:

• a Domain owns the hostname and nginx placement;
• an SSL Certificate owns certificate material and renewal state;
• a Route owns request behavior, health policy, and its primary upstream;
• an Additional Route owns one literal path-prefix override;
• an Access List is reusable policy that can be attached to more than one Route;
• a Route-owned Secure Link follows the Route and cannot be removed independently.

Deleting one resource must not silently delete another reusable resource. Before deletion, inspect linked resources and decide whether the intended action is disable, maintenance, detach, migrate, or permanent removal.

Recommended creation order

1. Enroll and validate the target Ingress node.
2. Register the Domain and confirm its intended placement.
3. Issue or upload the TLS certificate.
4. Create the Route and select its upstream.
5. Add access policy, headers, WebSockets, rewrites, or timeout overrides only when required.
6. Enable the Route and wait for nginx configuration validation.
7. Test HTTP and HTTPS from an external client.
8. Confirm health history, access logs, and certificate distribution.

Safe operating rules

• Keep one canonical owner for every hostname; do not create competing Routes for the same host outside Gateway.
• Treat raw nginx configuration as an expert escape hatch. It disables some managed validation and lifecycle features.
• Do not publish a private workload port merely because a Secure Link is temporarily unhealthy.
• Use maintenance mode for deliberate customer-visible work and disable a Route only when traffic should stop entirely.
• Migrate placement through the explicit workflow so Domains, Routes, certificates, health state, and DNS changes remain coordinated.

Gateway and operator responsibilities

Gateway validates and distributes the nginx configuration, tracks the desired placement, manages supported certificate workflows, and records the operations that change public traffic. It does not control an external DNS provider unless a configured integration owns that zone, open an upstream firewall, or make an unhealthy application ready. Those dependencies remain operator responsibilities.

This distinction matters during incidents. A healthy Ingress Node proves that the daemon and nginx are available; it does not prove that public DNS points to that node, that every Route has a reachable upstream, or that an external network permits traffic. Conversely, a failed application health check does not require rebuilding the nginx host. Diagnose the resource chain from the public hostname toward the application and change only the failed layer.

For production ownership, record who may change DNS, certificates, Routes, Access Lists, and application releases. Keep emergency access to Gateway independent of the application hostname being operated. Review shared certificates and Access Lists before changing them because a single edit can affect several Routes.

Production acceptance

Before declaring a hostname ready, verify it from a network outside the managed hosts. Confirm DNS answers, HTTP redirect behavior, the HTTPS certificate chain and hostname, the expected application response, and WebSocket behavior when used. Then compare that request with Gateway health history and nginx access logs.

Keep the previous DNS placement or application revision available during a cutover when practical. If acceptance fails, restore the known-good upstream or placement rather than deleting the new resources. Deletion removes useful desired-state and operation history and is rarely the safest rollback.

Continue with Domains, Routes, and TLS for configuration, Secure upstreams for private Docker targets, and Ingress troubleshooting for failure diagnosis.