Custom domains

Every deployment lives at <slug>.apps.atelier.style automatically. To run it under your own domain, the flow is three steps: verify ownership, route traffic, let Atelier issue the certificate. The Console drives the whole flow; the CLI is the scripted entry point for the same actions.

1. Verify ownership

In the Console, open Project → Domains → Add domain. Atelier returns a TXT record to add at your DNS provider, with copy buttons next to each value.

Or via CLI:

atelier domains add example.com

Either path produces the same TXT record:

_atelier-verify.example.com   TXT   "atelier-verify-abc123..."

The Console shows the verification state in real time — no polling. Most providers propagate in under five minutes; some take up to thirty. The domain row moves through a live status badge: Pending TXT → Pending CNAME → Issuing cert → Live.

Or via CLI:

atelier domains list
# example.com           verifying   waiting for TXT
# example.com           verified    next: add CNAME

2. Route traffic

Once verified, the Console shows the CNAME (or apex routing) instructions tailored to your domain — subdomain gets a single CNAME, apex gets the ALIAS/ANAME options for your provider with a fallback A-record list. The status badge advances from Pending CNAME to Issuing cert the moment DNS resolves, so you don’t need to poll atelier domains list.

The record type depends on whether you’re pointing a subdomain or the apex.

Subdomain — CNAME

The simplest case:

app.example.com   CNAME   cname.apps.atelier.style

Set TTL low (300s) while iterating; raise it after things settle.

Apex — ALIAS / ANAME

example.com can’t take a CNAME (DNS rule). Use ALIAS or ANAME if your provider supports it:

example.com   ALIAS   cname.apps.atelier.style    (Route 53, Cloudflare)
example.com   ANAME   cname.apps.atelier.style    (DNSimple, easyDNS)

Providers that don’t offer ALIAS / ANAME fall back to plain A records pointed at Atelier’s static ingress IPs. Atelier rotates ingress capacity, so flat A records require manual maintenance — switching to an ALIAS-capable provider (Cloudflare, Route 53) is the recommended path.

Wildcard — for multi-tenant SaaS

*.example.com   CNAME   cname.apps.atelier.style

Atelier issues the cert via the DNS-01 challenge, which needs a CNAME at _acme-challenge.example.com. On supported providers, connect the provider once through Console → Domains → Connect provider and Atelier writes the record automatically. On others, the Console surfaces the values for paste. Required if your SaaS lets customers run under acme-corp.example.com, globex.example.com, etc.

3. TLS — automatic

The Console domain row updates: Issuing → Live (cert expires <date>). Renewals at 30 days, transparently. Once the CNAME (or ALIAS / wildcard) resolves, Atelier requests the certificate from Let’s Encrypt and attaches it to the edge. Typical wait: one to five minutes after DNS propagation.

Or via CLI:

atelier domains list
# example.com           verified  ✓ live    cert expires 2026-09-08
# app.example.com       verified  ✓ live    cert expires 2026-09-08

Common configurations

Apex + www

Most marketing sites want both example.com and www.example.com. In the Console, on the domain row, mark example.com primary and add www.example.com with a 301 redirect target. Atelier issues both certificates and serves the 301 from www → apex (or the other way around — primary is your call).

The same setting saved as code:

// atelier.config.ts
export default {
  deployments: {
    domains: {
      'example.com': { primary: true },
      'www.example.com': { redirectTo: 'example.com' },
    },
  },
};

Staging vs production

Domains pick their environment from the Console project switcher — add a domain while viewing the preview environment and it’s bound to preview; the production environment gets its own row.

Or set explicitly in code:

deployments: {
  domains: {
    'example.com': { env: 'production' },
    'staging.example.com': { env: 'preview' },
  },
}

The same project, two domains, no extra setup.

Per-tenant — for B2B SaaS

Turn on Settings → Domains → Allow tenant-supplied domains. Customers add their domain through your app; Atelier guides them through the same TXT + CNAME flow scoped to their tenant. The SDK call that backs the customer-facing UI you build into your app:

await atelier.domains.add({
  tenantId: tenant.id,
  domain: 'acme.com',
});

The customer’s admin sees the TXT and CNAME instructions in your UI; Atelier verifies, issues the cert, and routes traffic to the right tenant. Wildcard subdomains (*.your-app.com for acme.your-app.com, globex.your-app.com) skip the customer DNS step entirely.

Troubleshooting

Lifecycle

In the Console, the Domains list shows status, expiry, primary flag. Remove from the row’s overflow menu — a confirmation modal explains the 24-hour cert grace. Transfer through the project picker; no re-verification.

Or via CLI:

atelier domains list
atelier domains remove app.example.com
atelier domains transfer app.example.com --project new-project

Removing a domain unbinds it from the project but leaves the cert in place for 24 hours (so accidental removals during deploys don’t break users mid-session). Transfer moves a domain between projects without re-verification.

What about subdomains we already use?

Atelier doesn’t take over the whole zone. It only attaches to the records you point at it. support@, mail.example.com, the existing blog at blog.example.com — none of them touched.

If you want Atelier to host the whole zone (delegate the entire domain), initiate the delegation from Console → Domains → Delegate zone, or run atelier domains delegate example.com. Either path shows the four NS records to set at your registrar; from there Atelier manages everything (including MX records you ask it to keep for Messaging’s inbound email).