Running your application
Domains
How to make an environment answer on a domain of your own, with a certificate.
On this page
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. To make an environment answer on your own domain:
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:
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 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:removecommand that removes it. To change such a record yourself, use 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 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. Every answer on the test address tells search engines to stay away (X-Robots-Tag: noindex, nofollow), and its robots.txt disallows everything.
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 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.