Domains and HTTPS on Candor Deploy

Every app you deploy gets two things without asking: a working URL and a real HTTPS certificate. When you’re ready to put your own domain in front of it, that’s one request and one DNS record. This page covers all three.

The URL you get for free

Every app and static site gets a generated hostname the moment it exists:

https://<service-name>-<account-number>.candorhost.app

So an app named shop on account 42 serves at https://shop-42.candorhost.app. You’ll see the exact URL at the top of the app’s page in the portal, next to a Visit link — no need to construct it yourself.

Databases don’t get URLs, on purpose: they’re reachable by your apps, never by the open internet — see databases on Deploy.

The generated URL never goes away, even after you add a custom domain. It’s handy as a stable address for health checks or for testing a deploy before your real domain cuts over.

HTTPS is automatic — everywhere

Every hostname your app serves — the built-in candorhost.app one and every custom domain you add — gets its own HTTPS certificate, provisioned and renewed automatically. Plain http:// requests redirect to https://. There is no toggle, no certificate to upload, and nothing to renew. This is included on every plan.

Add your own domain

Custom domains apply to app and static site services (databases have no public endpoint to point a domain at). You add domains through the Candor MCP tools — for example, ask an AI assistant connected to Candor’s MCP server (connect Claude) to add the domain for you (you need permission to manage domains on the project):

1. Ask it to add the full hostname — www.yourdomain.com, app.example.com, or a bare example.com — to your app or static site. This calls the add_domain tool.
2. Candor immediately returns the one DNS record to create (type, name, and value). Add that record wherever your domain’s DNS is managed — your registrar or DNS provider.
3. Check the domain’s status with the list_domains tool. DNS shows pending until the record resolves, mismatch if it resolves somewhere else, and ok once it points at us; TLS shows pending until the certificate has issued, then active. Either can briefly show unknown if the status couldn’t be checked; check again in a minute.

You can add a domain before your app’s first deploy; it’s wired up automatically when the app first goes live.

The DNS record we ask for

Which record you set depends on the hostname:

Your hostname	Record type	Points to
A subdomain (www.example.com, app.example.com)	CNAME	edge.candorhost.app, or the target Candor returns
A bare apex (example.com)	A, or CNAME via your provider’s ALIAS/flattening (see the note Candor returns)	15.204.160.184, or the target Candor returns

The difference isn’t our preference — an apex domain can’t be a CNAME (a DNS-wide rule), so it gets an A record to our edge IP, or a target you set with your DNS provider’s ALIAS, ANAME, or CNAME-flattening feature. Either way, Candor returns the exact record — type, name, and value — for each domain you add. Treat that as the source of truth, not this page.

A few practical notes:

• www and the apex are separate hostnames. If you want both example.com and www.example.com to work, add both — each gets its own record and its own certificate.
• Wildcards aren’t supported. Add each hostname you actually want to serve.

How verification works (there’s nothing to verify)

Some platforms make you prove domain ownership with a TXT record or a verification code. We don’t need one: control is proven by reachability. Once your DNS record is in place and resolves, the certificate issues automatically. The certificate can’t issue before your DNS actually points at us — which is why a freshly added domain sits at pending until the record is set and has propagated.

How long that takes is mostly a DNS question: if the record is right, the wait is your DNS provider’s propagation time, then a short certificate issuance. If a domain stays pending for hours, the record is almost always the culprit — re-check the type, name, and value against the record Candor returned when you added the domain.

The fine print

• Adding a domain that’s already in use fails with a clear error. If the other service is one of yours, remove the domain there first; if you don’t recognize it, open a ticket — a hostname can only be attached to one service across the whole platform.
• You can’t add domains ending in candorhost.app or candorhost.com — those are ours. Your generated URL already covers that need.
• Enter a full hostname (app.example.com), not an IP address and not a bare label.
• Removing a domain is the remove_domain tool (it asks you to confirm the hostname). Traffic to that hostname stops being routed to your app; the generated URL keeps working.

If you get stuck

DNS has more moving parts than the rest of this platform, and half of them belong to your registrar. If a domain won’t go live and the record looks right to you, open a ticket with the domain name and where its DNS is hosted — we reply within one business day, per Candid Support.