# Domains

How to make an environment answer on a domain of your own, with a certificate.


Without a domain of your own, an environment is reached on the address its provider gave it. An own domain comes with a plan, on any environment: production, staging or development. Without a subscription it is refused; see [Billing](/organisation/billing). To make an environment answer on your own domain:

```bash
brewless domain:add production shop.example.eu
brewless domain:add staging staging.shop.example.eu
```

You can do the same under **Domains** on the page of the environment in the console, or name the domains in your `brewless.yml`:

```yaml brewless.yml
environments:
  production:
    domains:
      - shop.example.eu
      - www.shop.example.eu
```

`brewless deploy` names each domain the environment does not answer on yet and asks before it adds them, under the same rules. Adding a domain can move its visitors: when its DNS zone is in your bunny.net or Scaleway account, the record is pointed at Brewless. Without a terminal, or with `--no-interaction`, nothing is added unless you pass `--domains`. A domain the file does not name is not removed; take it off in the console or with `domain:remove`.

## DNS

Where the record comes from depends on what stands in front of the environment.

**With bunny.net connected.** When the DNS of the domain is at Bunny DNS in your account, or at Scaleway DNS in your Scaleway project, the record is made for you, before the name goes on the pull zone, and Brewless takes over the zone for this environment if it did not manage it yet: it says so, and changes nothing else in the zone. At Bunny DNS the record leads straight to the pull zone. At Scaleway DNS it is a `CNAME` to the pull zone's address, and on the domain itself, where a `CNAME` may not stand, an `ALIAS`. A wildcard needs its zone at Bunny DNS: bunny.net only proves a wildcard through its own DNS. Its records are then on the [DNS records](/running/dns-records) page. bunny.net checks a wildcard's record before it takes the name; while it does not see the fresh record yet, Brewless tries again. When bunny.net refuses a name for another reason, the error gives bunny.net's own words. Is the DNS kept elsewhere? Point the name at the target the console shows with a `CNAME` yourself.

**Without bunny.net.** Point the name at the target the console shows with a `CNAME` at your DNS provider.

> [!NOTE]
> Adding a domain never changes a record that already leads somewhere else: it only creates records that do not exist yet. When one is in the way, the error names it, by id, type and value, with the `brewless dns:remove` command that removes it. To change such a record yourself, use [DNS records](/running/dns-records).

A name that points at a private address, such as `10.0.0.5` or `::1`, is refused: a domain of an environment is a name on the public internet. A name that has no address yet is fine; the DNS can come later.

## The test address

Next to the addresses its providers gave it, every environment gets a test address from Brewless, with each deploy: `<organisation>-<application>-<environment>` under Brewless's test domain, such as `acme-shop-production.brewless.dev`. It is a `CNAME` in Brewless's own zone that leads straight to the web container, so it works whether or not you have a domain of your own, and with or without bunny.net in front. Brewless attaches the name to the container with your Scaleway key, as it does any domain, and Scaleway issues its certificate once the record is live; that can take a few minutes after the first deploy. The console lists it as **Test address**.

With `brewless/laravel` 0.5.1 or later, your application answers the test address as if it were asked for the host of `APP_URL`, so an application that only answers on its own domain works there too, while the links and files on its pages stay on the test address. Every page on the test address tells search engines to stay away (`X-Robots-Tag: noindex, nofollow`), and its `robots.txt` disallows everything, unless your application has a `public/robots.txt` of its own: the web server hands out that file as it is.

Visitors of the test address go straight to your container, never through Brewless. When two environments would get the same name, the second one gets a short code at the end, and so does a name longer than DNS allows. A name under the test domain cannot be added as a domain of your own. When you delete an environment or let Brewless go of it, its record is taken out of the zone; the name on your container stays until you remove it.

## Your application's own address

When the domain is added and your application still calls the provider's address its own (`APP_URL` for Laravel), Brewless says so, and `brewless domain:add` offers to set it to the new domain. It is only changed after a yes, and takes effect with the next deploy. [Moving your domain to Brewless](/getting-started/moving-your-domain) walks through the whole move.

## Certificates

The provider issues the certificate once the DNS record is live, and renews it by itself, also when Brewless is not around.

Brewless reads when each certificate runs out and tells you when a renewal did not happen in time.