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, and a Private Network and a cache when you ask for them | 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. The one value it keeps, encrypted, is the key your application signs its requests for databases per tenant with, to check those signatures.
- 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 hash (SHA-256), so a token can be checked but not read back. A token is 64 random characters, which no one can work out from its hash. Beside it: its name, which application a pipeline token deploys, when it expires and when it was last used.
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. The one thing Brewless removes at a provider is a database your application asked it to remove through databases per tenant.