SEAGIT DOCS
Documentation

DNS & Domains

How SeaGit gives every deployment a stable URL, keeps DNS records in sync automatically, and why your app URLs survive a cluster stop and start.

New to how domains fit together? Start with Domains for the concept and the environment → domain → cluster flow. This page is the operational companion: how records stay in sync and why your URLs survive a cluster stop/start.

How DNS Works in SeaGit

Every deployment gets its own subdomain on the domain attached to its environment — for example my-feature.dev.example.com. You never have to create or update a DNS record by hand.

Three pieces work together:

  • Your domain — a hosted zone (Route 53, Cloudflare, or PowerDNS) that you attach to an environment.
  • The ingress controller — NGINX or the AWS Load Balancer Controller. It owns a load balancer that receives all traffic for the cluster.
  • external-dns — a controller running inside your cluster. It watches your ingresses and writes the matching DNS records, pointing them at whatever load balancer is currently live.

The important consequence: external-dns owns your records. If the underlying load balancer ever changes, external-dns notices and re-points your records at the new one. Your URLs do not change.

external-dns ships as a per-cluster add-on, and it comes in two flavors — pick the one that matches where your zone lives: External DNS – AWS for Route 53 domains, and External DNS – PowerDNS for SeaGit’s managed *.segt.io domains. A cluster missing the right one deploys your app fine but its URL never resolves. For the Route 53 path, see Deploy an App on an AWS Route 53 Domain.

The One Rule: Never Hardcode the Load Balancer Hostname

⚠️ Point your DNS at your SeaGit domain — not at the raw AWS hostname

The *.elb.amazonaws.com hostname is an internal implementation detail. It can and does change — for example when a stopped cluster is started again. Anything pointed directly at it will break.

If you want to serve your app on a domain you manage yourself, create a CNAME to your SeaGit deployment URL:

# ✅ Correct — CNAME to your SeaGit URL (stable forever)
www.mycompany.com.   CNAME   my-app.prod.example.com.

# ❌ Wrong — CNAME to the load balancer (changes on stop/start)
www.mycompany.com.   CNAME   k8s-default-abc123-...elb.amazonaws.com.

The SeaGit URL is stable for the life of the deployment. The load balancer behind it is not.

Stopping & Starting a Cluster

Development clusters are commonly stopped outside working hours to cut costs — usually on a schedule, via Action Rules. Here is exactly what happens to your networking when they do.

When a cluster stops

SCALED TO 0Every node group scales to zero. Your workloads stop running.
RELEASEDThe cluster's load balancers are released, so a stopped cluster does not keep billing you for idle load balancers.
PRESERVEDCluster configuration, node group definitions, domains, DNS records, TLS certificates and persistent volumes are all kept.

When a cluster starts again

  1. Node groups scale back up to their configured size.
  2. The ingress controller comes back and rebuilds the load balancer automatically. The new load balancer has a different AWS hostname.
  3. external-dns detects the new load balancer and re-points your DNS records at it.
  4. Your app URLs — my-app.dev.example.com — are unchanged and start serving again.

Rebuilding a load balancer takes a few minutes, so give a freshly started cluster a little time before its URLs answer. Nothing is required from you: no DNS edits, no redeploys.

💡 Why the load balancer is released at all

A load balancer bills by the hour whether or not anything is behind it. Leaving one running in front of a cluster with zero nodes is pure waste — it can only return errors. Releasing it is what makes a stopped dev cluster genuinely cheap. Because external-dns owns your records, this is invisible in day-to-day use.

What a Stopped Cluster Still Costs

Stopping a cluster removes the large, variable costs. A few fixed costs remain because the cluster still exists:

  • Removed: all EC2 node costs, and the cluster's load balancers.
  • Still billed: the managed Kubernetes control plane, the NAT gateway, and any persistent volumes holding your data.

To remove those too, terminate the cluster instead of stopping it — but note that a terminated cluster cannot be started again.

Troubleshooting

My app URL doesn't resolve right after starting a cluster

Expected for the first few minutes. The load balancer is still being rebuilt, and external-dns updates your records once it is ready. If it persists well beyond that, check that the external-dns and ingress add-ons are installed and healthy on the cluster.

My custom domain broke after a stop/start

Almost always because it was CNAME'd directly at the old load balancer hostname. Re-point it at your SeaGit deployment URL instead — see the rule above. That survives every future stop/start.

My TLS certificate

Certificates are issued and renewed by cert-manager and are unaffected by a stop/start cycle. See Certificates & TLS.

Previous: Variables & SecretsNext: Certificates & TLS