Applications
Leaving Brewless
How to export an environment with Terraform and detach it, and what keeps running when you do.
On this page
Everything Brewless deploys runs in your own accounts. Leaving is therefore a matter of taking Brewless away, not of moving your application.
Export
An export is everything Brewless knows about an environment, written as files.
brewless export production
The console has the same under Resources, Download the export, as one file.
| File | Contents |
|---|---|
environment.json |
The application, its framework, the environment and its region |
resources.json |
Every resource Brewless manages for it, with its identifier and settings |
domains.json |
The domains it answers on and how they are routed |
releases.json |
The latest releases, each with its commit and image |
variables.json |
The names of its variables and the secret that holds their values |
main.tf |
Terraform that takes the resources over as they are |
README.md |
What is in the folder and how to deploy without Brewless |
No value of a secret is in an export. The values are in your own Secret Manager.
Exporting changes nothing. You can do it as often as you like, also just to see what Brewless holds.
The Terraform
main.tf has, for every resource, a block that imports it and a block that describes it. With your own keys in the environment:
export SCW_ACCESS_KEY=... SCW_SECRET_KEY=... BUNNYNET_API_KEY=...
terraform init
terraform plan
The plan imports every resource and wants to change nothing. Two things are left out on purpose:
- The image and the variables of a container. A deploy changes them, not Terraform, so a later plan does not want to undo a release.
- The settings of a pull zone. It is taken over as it is. Terraform leaves it alone until you describe its settings yourself and remove the line that says so.
- A zone at Scaleway DNS. It is imported by its full name and taken over as it is, with its records; Brewless does not keep how Scaleway splits the name into a domain and a subdomain.
Detach
Detaching ends what Brewless does for an environment.
brewless detach production
In the console you type the name of the environment to confirm. A last export is made first.
| Stops | Stays |
|---|---|
| Deploying and rolling back through Brewless | Your containers and what they serve |
| Scaling through Brewless | Your database and its data |
| Watching for changes made elsewhere | Your domains and certificates, which your providers keep renewing |
| The test address: its record leaves Brewless's zone | |
| The trigger that calls your worker every minute | |
| Your secrets, in your own Secret Manager |
Nothing at your providers is touched. The environment, its releases and the audit trail stay in Brewless as a record of what happened.
Detaching waits for work that is under way: while a deploy is running, it is refused.
Note
The keys of your providers belong to your organisation, not to one environment. They stay connected while Brewless manages anything else for you. When it manages nothing any more, disconnect them under Providers, and delete the key at the provider itself to end its access for good.
Deploying without Brewless
A release is three plain calls to your provider, described in the README.md of the export:
- Build an image and push it to your registry.
- Give the release container that image and call its release route with your ops secret. That runs your release commands.
- Give the web and worker containers the same image.
The command line client and the package that answers these calls in your application are open source.
Coming back
Adopt the resources again on the Resources page of the environment. See Applications and environments.