Skip to main content

Documentation Index

Fetch the complete documentation index at: https://paper.brimble.io/llms.txt

Use this file to discover all available pages before exploring further.

A region is the physical datacenter where your project runs. You pick a region when you create a project. Pick the one closest to your users.

Why region matters

Latency between your users and the region they hit is the single biggest controllable factor in app responsiveness. A user in São Paulo hitting a project in Frankfurt pays around 200ms in network round-trip before your code does anything. If your users are in one place, deploy there. Region also determines:
  • Where the project’s database and disk live.
  • Which IP range outbound traffic comes from (relevant if you whitelist Brimble at a third-party API).
  • The price of storage. Storage cost is multiplied by a per-region factor.

Region tiers

TierAvailable onDescription
FreeFree plan and upLimited selection. Suitable for side projects and testing.
PaidHacker, Pro, TeamWider selection across continents.
The dashboard marks paid regions clearly during project creation. You can’t deploy to a paid region from the free plan.

Available regions

Brimble has regions across:
  • Europe, including Frankfurt, Helsinki, and Nuremberg.
  • Asia, including Singapore and Tokyo.
Region codes follow the pattern <city><sequence>, for example fra1, nyc1, lhr1. The dashboard shows the city, country, and region code side by side when you create a project.

Picking a region

Rules of thumb:
  • Single market. Pick the region geographically closest to your users.
  • Multi-region traffic. Pick the region closest to the largest user concentration. For two roughly-equal markets, weigh the latency cost on each side.
  • Database co-location. Always put a project’s database in the same region as the project that uses it. Cross-region database calls add round-trip latency to every query.
  • Compliance. If you have data-residency requirements (GDPR, regional privacy laws), pick a region inside the relevant jurisdiction.
The dashboard pre-fills a default region based on your account location. Override if your users are elsewhere.

Region status

Each region is in one of three states:
  • Active. Accepting new deployments.
  • Degraded. Accepting deployments, but performance may be reduced. See status.brimble.io for active incidents.
  • Maintenance. Temporarily not accepting new deployments. Existing deployments continue serving.
If a region is in maintenance and you create a project there, the first deployment stays pending until the region is back. You can move to a different region instead.

Change a project’s region

You can change a project’s region at any time from the dashboard:
  1. Open the project.
  2. Click Configuration.
  3. Find the Region dropdown.
  4. Pick the new region. Click Save.
Brimble redeploys the project in the new region on save. Custom domains, environment variables, and project settings carry over automatically. The default <project>.brimble.app hostname keeps working through the move. For database projects the move involves migrating the underlying volume, which Brimble does as part of the redeploy. Larger volumes take longer; expect a brief connection interruption while the new instance comes up.

Storage pricing per region

Storage cost is multiplied by a per-region factor. Most regions are at the base rate; a few high-cost regions carry a small multiplier. The exact rate per region appears during project creation and on the project’s billing page.

Outbound IP ranges

Outbound traffic from your project comes from a region-specific IP range. If you’re whitelisting Brimble at a third-party API, request the current ranges from support, since they aren’t fixed forever.
Last modified on May 9, 2026