Going further

Deploy a Node or Next.js app

Getting a Node.js or Next.js app live — and shipping every change after that with a safety net. The short version: connect a repository, push, and we build in isolation, run your release step, and only swap the new release in once it passes a health check. A bad deploy rolls itself back.

Every deploy runs the same pipeline: build → release → start. The build happens in a throwaway, network-isolated container and produces an immutable release image. Your release command (a database migration, for example) runs next — and if the app has databases attached, we snapshot them first. Then the new release has to pass a health check on your health path before it takes any traffic; if it fails, the previous image, env, and that database snapshot are restored automatically.

The static preset skips the runtime entirely. A build step is optional: we run one when you've set a build command or your package.json has a `build` script, and otherwise we publish the repository exactly as it is — a repo of plain HTML and assets needs no build and no package.json at all. Env vars are injected at build time, which is where NEXT_PUBLIC_-style values bind. The output is published as plain files served straight from the edge, releases swap atomically, and a bad build can never replace the one currently being served — rollback is an instant symlink flip. A static app is always the Front tier.

Connect a repository
Point us at a GitHub, GitLab, Bitbucket, or Codeberg repo — connect the GitHub app for push-to-deploy, or use a read-only deploy key. Pick a preset — Next.js, a custom service, or a static site — and a branch. For a repo the connected GitHub app can see, the branch field is a dropdown of that repo's real branches; otherwise you type the branch name.
Set your commands
The Deploy configuration card on the app's Overview shows the build, release, and start commands — view and edit them anytime; changes apply on the next deploy. On the Next.js preset the start command is managed for you.
Push — or click Deploy
Every push to your branch ships automatically, and a manual Deploy button is always there. To read what a build actually did, open the Deploys tab and click a release — the row expands to show that build's output. If a deploy fails you also get an email with the reason and a link straight to those logs.
Roll back in one click
The newest three releases stay on the node — roll back to any of them instantly. For container apps the same health gate and auto-restore protect the rollback; for a static site it's an atomic symlink flip back to the previous release.

Environment variables

Set them on the app's Env vars tab, where they're stored encrypted — or over SSH, on a full-stack app. Server-side values are read at runtime, so Save & apply restarts the app with them, health-checked. Next.js NEXT_PUBLIC_* values are the exception: Next.js bakes them into the browser bundle when the app is built, so changing one rebuilds the app instead — automatically, from the same Save & apply. On a static site every variable lives in the build, so Save & apply rebuilds it.

Database migrations without the fear

Run your migration (e.g. prisma migrate deploy) as the release command. Attached databases are snapshotted before it runs, and a failed dump aborts the deploy before anything destructive happens. If the new release then fails its health check, that snapshot is restored — so a broken deploy unwinds the schema change along with the code.

What an app costs

Two flat tiers, set automatically by what the app uses: a front-end with no database services is 15/app/mo; attach a managed Postgres, MySQL or Redis and it's 39/app/mo full-stack, with daily off-site backups of those databases and SSH into the app included. Detach every service and it drops back. No usage meters on either tier.

Health-gated deploys, instant rollback, and a managed database — flat per app, no meters.

Node & Next.js hosting →

← All guides