Build & runtime settings
Control how a service builds and runs — root directory, commands, release command, and plans.
Most services deploy fine on defaults, but Helicarrier gives you precise control over how your code builds and runs when you need it. These settings live on the service’s build/settings panel.
Build settings
Section titled “Build settings”- Root directory — the subdirectory to build. Point this at a package inside a monorepo (for example,
apps/web) and the build runs there. - Install command — override the detected dependency install step (for example,
pnpm install --frozen-lockfile). - Build command — override the detected build step (for example,
npm run build). - Start command — the command that launches your app (for example,
node dist/server.js). - Dockerfile path — if you build from a Dockerfile that is not at the repo root, point at it here.
When these are left blank, Helicarrier detects sensible defaults for your framework.
Release command
Section titled “Release command”A release command runs once before a new version starts taking traffic — after the image is built, before the rollout completes. It is the right place for database migrations and other one-time pre-launch steps. If the release command fails, the deploy stops and the current version keeps serving, so a bad migration never takes your app down.
Choosing a plan
Section titled “Choosing a plan”On Helicarrier Cloud you size a service by picking a plan, not by hand-setting raw CPU and memory numbers. Each plan reserves a fixed amount of RAM and sets the service’s monthly price — the service’s plan picker shows a live monthly total as you choose.
Compute services (web, worker, private) use the Heli S plans:
| Plan | RAM | Price |
|---|---|---|
| Heli S1 | 512 MB | $3 / mo |
| Heli S2 | 1 GB | $6 / mo |
| Heli S3 | 2 GB | $12 / mo |
| Heli S4 | 4 GB | $24 / mo |
| Heli S5 | 8 GB | $48 / mo |
How the plan maps to resources:
- RAM is reserved — a hard guarantee. Pick the plan that fits your app’s memory footprint; if it consistently exceeds the plan’s RAM it can be restarted, so size up if you see out-of-memory restarts.
- CPU is shared and burstable — compute services share CPU and burst when the host has headroom, so you are not billed per core. Need guaranteed CPU? Add the dedicated CPU add-on (guaranteed vCPU, billed on top of the plan).
- You can change a service’s plan any time from its settings.
Managed databases have their own plans (Heli DB, CH, KV) that reserve CPU (so a database is never CPU-starved) and add storage — you pick one when you provision. See Provision a database.
Read-only filesystem
Section titled “Read-only filesystem”Under Settings → Build, Read-only filesystem runs your service with its root filesystem
mounted read-only. /tmp (512 MB) and /run (64 MB) stay writable as in-memory scratch space;
everything else in the image is immutable at runtime.
Why you might want it: a process that is compromised cannot modify your application’s files, and a bug that writes without bound cannot fill the disk. Why it is off by default: some images write to their own filesystem — a cache directory, uploaded files, a SQLite database next to the code. Those break under a read-only root. The fix is to put that data on a volume, which is where it belongs anyway, and then turn the option on.
It takes effect on the next deploy. Managed databases do not offer it; their storage is capped separately.
Build-time environment variables
Section titled “Build-time environment variables”Some frameworks bake variables into the client bundle at build time (NEXT_PUBLIC_*, VITE_*, REACT_APP_*). Helicarrier makes your variables available during the build so these are embedded correctly. References to other services resolve to their internal addresses at build time. See Environment variables for how to set them.
- Understand the rollout and how to undo a bad deploy in Deploys & rollback.
- Add the variables your build and runtime need.