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

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. See the astroctl domain reference for every flag.

Nova

Ask Nova to add and verify a domain in plain language. Nova claims the domain and returns the exact TXT record to publish, the same record the console and CLI show. After you add the record at your DNS provider, ask Nova to verify it. Publishing the DNS record is always yours to do; Nova never touches your DNS zone.

"Add example.com as a custom domain and show me the TXT record to publish."

Use the domain for an application

Console

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

For image applications, external access uses two mutually-exclusive fields under externalAccess. Set them in the application spec and apply it with astroctl app apply -f app.yaml:

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. See the application CLI reference for the full spec.

Nova

Ask Nova to deploy an image application on a verified domain, either on an auto-generated hostname or one you name. Nova produces the same application spec the console and CLI use, then reports the hostname it reserved.

"Deploy myrepo/shop:v1.0.0 on shop.example.com."

Managing domains

Console

Open the domain card in Settings → Domains. It lists every bound hostname, the owning application, and whether the name was generated or chosen. Release a hostname or delete an unbound domain from there.

CLI

astroctl domain list                                              # every domain in the org
astroctl domain get example.com                                   # bound hostnames + owning apps
astroctl domain unbind example.com --hostname shop.example.com --yes   # release one hostname
astroctl domain delete example.com --yes                          # delete a domain (no hostnames bound)

Releasing a hostname also happens when you delete its application. A domain can only be deleted once no hostnames are bound.

Nova

Ask Nova to list your domains, show which hostnames are bound, or report an application's hostname. Releasing a hostname and deleting a domain are destructive, so Nova confirms the exact hostname or domain with you before it acts; you choose the target, it is never implied.

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.

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 a serving stack on the cluster:

Component	Why you need it	Install with
Ingress controller	Terminates HTTP(S) and routes hostnames to your apps	nginx-ingress add-on
TLS certificates	Serve https:// on your hostname	cert-manager add-on
DNS automation (optional)	Creates DNS records from ingresses automatically	external-dns add-on

Each is one astroctl infra k8s addons apply (or one click in the console's cluster page) — see Cluster Add-ons. One important boundary: ExternalDNS writes records using the cluster's own cloud identity (for example IRSA or Workload Identity), which you set up at the cluster level. AstroPulse never holds your DNS zone credentials, so DNS automation works exactly as far as the access you gave your cluster.

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.

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.

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.