Getting started
How Brewless works
The parts of a Brewless setup, where each one runs and who is responsible for it.
On this page
A Brewless setup has three parts: your organisation at Brewless, your Scaleway project (or several) and, optionally, your bunny.net account.
Your organisation
An organisation is your team's place at Brewless, on its own address: <name>.brewless.eu. Its console shows your applications, their environments and their releases, and it is where you connect your providers and invite your team.
Applications and environments
An application is the thing you deploy: one codebase. An environment is one running copy of it, such as production or staging. Each environment has its own container, its own variables, its own domains and its own releases, and runs in the Scaleway region you choose for it.
Read more in Applications and environments.
Your providers
| Provider | What runs there | Required |
|---|---|---|
| Scaleway | Containers, the image registry, the database, Secret Manager, jobs and queues | Yes |
| bunny.net | DNS, CDN and Shield in front of your application | No |
Brewless works in these accounts with a key you hand it, each limited to one Scaleway project; an application runs in one of them. See Connecting providers.
What Brewless keeps
Brewless records what it needs to operate your application: releases, the steps of every operation at your providers, an audit trail of who changed what, per hour how long each container ran, how long it was scaled to zero and how long it can have kept the database awake, and per hour how long each serverless database was up, the vCPU time it was given and its size.
It deliberately does not keep:
- Values of environment variables. Only their names and revisions.
- Logs. They are read live from Scaleway and shown, not stored.
- Metrics. Requests, response times and replicas are read live from your providers. Only the hourly totals of serverless usage and of serverless databases are kept, never the samples.
- Output of commands you run in an environment.
- Tokens of the command line client and of pipelines. Only a keyed hash, so a token can be checked but not read back.
Work at your providers is recorded step by step
Every change Brewless makes at a provider is an operation made of steps. An operation survives a restart, and a step that failed can be tried again without repeating the ones before it. Nothing destructive happens to your resources as a side effect: removing something from Brewless leaves it running at the provider.