Domains

Every environment answers on a platform hostname from the moment it exists, and on your own domains once you have proved they are yours. Both are managed on the environment's Routing tab.

#The platform hostname

Each environment gets one, built from the environment's name and the project's:

production.gwfdxo99.vallic.cloud

It is created with the environment, already verified, and its DNS is ours. It cannot be removed or switched off, and it does not change if you rename the project — it is in certificates, bookmarks and other people's configuration by then, and a name that moves breaks all of them.

It is never put behind the CDN. That keeps it a direct route to the machine: when you are trying to work out whether something is broken, it is the address that does not depend on a cache.

#Adding a domain

Routing → Add domain. It asks for the hostname and, if something sits in front of us, which CDN that is (below).

A hostname is refused if:

Refused	Why
It contains *	Wildcards are issued by the platform, not added by hand
It is under vallic.cloud	Only the platform issues names there
It is already on this project, on any environment	One name routes to one place
Somebody else on the platform has already verified it	Whoever proves control first has it
It is an IP address	There is nothing to issue a certificate for

A hostname somebody else added but never verified does not block you. An abandoned claim is not a claim.

#Pointing DNS at us

When you add a domain, the tab shows the records to create, with the values filled in and a Copy button beside each. Copy them rather than retyping: the verification value is long enough that one wrong character reads as "not propagated yet".

Your domain	Record
A subdomain — www.example.com, shop.example.com	CNAME to the environment's CNAME target
An apex — example.com	A record to the environment's IPv4 address, or ALIAS/ANAME to the CNAME target if your provider offers it
An apex, with the platform CDN on	ALIAS/ANAME to the pull zone

The CNAME target is shown at the foot of the tab. It is the platform hostname, or the CDN's pull zone when the environment has one. It is a name rather than an address on purpose: replacing the machine, or putting something in front of it, is then one record we change rather than a message asking you to edit your DNS.

An apex cannot hold a CNAME — that is a rule of DNS, not of ours. Prefer ALIAS or ANAME where your provider has them, for the same reason: an A record names an address, and an address can change. Behind the platform CDN there is no address to give at all, so if your provider has neither, use a subdomain such as www and redirect the apex to it.

Only IPv4 addresses are given. There is no AAAA record to create.

#Proving it is yours

A domain does not route until it is verified. Until then it shows Awaiting DNS on the tab, and requests for it get nothing from us.

There are two ways to verify, and either is enough:

• The CNAME itself. Once the hostname's CNAME points at the environment's target, it is verified. Nothing else to do.
• A TXT record at _vallic-challenge. in front of the hostname — for www.example.com, at _vallic-challenge.www.example.com — holding the value shown on the tab.

The TXT record is what lets you verify before you move traffic. When you are bringing a live site across, publish the TXT, let it verify, check everything on the new environment, and only then change the CNAME — so there is no gap where the domain points at something that is not ready.

An apex can only verify by TXT. An A record points at a shared address, which proves the domain reaches us but not which environment you meant.

Check now on the row looks straight away, up to twelve times an hour per domain. A pending domain is also checked on a schedule without you pressing anything, and it keeps being retried until it verifies or you remove it. If a check fails, the row says why — no TXT record found, a TXT record with the wrong value, or the name already verified somewhere else.

Once verified, a domain stays verified. It is not re-checked, so you can remove the TXT record afterwards. It also means changing the domain's DNS to point somewhere else does not remove it from the environment — remove it here as well.

#The canonical domain

One hostname per environment is canonical, marked on the Routing tab. At first it is the platform hostname.

Make canonical on one of your own verified domains, and every other hostname the environment answers on — the platform hostname, the apex, www, an old domain you are migrating away from — redirects permanently to it, keeping the path. A site stops being reachable at two addresses, which is what search engines and absolute links both want.

There is no separate apex-to-www setting: that is this. Add both, make the one you want canonical, and the other redirects.

An unverified domain cannot be made canonical. Pointing every address at a name nobody has proved control of would take a working site off the air.

