Skip to content
flui.cloud

DNS as part of the deploy contract

An application that is up but unreachable is, in operational terms, not really deployed. Flui treats reachability as part of the deploy itself: every application gets an endpoint — the address at which it is reachable from outside the cluster — as part of the same operation that deploys it. The user does not allocate hostnames or edit DNS records by hand; the endpoint is decided from the cluster the application belongs to plus the application’s identity.

A certificate that makes that endpoint speakable on HTTPS is provisioned in lock-step — covered in TLS and certificates.

What an endpoint is

An endpoint is the FQDN that a client (a browser, another service, a CLI) uses to reach an application. Endpoints are opt-in: an application that does not need to be reachable from outside can be deployed without one. When the application does declare that it should be reachable, the rest — hostname, record, certificate, routing — is on Flui.

Endpoint hostnames come from one of two modes — DNS-based or IP-based — and the choice between them is the choice between production-grade addressing and a frictionless default.

DNS-based addressing comes in two flavours, depending on whether Flui is given delegated control of a zone or not.

  • With a DNS zone (recommended). The user creates the domain on a DNS provider Flui integrates with; Flui’s zone-creation wizard detects it and registers it as a zone of the installation. From that moment on the installation knows where the domain lives, and any cluster can be associated with that zone. More than one zone can be registered with a single installation; each cluster is bound to one at a time, and every endpoint on the cluster lives on a subdomain under it. Flui creates, updates and removes records on the zone automatically as endpoints come and go, and the certificate path runs once for the whole subdomain through a wildcard. The user never has to open the DNS provider’s console to approve a record.
  • Without a zone, record by record. No zone is registered with Flui; the user creates a DNS record for each endpoint manually, on whatever provider they use, pointing it at the cluster’s public IP. Flui still tracks each endpoint and the hostname it expects to resolve to, and a DNS resolution check is available from the dashboard so a missing or misconfigured record can be caught before triggering a certificate authority error. It is the more laborious path, but it is the way to bring an externally-hosted domain under a Flui cluster without delegating the zone.

The zone-based path is the recommended one for any environment beyond local experimentation: the loop “deploy → record → cert → serve” closes without manual steps, and additions or removals of endpoints leave no orphan records behind.

IP-based (nip.io)

The cluster has no domain bound, and Flui synthesises the endpoint’s hostname from the cluster’s master IP, through a public service (nip.io) that resolves names back to the IP embedded in them. No record exists anywhere — resolution happens at the resolver itself.

This mode exists primarily so the very first cluster of a fresh installation can come up without DNS as a prerequisite: the bootstrap is friction-free, and a working URL is in your hands the moment the cluster is ready. It is also a sensible choice for development and staging clusters where the hostname does not have to be presentable. It is not recommended for production — both for the reasons above (third-party dependency, shared rate limits) and because the URL itself carries the cluster’s IP.

Switching from IP-based to DNS-based later is a single operation: bind a domain to the cluster and every new endpoint uses the new mode; existing endpoints are reconciled across without re-deploying the application.

Public and gated endpoints

When the cluster has a domain bound, Flui standardises a small naming convention to separate endpoints meant for the public from endpoints meant for authenticated access:

  • <app>.<cluster-subdomain>.<zone> — the public endpoint of the application.
  • <app>.internal.<cluster-subdomain>.<zone> — the same application, behind the cluster-side authentication gate described in The control cluster.

Both share the same DNS and certificate flow; the difference is purely whether the auth gate is in the request path. An operator can publish “the app” and “the admin face of the app” on two sibling hostnames without doing anything extra at the DNS level.

When reality drifts

The endpoint’s record lives on the provider’s DNS, and Flui keeps its own view of what should be there. If something edits the records out of band — a human in the provider’s console, a deletion the provider’s API accepted but lost — the two views can drift apart.

Flui provides a reconciliation surface that lists what should be there, compares it against what the provider zone actually reports, and either prints the diff or applies the corrections. Where the provider supports it, Flui also offers a destructive cleanup operation for wiping stale records from a zone when starting over. The command-level reference for both is in the CLI docs.

What Flui DNS does not do

Buying a domain, or migrating its authoritative DNS to a provider Flui integrates with, is a step the user takes on the provider itself. Flui does not act at the registrar level: it works on a zone the user has already created on a supported provider.

A note on what sits behind an endpoint

Every endpoint in Flui resolves, internally, to a chain of pieces the runtime needs to route a request: a DNS record on a zone, a certificate held as a secret on the cluster, an entry in the cluster’s ingress, a service in front of the application’s pods. The user does not deal with any of them individually — they are the cluster’s job, not the operator’s. They are mentioned here only because someone debugging at the cluster level may need to know where to look.

Where this chapter goes from here