Skip to content

Custom Domains & SSL

Use 1ctl domains for custom-domain work. SatuSky creates and manages the Gateway API route for an attached hostname; do not create your own Ingress or HTTPRoute for the same app and host.

  • A deployed app with a Service.
  • A domain you control and access to update its DNS.
  • An active 1ctl profile for the organization that owns the app.

Before changing anything, inspect the current attachments and the expected DNS target. These commands are read-only:

Terminal window
1ctl domains list --app api
1ctl domains check api.example.com --probe
1ctl domains setup api.example.com
Terminal window
1ctl deploy --domain api.example.com

For an external hostname, 1ctl treats the domain as custom DNS. Use the explicit post-deploy command below when you need to select a port or avoid waiting for propagation.

Terminal window
1ctl domains add api.example.com --app api --port 8080

The command attaches the hostname to the app and reconciles the platform route and TLS intent. It waits for DNS and TLS by default. To return after attachment, use --no-wait; use --with-www to request a www redirect for an apex domain where supported.

<domain> is a hostname, not a URL. Wildcard hostnames are not currently supported by custom-domain TLS. A hostname outside satusky.com is treated as custom DNS; --custom-dns makes that choice explicit.

Terminal window
1ctl domains setup api.example.com

For externally managed DNS, add exactly the record shown by the command at your DNS provider. If the hostname belongs to an existing SatuSky-managed zone, attachment creates or updates the required record automatically; inspect it with 1ctl domains dns list --domain example.com. Do not point the hostname directly at a workload or create a second Gateway route.

Terminal window
1ctl domains check api.example.com --probe

A domain is ready only when backend attachment, Gateway route attachment, DNS, TLS, and HTTP reachability agree. A healthy deployment can still have pending DNS or TLS.

An app hostname, a managed DNS zone, and a purchased registration are separate resources. Listing either of the first two is safe:

Terminal window
1ctl domains managed list
1ctl domains dns list --domain example.com

1ctl domains managed add changes DNS-zone ownership/delegation expectations; use it only for a domain you control. managed verify checks nameserver delegation. DNS create, update, and delete change the zone and can disrupt live traffic, so inspect records first and make one deliberate change at a time. Managing a DNS zone does not attach it to an app: attach the hostname separately with 1ctl domains add.

Searching and availability checks do not purchase a domain:

Terminal window
1ctl domains search --name example --tld com --tld xyz --period 1
1ctl domains available --domain example.com --price

1ctl domains purchase creates a checkout using the current organization’s credit balance and requires registrant contact details. Confirm the selected domain, price, and organization before running it; then retain the returned intent ID and follow it with 1ctl domains purchase-status <intent-id>.

Terminal window
1ctl domains remove api.example.com --app api --yes