Make it real
Your own domain — and the certificate that follows
Your app already has an address that works. This is how it gets the one you own: the records to create, what happens on its own afterwards, and what to delete the day you stop.
1. Tell Erawan the name
Say it to your agent, or run it yourself. Either way what comes back is the DNS records to create — the exact ones for the name you gave, which is why this step comes before you touch your registrar.
2. Create what it printed
A subdomain is one record:
Type | Name | Value |
|---|---|---|
CNAME | shop | ingress.erawan.cloud |
A bare domain is two, and you get both without being asked which you wanted:
Type | Name | Value |
|---|---|---|
A | @ | the address it printed |
CNAME | www | ingress.erawan.cloud |
The second one is not optional politeness. A bare domain cannot be a CNAME — that is a rule of DNS, not ours — so the apex needs a literal address while www can point at a name. Create only the first and your site works perfectly while the link a friend types, with the www they add out of habit, goes nowhere. Nothing reports that. You find out when somebody tells you.
3. If you use Cloudflare, turn the proxy off
The orange cloud has to be grey. With the proxy on, the name resolves to Cloudflare rather than to us, the certificate cannot be issued, and the error you would otherwise get says nothing useful — so Erawan checks for it by name and tells you this instead.
4. Wait, and let the certificate happen
Nothing else to do. Erawan resolves the name itself, and only once it can see the records pointing here does it ask for a certificate.
That order is deliberate and it is protecting you. Let's Encrypt rate-limits failed validations at five per hour per hostname, so a "check again" button that asked every time you pressed it would lock you out of your own domain within a few minutes — behind an ACME error nobody can read. Checking DNS first costs a wait and cannot burn the allowance.
That says what each name is waiting for. DNS changes can take up to an hour to spread; the certificate follows within a minute or two of the name becoming visible.
5. Optional: send the old address to the new one
The erawan.app address keeps working and stays yours. If you would rather everyone ended up on the domain you own:
Off by default, because until you say so both addresses are equally real and neither of us should decide which one is the front door.
6. Renaming the app does not move the address
That changes the handle you type into commands and nothing else. The erawan.app address stays exactly as it was, because it is stored rather than built from the name — and because it is a promise already made to whoever has the link. Changing the address is what this lesson is for; renaming is a different thing that only looks adjacent.
Add-ons do not move either. A Postgres attached before a rename keeps a name derived from the old one, which reads oddly and is the right trade: the alternative moves a volume holding your data to make a name tidy.
7. If your project has an erawan.yaml
Two different things share the word. erawan domain add attaches a domain to the app. A domain: inside erawan.yaml belongs to one component, which is the part of a multi-component release that will actually serve that name — and subdomain: beside it claims a name in Erawan's own flat namespace, which is first-come, so it is written out rather than derived from your app's name.
A single-component app never meets this. If you are running one service, the command is the whole story.
8. When you stop
Detaching gives the app its erawan.app address back, untouched:
The DNS records are yours to delete, and we cannot do it for you — the zone is at your registrar, not here. Left in place they point at an address that no longer answers for that name, which is worse than an obvious error: the browser will simply hang.