Skip to main content
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 regional pool static outbound IPs use, if you enable that feature.
  • The price of compute (CPU and memory) and storage. Some regions use a higher rate than the base.

​
Region tiers

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.

​
Compute and storage pricing per region

CPU and memory use Brimble’s metered compute pricing (1pervCPU−month∗∗and∗∗1 per vCPU-month** and **1 per GB-month at the base rate). Most regions bill at that base. A few regions apply a multiplier (for example 1.45×), so the same size costs more there. Storage is also multiplied by a per-region factor where applicable. The dashboard shows the effective rates for the region you select during project creation and when you change size. Use that display as the source of truth for the region you pick.

​
Outbound IPs

By default, outbound traffic does not use a published, fixed address. The source IP can change if the project is rescheduled onto another host. Don’t allowlist that address, and don’t ask support for a default range, we don’t publish one. If you need a stable allowlist for a bank, payment processor, or partner API, enable Static outbound IPs. That feature is regional: Europe is live; Africa, the US, and Asia are not yet.
Last modified on October 16, 2026