Docs · Get started

Builds, previews & rollbacks.

What actually happens between git push and your app being live — and the levers you have when something goes sideways.

How a build runs

Every deploy builds in an isolated sandbox: its own Linux user, its own memory budget (capped per plan — see the limits), no access to other tenants or platform services. Dependency install scripts are disabled by default for supply-chain safety; if a package genuinely needs its build script (e.g. sharp), allow it explicitly with a canner.allowedBuildScripts entry in your package.json. Your node_modules and framework caches (like .next/cache) persist between builds, so rebuilds are fast.

The build log streams live in the dashboard. When the build succeeds, the new version starts, must answer the health check (respond on / — or your configured path — within 30 seconds), and only then takes over traffic. A failed health check leaves the previous version serving.

Preview deploys

With GitHub connected, every pull request gets its own isolated preview at branch--project.app.canner.ca, rebuilt on each push to the branch and cleaned up when the PR closes. Previews share the project’s environment variables but never its production process.

Retry, cancel, roll back

  • Retry re-runs a failed build from the same commit or upload — useful after fixing an env var or when a registry hiccuped.
  • Cancel stops a queued or running build.
  • Rollback re-activates any previous successful deploy instantly — the old bundle is still on disk, so there is no rebuild. Find it on the Deployments tab.

Sleep and wake on the free plan

Starter apps sleep after 3 hours without a request. The next visitor wakes the app automatically — they wait a few seconds while it boots, then everything is normal. Paid plans (Live and up) keep apps always on, which is the thing to upgrade for when a real audience depends on your site.

Logs

The Logs tab streams your app’s runtime output (stdout/stderr) live. Build logs live with each deployment on the Deployments tab. If your app crashes on boot, the health-check failure message in the build log includes the tail of the runtime log — that’s the first place to look. For what specific messages mean, see common build & deploy errors.