Custom Domains

Serve your internet-facing applications on your organization's own domain. Verify a domain once, and every image application in your organization can use it — either with an automatically generated hostname like my-app-a1b2c3.example.com, or a hostname you choose such as shop.example.com.

How it works

1. Claim a domain your organization controls (for example example.com or apps.example.com).
2. Verify ownership by publishing a DNS TXT record — the same industry-standard challenge used for TLS certificates and major cloud platforms. Verification is a one-time step per domain.
3. Use it when deploying an image application: pick the domain in the deploy wizard. AstroPulse reserves the hostname for your app and configures the application's ingress to answer for it.
4. Point DNS at your cluster — this step is yours. AstroPulse does not create records in your DNS zone; see DNS records are your responsibility below.

Applications that don't need to be reachable from the internet can simply skip external access — they run inside the cluster without any domain. Internet-facing image applications are served on your verified domain.

Claim and verify a domain

Web console

1. Go to Settings → Domains and select Add domain.
2. Enter a domain your organization controls, e.g. example.com.
3. The console shows a TXT record (name and value). Add it at your DNS provider.
4. Once DNS has propagated — typically a few minutes — select Verify.

CLI

# Claim the domain — prints the TXT record to publish
astroctl domain add example.com

# Show the required TXT record again at any time
astroctl domain get example.com

# After adding the record at your DNS provider
astroctl domain verify example.com

If verification reports that the TXT record was not found yet, wait a few minutes for DNS propagation and retry. The verification challenge is valid for 24 hours; if it expires, re-add the domain for a fresh challenge.

Use the domain for an application

Deploy wizard

When deploying an image application, the External access field is an explicit choice:

• Not exposed to the internet — the app runs inside the cluster only.
• Your domain — the app is served at an auto-generated <app>-<id>.example.com, or enter a specific hostname such as shop.example.com. Requires a verified domain.

CLI / application spec

For image applications, external access uses two mutually-exclusive fields under externalAccess:

apiVersion: platform.astropulse.io/v1
kind: Application
spec:
  name: shop
  profileName: my-profile
  source:
    type: image
    image:
      repository: myrepo/shop
      tag: v1.0.0
  externalAccess:
    domain: example.com            # auto-generated → shop-a1b2c3.example.com
    # hostname: shop.example.com   # OR serve at exactly this hostname

• domain: <verified-domain> → the platform auto-generates a hostname <app>-<id>.<domain> (a unique subdomain under your domain).
• hostname: <exact-hostname> → the app is served at exactly this — your domain's apex (example.com), or any hostname under a verified domain (shop.example.com, a.b.example.com).

Set one or the other, never both. Hostnames are reserved per organization — if another application already holds one, deployment fails with a clear error, and deleting an application frees its hostnames for reuse.

• Omit externalAccess → the app is internal-only (reachable inside the cluster, not from the internet).

There is no platform-default public URL: the platform doesn't create DNS for a hostname on your cluster, so an internet-facing app must bring a verified domain. Asking for external access without a domain or hostname is rejected at deploy time rather than handing back an address that never resolves.

Managing domains

• See what's bound — the domain card in Settings → Domains (or astroctl domain get example.com) lists every bound hostname, the owning application, and whether the name was generated or chosen.
• Release a hostname — delete the application, or run astroctl domain unbind example.com --hostname shop.example.com --yes.
• Delete a domain — only possible once no hostnames are bound: astroctl domain delete example.com --yes.

What AstroPulse automates — and what it doesn't

Be clear about the boundary before you rely on a custom hostname in production:

AstroPulse does:

• Verify domain ownership and reserve hostnames per organization (no two apps can claim the same name).
• Configure your application's ingress resource to answer for the bound hostname.

AstroPulse does not (today):

• Create or modify records in your DNS zone. Verifying a domain proves ownership — it does not give AstroPulse access to your DNS provider, and AstroPulse never writes to your zone.
• Install the serving stack on clusters you registered yourself.

Serving-stack prerequisites on registered clusters

If you registered your own cluster (bring-your-own-cluster), external access — on a custom domain or otherwise — requires infrastructure that AstroPulse does not install for you:

Component	Why you need it	Typical choice
Ingress controller	Terminates HTTP(S) and routes hostnames to your apps	ingress-nginx
TLS certificates	Serve https:// on your hostname	cert-manager + Let's Encrypt
DNS automation (optional)	Creates DNS records from ingresses automatically	ExternalDNS with your zone credentials

Without DNS automation, create the record yourself: point the bound hostname (CNAME or A record) at your cluster's ingress load balancer. Until the record exists and propagates, the hostname is reserved but will not receive traffic.

Ready-to-use examples for deploying these dependencies (ingress-nginx, cert-manager, ExternalDNS) are maintained in the astro-platform-apps repository.

Clusters provisioned by AstroPulse come with the serving stack (ingress, DNS automation for default AstroPulse URLs) preinstalled — but DNS records for your custom domain remain yours to manage either way, since only you hold your zone's credentials.

Coming later: first-class support for this stack is on the roadmap — AstroPulse cluster add-ons will install and manage ingress, cert-manager, and ExternalDNS on registered clusters too, automating the full path. Until then, plan for the manual steps above.

DNS records are your responsibility

• Binding a hostname reserves it inside AstroPulse and configures the app's ingress — it does not make DNS resolve. Point the record at your cluster to go live.
• If the hostname already has a DNS record pointing somewhere else (an existing service outside AstroPulse), that service keeps receiving traffic until you change the record. AstroPulse never takes a hostname over.

Good to know

• Verification is first-come, first-served. If two organizations claim overlapping domains, whichever proves ownership first wins; unverified claims never block the real owner.
• Busy zones: verify a subdomain. If your apex zone hosts many services (e.g. grafana.example.com), claim a dedicated subdomain such as apps.example.com so generated app hostnames can never collide with existing records.