Custom domain

Serve an application or model on a name under your own domain, such as shop.apps.example.com, over HTTPS. You verify the domain once for the organization; then the Access step of the wizard serves an application on it, and for a model an access policy decides who may call it.

Before you start

• On the cluster, Ingress and Certificates for HTTPS, and Gateway for a model with an access policy. Add DNS Automation to create the DNS records for you. Install add-ons.
• A DNS zone you can add a TXT record to.
• For a model called from outside: an access policy.

In the console

1. Open Integrations > Domains, select Add domain, enter the Domain name, for example apps.example.com, and select Claim domain. Add the TXT record it shows to your DNS zone, then select Verify. The domain shows Verified. See Custom domains.

   Open zoom view

   The domain verified and ready to use

   

2. For a model: create an access policy under Integrations > Access Policies, for example partner-keys with a key for each caller. See Give callers API keys, or Let your services call with tokens.

   Open zoom view

   The new API-key policy form

   

3. Open Workloads > Applications > Deploy application and select Container image as the source, or Workloads > Models > Deploy model.

4. On Access, under External access, pick Serve on apps.example.com. With no verified domain, the step says "The app runs inside the cluster. To serve it on the internet, verify a domain in Integrations › Domains."

5. Type the subdomain, for example shop. The step shows "Served at shop.apps.example.com." Leave it blank to use the application's name.

6. For an image application, pick a TLS mode: Add-on default, or one of the modes the cluster offers. See TLS modes.

7. For a model, pick the policy under Who may call it.

   Open zoom view

   The Access step serving on a verified domain, with the subdomain, the hostname it is served at, and Who may call it

   

8. Select Review, run the dry run, then Deploy.

A running model that is not on a domain yet gets one from its Update tab, Change configuration, Access. Once an application is served on a hostname, the step shows "Served at this hostname. Fixed once the application is created."

Open zoom view

A served model's Access step: the domain fixed and its access policy

You should see

The Overview shows the Endpoint: its public address and, for a model, Who may call it and Try it. Call a model with its key in the Authorization: Bearer header.

Open zoom view

The model's endpoint ready with its access policy

DNS

When you choose a domain, the Access step says who writes the hostname's DNS record on that cluster. With DNS Automation installed, AstroPulse writes it for hostnames inside the add-on's Domain filter, unless Dry run is on. Otherwise create the record yourself, pointing at the cluster's ingress; the application is served either way.

Expose each source type

Which add-on serves the application depends on its source:

Source	Served by	You set
Image	Ingress	externalAccess.domain or hostname; AstroPulse writes the Ingress and the certificate
Model	Gateway when it is installed and ready, Ingress otherwise	The same, plus accessPolicyRef. Only the Gateway enforces an access policy
Helm, repository, YAML	The chart's or manifests' own Ingress	The Ingress in your values or manifests; AstroPulse adds nothing to it

Image

shop.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
metadata:
  name: shop
spec:
  profileName: eks-prod
  source:
    type: Image
    image:
      repository: nginxinc/nginx-unprivileged
      tag: 1.27-alpine
      port: 8080
  externalAccess:
    domain: apps.example.com

Served at https://shop.apps.example.com. To pick the certificate (one per app, a wildcard, or the app's own), choose the wizard's TLS mode, or set externalAccess.tls.mode: TLS modes.

Helm chart

Turn on the chart's own Ingress in values. The keys are the chart's; this is the podinfo chart:

podinfo.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
metadata:
  name: podinfo
spec:
  profileName: eks-prod
  source:
    type: Helm
    helm:
      repo:
        repoURL: https://stefanprodan.github.io/podinfo
        chartName: podinfo
        chartVersion: 6.7.1
      values:
        object:
          ingress:
            enabled: true
            className: nginx
            annotations:
              cert-manager.io/cluster-issuer: astro-letsencrypt
            hosts:
              - host: podinfo.apps.example.com
                paths:
                  - path: /
                    pathType: Prefix
            tls:
              - secretName: podinfo-tls
                hosts:
                  - podinfo.apps.example.com
  externalAccess:
    dnsEndpoint: podinfo.apps.example.com

What the chart's Ingress needs:

• Class nginx, so the Ingress add-on serves it.
• Annotation cert-manager.io/cluster-issuer naming the cluster's issuer (astro-letsencrypt by default; astroctl infra k8s exposure get <cluster> shows it) and a tls entry with a secretName, so Certificates issues the certificate. To use the add-on's wildcard certificate instead, see Behavior and limits.
• Host under your domain. DNS Automation publishes its record.

Git repository

A chart in Git takes the same values:

podinfo-git.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
metadata:
  name: podinfo-git
spec:
  profileName: eks-prod
  source:
    type: Repository
    repository:
      repo:
        repoURL: https://github.com/stefanprodan/podinfo.git
        path: charts/podinfo
        targetRevision: 6.7.1
      values:
        object:
          ingress:
            enabled: true
            className: nginx
            annotations:
              cert-manager.io/cluster-issuer: astro-letsencrypt
            hosts:
              - host: podinfo-git.apps.example.com
                paths:
                  - path: /
                    pathType: Prefix
            tls:
              - secretName: podinfo-git-tls
                hosts:
                  - podinfo-git.apps.example.com
  externalAccess:
    dnsEndpoint: podinfo-git.apps.example.com

YAML

