# Moving your domain to Brewless

From a first release on the edge's address to your own domain: the DNS zone, records in the way, APP_URL and the deploy that puts it live.


After the [quickstart](/getting-started/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](/running/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:

```text
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

```bash
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

```bash
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:

| The message says | What it means |
| --- | --- |
| The web container did not start, and Scaleway says why | The container stopped while starting, such as on a port nothing listens on. The rest is in `brewless logs production`. |
| The health route answered 404 when asked as your domain | Your application does not serve that host. Check that `APP_URL` names it, then deploy again. |
| The health route answered another status | Your application failed on it. The error is in `brewless logs production`. |
| The health route gave no answer within 15 seconds | Your application did not answer in time. Brewless asks again for a few minutes. |