Docs / Candor Deploy
Domains and HTTPS on Candor Deploy
How your app gets its built-in candorhost.app URL, how to attach your own domain, the exact DNS records to set, and how HTTPS certificates issue automatically.
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 a form field 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.
Two service types don’t get URLs, on purpose: workers (background processes with no public endpoint) and databases (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 Let’s Encrypt certificate, issued and renewed automatically. 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 (workers and databases have no public endpoint to point a domain at). To attach one:
- Log in at my.candorhost.com, open your Candor Deploy service, and go to the Deployments tab.
- Click the app or static site, then open its Domains tab.
- Type the full hostname —
www.yourdomain.com,app.example.com, or a bareexample.com— and click Add domain. - The portal immediately shows the one DNS record to create. Add that record wherever your domain’s DNS is managed — your registrar or DNS provider.
- Check the domain’s status in the same tab (re-open it to refresh). It starts as Pending — set the DNS record below and shows Live over HTTPS once your DNS points at us and the certificate has issued.
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 |
A bare apex (example.com) | A | 192.99.45.30 |
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 instead. Either way, the portal shows 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:
wwwand the apex are separate hostnames. If you want bothexample.comandwww.example.comto work, add both in the Domains tab — each gets its own record and its own certificate.- Wildcards aren’t supported. Add each hostname you actually want to serve.
- New to DNS records, or your DNS is hosted with us? The DNS guide covers how records work, how to add them from our portal’s DNS editor, and the TTL-lowering trick that makes changes propagate faster.
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 requests for your domain reach our platform, we answer Let’s Encrypt’s challenge over plain HTTP on your domain and the certificate issues. 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 what the portal shows, and see troubleshooting.
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.apporcandorhost.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 button next to it in the Domains tab. 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.
Something here wrong, unclear, or missing? Tell us — docs get fixed like bugs.