The YAML source applies the manifests in a Git directory as they are. Kustomize is not run: commit the rendered output (kustomize build). In your own repository (https://github.com/<your-org>/<your-repo> below), add an Ingress for your hostname next to your Service:

ingress.yaml (in your repository)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
  annotations:
    cert-manager.io/cluster-issuer: astro-letsencrypt
spec:
  ingressClassName: nginx
  tls:
    - hosts: [web.apps.example.com]
      secretName: web-tls
  rules:
    - host: web.apps.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

web.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
metadata:
  name: web
spec:
  profileName: eks-prod
  source:
    type: YAML
    yaml:
      include: "*.yaml"
      recursive: true
      repo:
        repoURL: https://github.com/<your-org>/<your-repo>
        path: deploy
        targetRevision: main
  externalAccess:
    dnsEndpoint: web.apps.example.com

Model

qwen-chat.yaml

apiVersion: platform.astropulse.io/v1
kind: Application
metadata:
  name: qwen-chat
spec:
  profileName: eks-prod
  source:
    type: Model
    model:
      uri: hf://Qwen/Qwen2.5-0.5B-Instruct:7ae557604adf67be50417f59c2c2f167def9a775
  externalAccess:
    domain: apps.example.com
    accessPolicyRef:
      name: partner-keys

With the Gateway installed, the model is served through it with a certificate issued for its hostname. On Let's Encrypt that needs the DNS challenge on Certificates (identity and dnsSolver); an EKS cluster AstroPulse created has it. Without the Gateway, a model with an access policy is refused: "Authenticated endpoints need the gateway add-on". Details: Exposing a model.

On Helm, repository and YAML applications, externalAccess.dnsEndpoint records the hostname for reference and cannot be changed once set. domain, hostname, exposure, tls and accessPolicyRef are refused on them.

On Helm, Git repository and YAML applications, externalAccess.dnsEndpoint records the hostname for reference and cannot change once set. domain, hostname, exposure, tls and accessPolicyRef are refused on them. Nova can write the chart values or the Ingress manifest for you. See Helm chart, Git repository and YAML.

Check the URL and certificate

astroctl app get shop shows the hostname it is served at (endpoint). Check the certificate it presents:

Terminal

host=shop.apps.example.com
echo | openssl s_client -connect "$host:443" -servername "$host" 2>/dev/null \
  | openssl x509 -noout -issuer -dates -ext subjectAltName
curl -sSI "https://$host"

-ext needs OpenSSL 1.1.1 or later. The names (subjectAltName) include the hostname, or *.apps.example.com in the wildcard mode, and the issuer is the cluster's issuer, Let's Encrypt by default.

Other ways in

• Nova: ask it, for example "serve shop on apps.example.com".
• SDK and API: the same operations, in the API reference.

With astroctl

Apply any manifest above with a dry run first:

Terminal

astroctl app apply -f shop.yaml --dry-run
astroctl app apply -f shop.yaml

Domains, policies and keys from a terminal: Custom domains, Access policies.

Settings

External accessexternalAccess.domain

A verified domain. The application is served at <subdomain>.<domain>. Image and model applications only.

Accepts

a domain verified under Integrations > Domains

Default

none: the application is internal only

See

Custom domains

SubdomainexternalAccess.hostname

An exact hostname under a verified domain, instead of domain. In the console, the subdomain you type.

Accepts

a hostname under a verified domain

Default

<app>.<domain>, with an id added only if that name is taken

TLS modeexternalAccess.tls.mode

The certificate an image application is served with: one per application, a wildcard, or the application's own.

Accepts

Certificate, Wildcard, Passthrough, as the cluster offers them

Default

the Ingress add-on's default

See

TLS modes

Who may call itexternalAccess.accessPolicyRef.name

The access policy the Gateway enforces on a model's endpoint. Needs the Gateway add-on.

Accepts

an access policy in your organization

See

Access policies

externalAccess.dnsEndpoint

On Helm, Git repository and YAML applications, the hostname their own Ingress serves, for reference. Fixed once set.

Accepts

a verified domain or a hostname under one

The hostname cannot change after the first deploy. To serve an application elsewhere, delete it and deploy it again.

If it's refused

"apps.example.com" must be a verified domain

Cause

externalAccess.domain names a domain that is not verified in your organization.

Fix

Verify it under Integrations > Domains, then apply again.

"shop.apps.example.com" is a hostname under a verified domain, not a verified domain itself: use externalAccess.hostname to serve at this exact hostname

Cause

domain holds a full hostname.

Fix

Move it to externalAccess.hostname, or set domain to the verified domain.

"external access requires a verified domain or hostname: set externalAccess.domain or externalAccess.hostname, or omit externalAccess for an internal-only app"

Cause

externalAccess is set without a domain or hostname.

Fix

Set one, or remove externalAccess to keep the application internal.

"externalAccess.domain is used only by image and model applications; a Helm application is reached through its chart's own ingress. Remove it, or set externalAccess.dnsEndpoint to the hostname that ingress serves."

Cause

A Helm, Git repository or YAML application sets domain or hostname.

Fix

Turn on the chart's or manifests' own Ingress (By source) and set externalAccess.dnsEndpoint.

"Moving an application's endpoint to another hostname is not supported yet; the endpoint stays at <hostname>. To serve it elsewhere, delete the application and deploy it again."

Cause

The update changes the hostname of an application already served.

Fix

Keep the hostname, or delete the application and deploy it again on the new one.

"Authenticated endpoints need the gateway add-on"

Cause

A model with an access policy, on a cluster without the Gateway add-on. The Ingress cannot enforce an access policy.

Fix

Install the Gateway add-on on the cluster, then apply again.

Next

• Access a cloud bucket
• Access policies
• Releases and rollback