To stop redirecting, make the platform hostname canonical again — or remove your canonical domain, and the platform hostname takes the role back on its own.

#HTTPS

Everything is HTTPS. A request on plain HTTP is redirected permanently to the same address over HTTPS, on every hostname. The only exception is the path certificate authorities use to prove a domain, which has to be reachable on HTTP for a certificate to be issued at all.

You do not choose how a certificate is obtained. It follows from what is in front of the domain, and the row on the Routing tab shows which applies:

Shown as	Covers	Issued by	You need to
Platform wildcard	The platform hostnames	Us, one wildcard per project, renewed 30 days before it expires	Nothing
Let's Encrypt	Your domain, pointed straight at us	Let's Encrypt, on the machine, renewed automatically	Verify the domain and point it at us
Terminated at the CDN	Your domain, behind a CDN	The CDN	Nothing, if it is the platform CDN; your CDN's own certificate otherwise

A Let's Encrypt certificate is asked for once the domain is verified and resolves to us, and not before: the authority checks by connecting to the name, and a name that still points at your old host proves nothing. So there is a short window after you change DNS where the domain answers but its certificate is still arriving.

You cannot upload a certificate of your own, and you cannot add a wildcard domain. If you need either — an EV certificate your contracts require, or a thousand customer subdomains — talk to us before you build around it.

#Behind a CDN of your own

If your domain goes through Cloudflare, Fastly, Akamai, your own Bunny account or another proxy before it reaches us, say so under CDN in front when adding or editing it. Two things depend on it.

The certificate. A CDN in front answers the visitor's connection itself, so it is the CDN's certificate the visitor sees, and it also intercepts the check Let's Encrypt would use. We do not obtain a certificate for that name on the machine. Your CDN has to connect to us over HTTPS — plain HTTP is redirected to HTTPS, which a CDN following it will do in a loop — and it will not find a publicly-issued certificate for your domain at our end.

Who the visitor is. Behind a CDN every request reaches us from the CDN. The platform reads the visitor's real address from the header that network sets on every request: CF-Connecting-IP for Cloudflare, Fastly-Client-IP for Fastly. That address is what allow and deny lists are matched against.

The header is believed only from the CDN's own addresses. Anyone can connect to your site directly and send the header themselves, so it is read only on a request that arrived from one of the network's published edge ranges, which the platform fetches daily. A request from anywhere else is judged by the address it connected from.

Akamai publishes no list of its edges, and neither can a CDN we have no entry for, so for those the header is never believed: the rules see the CDN's own address. A block list behind them stops nobody and an allow list stops everybody. Bunny sets no header of its own either; with your own Bunny account you are in the same position.

With the platform CDN none of this is yours: the pull zone, its certificate and its header are set up for you, and the field is not shown.

#How many domains

Two custom domains per project are included, across all its environments — the name the site answers on, and the one somebody always wants beside it. Platform hostnames do not count. A domain awaiting verification does.

More are bought under Commercial terms on the project's configuration page, in two bands:

Custom domains	A month
Up to 9	€4 / £3.60 / $5
Up to 25	€8 / £7.20 / $10

Past 25, talk to us. Adding a domain past the count is refused with a message saying so, rather than quietly billed.

#Removing a domain

Remove on the row. The name stops routing on the next reconcile and its certificate is no longer renewed. Your DNS is not touched — records still pointing at us are yours to remove, and until you do, visitors get nothing useful from them.

The canonical domain cannot be removed while it is canonical; make another one canonical first. You can add a removed name back later.

#Who can do what

	Role needed
See the Routing tab	Viewer
Add, edit, check, make canonical	Developer
Remove	Admin

On a protected environment — production, unless you have changed it — every change needs the Owner. See Teams.

The API can list, add, verify and remove domains. Making one canonical and declaring a CDN are done in the console.

#Next

• The edge — what happens to a request once it has reached us
• CDN — putting the platform's CDN in front