---
title: How the plans differ technically
description: Compare Free, Standard, and Pro as a developer: where production runs, its start after idle, its CPU and memory, its scale, and what stays the same.
slug: /concepts/how-the-plans-differ-technically
order: 22
visibility: public
redirects_from: []
---

# How the plans differ technically

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](/guides/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](/concepts/applications-and-environments#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](/guides/plan-and-usage#2-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](/guides/add-a-database#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](/guides/author-the-manifest#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](/backend-packages/database#the-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](/concepts/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](/guides/use-websockets)).
- **Deploy time.** A deploy to shared compute is typically quicker than one to its own container, as [Read the status](/getting-started/deploy-an-application#5-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](/guides/plan-and-usage#what-a-plan-includes) lists. Pro also supports a domain of your own and email sends.

## Related

- [Plan and usage](/guides/plan-and-usage) changes the plan and reads the month's usage.
- [Applications and environments](/concepts/applications-and-environments) explains where each environment runs.
- [Add a database](/guides/add-a-database#the-connection-limit) explains the connection limit.
- [The settings a deployed copy receives](/concepts/the-settings-a-deployed-copy-receives) lists the settings and the user each copy runs under.