How a request reaches your application: DNS, the edge node and HTTPS

A public request reaches your web application through the Edge node of its cluster. DNS gives the browser its address. A small proxy, the front, passes the connection to the edge router. The router handles HTTPS, then sends the request to a replica.

Tenkai obtains and renews certificates through Let's Encrypt. You do not install certificates or configure a reverse proxy. For a custom domain, you still need to point DNS at the edge node.

DNS points to the edge node

Each web application gets a default route, such as api-k7m4p9.apps.tenkai.cloud. When Tenkai creates the default route, it queues publication of a DNS A record pointing to the edge node's public IPv4 address. The record uses DNS only, without a provider proxy. It asks DNS resolvers to cache it for 60 seconds. This is its time to live, or TTL. Publication can take time or fail. Tenkai waits for confirmation before routing the default route.

A custom domain points to the same address. Prefer a CNAME to the default route so it follows a change of edge node. Its DNS check passes only when it resolves to the edge node's IPv4 address and no IPv6 address. Turn off any DNS provider proxy.

The edge node takes every request

The edge node is the manager node that receives public web traffic on TCP ports 80 and 443. Other nodes do not normally listen on these ports, but their firewalls allow them, along with SSH.

HAProxy, the front, holds both ports. It forwards connections to the edge router with the visitor's address in a PROXY protocol header.

Why use a front? The edge router joins each environment network it routes. Changing these networks replaces its task. The front stays on its own network, so Swarm can start the new router before stopping the old one. Long-lived connections can still close when the old router stops. Updating the front itself briefly interrupts traffic.

The front closes an established tunnel, such as a WebSocket, after 24 hours without traffic. Connection setup and initial exchanges have shorter timeouts.

The edge router decrypts the request

The edge router is Traefik. It selects a certificate for the hostname, decrypts the request and routes it to the matching web application.

Ordinary HTTP requests on port 80 redirect to HTTPS. Certificate checks take a separate path, described below. Application HTTPS responses include HSTS, which tells browsers to use HTTPS for that hostname for a year.

Each hostname has its own certificate. A failed certificate request for one custom domain does not block the others or the default route.

A replica answers, on any node

Traefik sends plain HTTP to a replica's configured port through its environment network. You choose that port, 8080 by default, and Tenkai supplies it as PORT. Public HTTPS still uses 443. Traffic to another node crosses the encrypted cluster network.

The edge router joins the production environment's private network but does not forward packets between networks.

With several replicas, Traefik takes them in turn. See load balancing and replicas for placement and failure limits.

For a static site, Tenkai builds a serving image from the files your CI uploads. Its server can return index.html for client-side routes, or use directory indexes and 404.html for a static website. See deploy a static site.

An optional TCP port takes a different path. Tenkai assigns a public port from 22000 to 22019 on the edge node and forwards raw TCP to the container port you choose. The application handles authentication and TLS. It sees the router's address, not the client's. UDP is not supported.

How Tenkai issues the certificates

Tenkai requests certificates. Traefik only serves them.

1. Tenkai requests certificates once an application is deployed or deploying, for its enabled default route and DNS-checked custom domains. Let's Encrypt limits still apply.
2. Tenkai proves control of a default route with a DNS TXT record. For a custom domain, Let's Encrypt checks a special URL on port 80 to verify control of the domain. Traefik redirects that request to Tenkai, which answers. You add no extra DNS record for this proof.
3. Tenkai stores the certificate in its database and encrypts its private key. It sends both over SSH to the edge node. A node receives only its cluster's certificates.
4. Traefik loads the certificate without a restart. Tenkai waits for delivery before routing the hostname.
5. Tenkai schedules renewal in the window Let's Encrypt suggests. Without a window, it renews when one-third of the certificate's lifetime remains. Traefik loads the replacement without a restart.

Removing a custom domain, disabling the default route or deleting the application stops renewal and queues removal from the edge node. Tenkai retries removal if the node is unreachable.

Keeping certificates in Tenkai lets them outlive an edge node. During a planned edge node move, the new node gets certificates and custom domain routes before DNS changes. Both routers serve traffic while DNS caches catch up. A CNAME follows the default route; update an A record yourself. Tenkai waits for the domains to leave the old address before retiring its router, unless you explicitly skip that wait. This is a planned move, not automatic failover.

If the first certificate request fails, the hostname stays unrouted. Its HTTPS status explains why and when Tenkai will retry. If renewal fails, the existing certificate stays in use. It can expire and cause browser warnings. See HTTPS is not ready.

Limits

• A cluster has one edge node. Losing it stops public traffic, even when replicas run elsewhere. Tenkai does not replace it automatically or provide an external load balancer.
• Tenkai routes IPv4, not native IPv6.
• Tenkai uses Let's Encrypt. You cannot upload your own certificate or use a wildcard certificate.
• Issuance and renewal need Tenkai to be reachable. Existing traffic does not, while the installed certificate remains valid.
• All visitors reach the edge node's location. The edge router does not cache responses.

When another option suits better

• For distant visitors, a CDN can serve cached files closer to them. A PaaS with multi-region deployment can run the application closer too. Tenkai's single edge node does neither.
• For traffic that must survive a lost entry server, choose a host with a load balancer across healthy servers. More Tenkai replicas do not solve this.
• If a contract requires another certificate authority, choose a host that accepts your certificates.

Go further

• How traffic reaches your applicationFollow a request from DNS to the edge node, through HTTPS and the edge router, to a replica on any node of the cluster.
• Connect a custom domainConnect your domain to a Tenkai web application with a CNAME or an A record, and verify automatic HTTPS.
• Diagnose deployment and HTTPS failuresRead the logs of a deployment and find the next check for a failed build, an application that does not respond, incorrect DNS or an HTTPS verification failure.
• Read the traffic of a web applicationRead the traffic tab of a web application: its requests by status class over time, what counts as a request, and what a gap in the chart means.
• The cluster networkMix Hetzner Cloud, DigitalOcean, Scaleway, Infomaniak Public Cloud and your own hardware in one cluster, linked by an encrypted WireGuard mesh.