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.
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.
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
When a cluster starts again
- Node groups scale back up to their configured size.
- The ingress controller comes back and rebuilds the load balancer automatically. The new load balancer has a different AWS hostname.
- external-dns detects the new load balancer and re-points your DNS records at it.
- 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.