Domains, Routes, and TLS

For managed Cloudflare DNS, configure the Cloudflare integration before selecting zones and creating Domain records. A DNS connector does not replace the ingress node or its TLS configuration.

This resource chain turns an application into a stable public endpoint. A Domain represents the hostname and where it is served, a Route defines what Gateway does with matching requests, and a TLS certificate proves the hostname to HTTPS clients. The intended outcome is one accountable owner for the hostname, encrypted traffic, an explicit upstream, and a verifiable rollback path.

Before implementation, decide who owns DNS, certificate renewal, application health, and production cutover. Gateway can coordinate these resources and supported provider actions, but external DNS and application readiness remain outside its control unless an integration explicitly manages them.

Success means the canonical hostname resolves to the intended Ingress Node, HTTPS presents the expected certificate, the Route reaches the intended application, and both Gateway health and an independent external request agree.

Domains

Register each hostname once and assign it to an eligible nginx node with a detected public service address. A Route and its Domain must remain on the same node. Cloudflare-managed Domains can reconcile A/AAAA records; external DNS remains the operator’s responsibility.

Certificates

Issue Let’s Encrypt certificates through HTTP-01 or DNS-01, or upload existing material. HTTP-01 requires the assigned node to be publicly reachable on port 80. Gateway distributes private key material only to nodes with enabled TLS Routes that use it.

Routes

Choose the Domain, behavior, upstream, TLS certificate, and health policy. Enable WebSockets, rewrites, headers, buffering, or timeout changes only when required by the application.

Migration

Use the explicit ingress migration workflow to move a Domain and its Routes. Cloudflare DNS can be changed during cutover; external DNS requires an operator-confirmed update. Verify the target before removing the source placement.

Prerequisites and permissions

The target Ingress node must be online, report a usable service address, and support the intended certificate challenge. The caller needs access to the Domain, Route, certificate, target workload, and any reusable Access List involved in the change.

For externally managed DNS, lower TTL before a planned migration and record the current records. For Cloudflare-managed DNS, verify the connector scope and zone allowlist before asking Gateway to mutate records.

Configure the complete chain

1. Create or select the Domain and place it on an Ingress node.
2. Confirm DNS points to the selected public service address.
3. Issue or upload a certificate covering the exact hostname.
4. Create the Route and select proxy, redirect, or 404 behavior.
5. Select the upstream and application protocol.
6. Attach TLS, access policy, health checks, and protocol options.
7. Save and wait for nginx validation and apply.
8. Verify the public endpoint from outside the managed network.

For wildcard or multi-name certificates, verify every hostname before reuse. Certificate existence alone does not mean it is distributed; distribution follows enabled TLS Route placement.

Change and deletion consequences

• Moving a Domain changes where all of its Routes are served.
• Replacing a certificate affects every attached TLS Route after distribution.
• Disabling a Route preserves configuration but stops the managed virtual host.
• Deleting a Route retires Route-owned Secure Links but does not delete reusable certificates or Access Lists.
• Deleting a Domain requires its dependent Routes to be removed or migrated first.
• Deleting an uploaded certificate removes Gateway’s managed copy only after dependencies are detached.

Verification checklist

• External DNS resolves to the intended node.
• HTTP behavior is deliberate: redirect, response, or disabled.
• HTTPS serves the expected certificate and complete chain.
• Health checks use the intended path and expected status.
• WebSocket and timeout settings match the application.
• nginx configuration is valid and the latest revision is acknowledged.
• Access and error logs show the external verification request.

Renewal and placement changes

Certificate renewal and Domain migration are separate operations. A renewed certificate must be issued successfully, stored by Gateway, distributed to every eligible Ingress Node that serves an attached TLS Route, and acknowledged by nginx. Check the new validity period and the certificate served externally; a successful issuance record alone is not the final verification.

For placement changes, prepare the target Node before changing DNS. Confirm nginx capability, public service addresses, certificate availability, Route configuration, upstream reachability, and health checks on the target. When DNS is external, change the records only after the target is ready and keep the source available for at least the expected TTL and cache window. When Gateway manages Cloudflare DNS, still verify the resulting public answers rather than assuming that the provider operation completed everywhere immediately.

Failure and rollback boundaries

If configuration validation fails, the invalid revision must not replace the last acknowledged nginx configuration. Read the validation error, correct the smallest relevant setting, and apply again. Do not detach a working certificate or move the Domain merely to bypass a syntax or upstream-selection error.

If a migration fails before DNS cutover, keep traffic on the source and repair the target. If external DNS was already changed, restore the recorded source records or complete the target repair according to the incident decision; avoid alternating records repeatedly because recursive resolvers may observe different states. After rollback, verify both public address resolution and the certificate actually served by the source.

Gateway cannot roll back application writes or external DNS changes that occurred outside its managed workflow. Preserve the previous DNS values, certificate assignment, and application revision as part of the change record.