Regions
Where briqs run, how a team picks its region, and what runs underneath.
Where briqs run
Each team has a region, chosen when the team is created and changeable in Settings. Every briq is created in its team's region at that moment and stays there: changing the team region affects briqs created afterwards, never the ones already running, so a team can move house without a migration.
| Region | Zone | Data stays in the EU |
|---|---|---|
paris (default) | Europe | yes |
frankfurt | Europe | yes |
london | Europe | no (UK) |
virginia, oregon | North America | no |
montreal | North America | no |
singapore, tokyo, sydney | Asia-Pacific | no |
Region ids are places, not provider codes. Under the hood each provider maps a region to its own
nearest site; the list above is the set every provider we plan for can serve, so a region you
choose today is one we keep serving after an infrastructure change. GET /v1/me returns the
regions the running installation offers.
A briq's region is the region of its team at creation; stops_at, cost and endpoints work the
same everywhere. Private networking is per team and spans regions, so a team can, for example,
keep its database in Paris and run a worker in Singapore, and they reach each other by name.
What a briq actually is
| Layer | What it is |
|---|---|
| Isolation | A Firecracker microVM per briq. Not a container on a shared kernel; two customers never share a machine |
| Network | One private network per team, with DNS between briqs inside it. Optional per-stack isolation on Pro |
| Storage | One volume per briq, attached at create, in the same region as the briq |
| Exposure | Private by default. briq_expose allocates a URL on *.briq.run when you ask for one, public or token-protected |
| Lifecycle | Stop keeps the root filesystem at the storage rate; destroy removes the machine and its volume |
| Metering | Per second while a briq runs, computed from our own state transitions and reconciled against infrastructure usage |
How briq is built underneath
briq is a control plane over a provider adapter. The adapter interface is deliberately small: create, wait for readiness, exec, logs, stop, start, destroy, volumes, expose, list. Everything above it, the API, the MCP tools, the recipes and the CLI, is written against that interface rather than against any particular infrastructure.
That is what makes capacity a deployment decision rather than a rewrite, and it is why the answer to "what are you running on" can change without anything in your integration changing.
What comes next
- Our own Firecracker fleet on bare metal in EU data centres: lower cost per machine-hour, faster boots, and full control of the network layer. The region list above was chosen so that EU regions land on EU-incorporated operators when that ships.
- More sizes per region, including
largeoutside Paris.
Status
Live status at status.briq.run.