Skip to content
Networking

Networking

How a request reaches your service, what Kuppit's edge does to it on the way, how services reach each other, and what is not there.

Every request to a Kuppit hostname, generated or custom, passes through Kuppit's edge before it reaches the revision that is Live. The edge terminates TLS, checks the hostname, forwards the request to the right service, and hands back whatever the service answers. Your application sees an ordinary HTTP request with a few headers Kuppit sets.

What happens to a request

  1. Plain HTTP is redirected to HTTPS with a permanent redirect. Certificates are Kuppit's to manage; you never upload one.
  2. The hostname is matched to a service. A hostname Kuppit does not route, or one whose environment has been removed, gets a plain 404 Domain Not Found from the edge.
  3. The request is forwarded to the Live revision with its path and query intact. Redirects your application returns go back to the browser as they are; the edge does not follow them.
  4. The response streams back. Bodies in both directions are streamed, not buffered.

Headers your service receives

HeaderValue
X-Forwarded-HostThe hostname the request came in on.
X-Forwarded-Protohttps, always.
X-Forwarded-ForThe client's address.
X-Kuppit-Request-IDAn id for the request. Every error page from the edge prints it, so a report can be matched to a log line.

Any values a client sent in those headers are replaced, so they can be trusted. Hop-by-hop headers are stripped from the request before it is forwarded; your service's response is returned as it is. A request carrying Upgrade: websocket keeps its upgrade headers on the way through; Kuppit makes no further claim about WebSocket support and has no settings for it.

Limits and timeouts

LimitValueWhat happens beyond it
Request body, as declared by Content-Length100 MB413 Payload Too Large, before anything is forwarded. A body sent without a length is streamed through unchecked.
Time to first byte from your service120 seconds504 Gateway Timeout.
A service that refuses the connection502 Bad Gateway.

Error pages from the edge are plain text with the request id.

Services reaching each other

Services have no private network between them. One service calling another does so over the other's public hostname, https://acme-api-d4e5f6.kuppit.app, like any other client, and its request passes through the edge the same way. Put the hostname in a variable rather than in code, because each environment has its own.

A web service exposes no variables of its own for others to reference. Only a database does.

Services reaching databases

A service reaches a PostgreSQL database in the same environment over a connection the infrastructure attaches, not over the public network. The details, and why PGHOST is not a hostname, are on reaching a database.

What is not here

  • Private networking, VPCs, private IPs. There is no network to configure.
  • IP allowlists, firewall rules, a WAF. Nothing filters requests by source.
  • Static addresses. Neither inbound nor outbound. A custom domain routes by CNAME, never by A record.
  • Caching, path routing, redirects, custom headers, rate limits at the edge. The edge routes one hostname to one service, whole.
  • The origin behind the edge is not hidden. The Kuppit hostname is the supported public interface, and the hostname is what carries the certificate and the headers above.
Was this page helpful?