Build & runtime settings
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.
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.