Moving your domain to Brewless

After the quickstart, your production environment answers on the address its provider gave it, such as acme-shop-production.b-cdn.net. This page moves your own domain over to it. The steps below assume bunny.net is connected under Providers; without it, the domain goes straight on the Scaleway container and you make its DNS record yourself.

1. Where the DNS of your domain lives#

At Bunny DNS, in the bunny.net account you connected. You do not have to do anything first. When you add the domain, Brewless takes over the zone that holds it for this environment, as the Resources page would, and says so. Taking it over changes nothing in the zone: from then on its records are listed and changed with the DNS records page and the dns: commands.

At Scaleway DNS, in the Scaleway project you connected. The same: Brewless takes the zone over and makes the record there. On the domain itself that is an ALIAS to the edge, because a CNAME may not stand there; on a name under it, a CNAME. A wildcard is the exception: it needs its zone at Bunny DNS (see step 3).

Anywhere else. Brewless cannot make the record. brewless domain:add prints the CNAME the name needs, and the console shows it under Domains; make it at your DNS provider. The certificate follows once the record is live.

2. Records in the way#

Adding a domain never changes a record somebody else made. When the name already has an address record (A, AAAA, CNAME or a link to another pull zone) that leads somewhere else, adding the domain stops and names that record, with the command that removes it:

example.eu already has an address record in your zone example.eu at Bunny DNS:
the CNAME record 4711, which leads to fbd90ff3._domainkey.example.eu. ...
remove it with `brewless dns:remove example.eu 4711 --force`

Look at the record before you remove it. Often it is the old address of your site, which is what you are replacing; sometimes it is a mistake, such as a DKIM key typed onto the domain itself instead of under _domainkey. Brewless keeps no copy, so a removed record is gone. Then add the domain again.

dns:remove asks before it removes. With --no-interaction it cannot ask, so it fails unless you pass --force.

3. Add the domain#

brewless domain:add production example.eu

An own domain comes with a plan: without a subscription Brewless refuses it and points to the Billing page. The client follows the three steps: the DNS record is made, the domain goes on the pull zone, and the certificate is issued. The certificate waits until the DNS points at the edge, so a zone kept elsewhere can take a while. Add every name visitors use, such as www.example.eu, the same way. A name with a wildcard, such as *.example.eu, needs its zone at Bunny DNS in the account you connected: bunny.net checks its record before it takes the name and issues its certificate through that zone.

4. Your application's own address#

Setting the environment up gave your application the edge's address as its own: APP_URL for Laravel. It keeps that value until you change it, and Brewless never changes it by itself. Until it names your domain:

• links your application builds with that variable still point at the edge's address, and
• an application that only serves its own address (one that answers 404 on any other host) answers 404 on your new domain.

When the domain is added and APP_URL still names the provider's address, domain:add says so and offers to set it to the new domain. Only after a yes is it set, in your variables, for the next deploy. You can also change it on the Variables page of the console, or with brewless env:pull and brewless env:push. When your brewless.yml sets APP_URL under variables, change it there instead: Brewless leaves a variable the file sets alone, and the next deploy applies the file's value.

The hostnames your application believes behind the edge, BREWLESS_DOMAINS for Laravel, are kept in step by Brewless: every deploy gives the web container the edge's address, every domain of the environment and whatever your variables already list. You do not change it when you add a domain.

5. Deploy#

brewless deploy production

A deploy is what puts a new APP_URL and the new hostnames in the web container. Before the release goes live, Brewless asks your health route the way the edge does, as a visitor of your domain. Once it answers healthy, the edge's cache is emptied, so nobody is served a page cached before, such as the page of the base image the environment started on. The worker follows last, with the new release.

While APP_URL still names the edge's address and the environment has a domain of its own, the deploy says so at the end.

When going live fails#

The previous release keeps serving in every case below. What the message says points at the cause: