How the plans differ technically #

View this page as Markdown

Free, Standard, and Pro run your application the same way, with one difference in where production runs. Free and Standard production run on shared compute: a container of its own, on servers that also run other applications' containers. Pro production runs in its own container on the hosting platform, apart from every other application.

This page compares the three plans for a developer: isolation, the start after idle, CPU and memory, scale, database connections, schedules, and outages. Plan and usage covers prices, included quantities, and the steps of a plan change.

Where the figures come from #

Each figure names in parentheses the pricing entry it comes from. read_plan_quotas returns the entries it serves, such as free-idle-stop and database-connection-limit, and this page states the others.

A figure marked estimated comes from the platform's own measurements, not from a measurement of your plan's compute. The measured figures replace the estimates when the platform publishes them.

Where production runs #

Free Standard Pro
Production runs on Shared compute Shared compute Its own container
grain in read_status pod pod container
Kept apart from other applications by Its own container, with its own CPU and memory bound, files, and network rules, on servers it shares The same as Free Its own container on the hosting platform, isolated from other applications at the kernel
The process runs as User ID (uid) 1000, with HOME set to /tmp The same as Free Root, because the image names no user
Kept running while idle No. It stops after 1,800 seconds, 30 minutes, without a request (free-idle-stop). Yes. One copy always runs (warm_floor 1). Yes. One copy always runs (warm_floor 1).

On shared compute, applications share the servers' operating system kernel, and the hosting platform keeps each container's processes, files, memory, and network apart. In both forms your application's files under /app belong to uid 1000.

Free or Standard production runs on shared compute where the platform has shared compute open to new environments with room left. Where none is open, it runs in its own container, and read_status shows container. A deploy to shared compute that is full is refused 409 group_full.

A development environment runs on shared compute on every plan, in the same way. Where each environment runs says more.

Start after idle and response time #

Free Standard Pro
Production after 30 idle minutes Stops. The next request waits while it starts. Keeps running Keeps running
Typical response (response-time-typical) A start after idle of 2.6 to 3.3 seconds, or about 1.8 seconds where the server already holds the application's image. Estimated. 173 to 176 milliseconds at the 95th percentile, through the platform's edge, read on its own container. Estimated. 173 to 176 milliseconds at the 95th percentile, through the platform's edge. Estimated.
Worst case (response-time-worst) About 18 seconds, where the server must first fetch the application's image. Estimated. About 18 seconds, only where its running copy restarts on a server without the application's image. Estimated. A new container's start, 2.9 seconds at the median. Estimated.

Free's response while its copy runs is Standard's. The Standard figures were read before Standard production moved to shared compute, whose own figures replace them when measured.

A development environment on Free or Standard stops after the same 30 idle minutes. On Pro it stops after 24 hours without a request (development-warm-hours). A stopped development environment starts again on the next request, the next scheduled run, or a deploy.

CPU and memory #

Free Standard Pro
CPU (production-replica-size) 0.25 virtual CPU (vCPU) 0.25 vCPU 0.5 vCPU
Memory (production-replica-size) 0.5 GiB 0.5 GiB 1 GiB

The CPU figure bounds each instant. A process that asks for more CPU is slowed to the bound and keeps running. A process that passes its memory bound is ended, and the platform starts it again.

The figures are bounds, and nothing is reserved for any plan. On every plan the copy uses up to its bound where the servers have the CPU and memory free. Where copies on shared compute contend for CPU, a Standard copy gets twice a Free copy's share. Where a server runs short of memory, it stops a development copy first and a Standard copy last.

A development environment in its own container has 0.25 vCPU and 0.5 GiB on every plan. On shared compute it takes the platform's development settings, at most 1 vCPU and 0.5 GiB.

Scale #

Every plan runs one copy of each environment, and two only while a deploy, a promote, or a plan change replaces it. No plan adds copies under load. More CPU and memory for an application comes from a move to Pro, whose copy has twice Free's and Standard's.

A plan change between Free or Standard and Pro moves production between shared compute and its own container. A change between Free and Standard moves it within shared compute, to the new plan's own part of it. There it takes the new plan's CPU share and place when a server runs short of memory. Either way the platform starts the new copy, checks its health, and switches requests to it, as a promote does. The running copy serves until the switch, so the move costs one start of the new copy, made before it takes requests.

Change the plan gives the refusals a move can meet.

Database connections #

Free Standard Pro
Connections each process may hold open (database-connection-limit) 1 2 10
Connections the database role admits 2 4 20

The role admits twice the figure, so that a deploy's old and new copies can both connect. Your application connects straight to the server, with no pooler between them. The server refuses a connection over the role's limit with the PostgreSQL error too many connections for role.

Set your client pool's maximum to the figure, which every copy receives as APP_DATABASE_CONNECTION_LIMIT. The connection limit explains the rest.

Schedules #

Free Standard Pro
Shortest interval between runs (schedule-minimum-interval) 15 minutes 1 minute 1 minute
Schedules per application (schedule-count-limit) 2 10 25

A scheduled run is one request, with a window of 230 seconds by default against an ordinary request's 180 seconds. Both windows are the same on every plan.

A run that finds an environment stopped starts it first, and the start counts inside the run's window. A Free schedule due every 15 minutes keeps its environment running, because each run arrives before the 30-minute stop. Run scheduled work gives the rest.

Outages and platform updates #

The same holds on every plan:

  • An update to the platform's base image. Your running version keeps the base image and the platform's runtime it was built on until your next deploy, so an update restarts nothing. harness_current in read_status shows a version built on an earlier runtime.
  • A zone failure. Each environment runs one copy, in one zone of the region. Where that zone fails, the copy stops until the hosting platform starts it again in another zone. The recovery time is published when measured.
  • A database failover. A failover switches a production server to its standby, and it ends every open database session. In two measured failovers the server answered nothing for 36 and 68 seconds, and a failover can take up to 120 seconds. The Database package's failover pool keeps the process serving through it.

What shared compute changes for your code #

  • The console. On shared compute, read_logs with the source container reads the copy's console, which lasts as long as the copy. Once Free production stops when idle, its console lines are gone. What your code writes through the Logging package stays in the logging service's store on every plan (How log records arrive).
  • WebSockets. Where the platform does not serve upgrades on shared compute, an environment whose grain is pod refuses each upgrade 400 websockets_not_yet_served. Pro production serves them in its own container (Use WebSockets).
  • Deploy time. A deploy to shared compute is typically quicker than one to its own container, as Read the status gives.

What every plan has the same #

  • The artifact: the same zip, manifest, image, and Node.js 24 runtime, built the same way.
  • The two environments, development and production, with promote and roll back.
  • The platform's settings, its network controls, and its request limits.
  • A database for each environment, on the platform's shared servers, and the storage areas.
  • The logging service's store and counters.

Beyond compute, the plans differ in their quantities, such as stored data and backend actions, which What a plan includes lists. Pro also supports a domain of your own and email sends.