Instance types & regions

Two settings decide a service's cost and its latency: the instance type it runs on, and the region it runs in. The instance type can always be changed. An app can change region, but a database stays in the region it was created in.

4 min read

Instance types

An instance type is a fixed amount of CPU and memory. Web services and cron jobs offer four:

Size	Resources	Suited to
Free	0.25 CPU · 256 MB	One per workspace, at no charge. Sleeps after 15 minutes without visitors and wakes on the next visit. Side projects and trying things out
Starter	0.5 CPU · 512 MB	Prototypes, low-traffic apps, `dev` environments
Pro	1 CPU · 1 GB	Production apps with steady traffic
Pro Max	2 CPU · 2 GB	Demanding, high-traffic workloads

The API calls these FREE, STARTER, STANDARD (Pro) and PRO (Pro Max).

A free web service sleeps after 15 minutes without visitors. The next visit shows a short "waking up" page and the app is serving again in under a minute. Paid sizes never sleep, so pick one for anything that has to answer at once, such as a webhook receiver or a queue worker.

Service settings showing the instance types with their resources and monthly prices, above the deployment region — Instance type and region both live on the service's Settings tab.

The current monthly price for each tier is shown on the cards, and in the summary panel while you are creating a service. That figure is the authoritative one, so quote it from the dashboard rather than from here.

Databases use their own tiers, including a small Dev size intended for non-production environments. See Managed databases.

Choosing a size

Memory is usually the binding constraint, not CPU. A service that is killed and restarted repeatedly under load is out of memory, not out of CPU.

Start at Starter for dev and uat.
Use Pro for anything taking real traffic.
Move to Pro Max when you can see sustained CPU near its ceiling, or memory headroom disappearing, on the service's overview.

Changing the instance type

Change it on Settings and save. The service restarts onto the new size, so there is a brief interruption while the new container starts and passes its health check, and no rebuild is required.

Scaling down below what the process needs will cause it to be killed shortly after starting. If a service becomes unstable right after a downsize, that is the cause.

Regions

A region is where the service physically runs. It matters for two reasons:

Latency to your users. A request from Lagos served from a Nigerian region avoids a round trip out of the country and back.
Latency to your data. A service and the database it reads should be in the same region. A query crossing regions pays the network cost on every call, and applications make many calls per request.

The region is chosen when you create a service, and the picker lists what is available to you. Your workspace's default for new resources is set under Settings. See Projects, environments & services.

Free services run in eu-west only. Upgrading a Free service to a paid size keeps it in eu-west, so to run in af-west (Port Harcourt), create the service there at a paid size. Apps, cron jobs, databases and caches cost 1.5× the listed price in af-west, and object storage costs 1.2×.

Changing region

A web service's region can be changed from Settings. The service is rebuilt and started in the new region, then traffic moves once it is healthy.

A database stays in the region it was created in, so choose its region first.

The private connection between an app and its database only works inside one region. Moving an app away from its database breaks that connection.

To move an app and its database to another region:

Create a new project in the target region.
Add a paid database and your app to it.
Download a backup of the old database, or take a dump with pg_dump, and restore it into the new database.
Check the new app works, then point your domain at it.
Delete the old project.

Anything written to the old database after the backup is not in the new one, so stop writes before you take it.