Build & buildpacks

Every deploy runs through a build. Static-from-Git projects build in a microVM and publish to the CDN; container projects build an image with Railpack or a Dockerfile and roll it out as a pod. This page covers how the build works, what it supports, and how to observe it.

Railpack

For container and auto-detected builds, PandaStack uses Railpack buildpacks. Railpack detects your framework and the language version and builds with no build or start command required — this is what makes the auto language and the one-click Deploy button work with zero configuration.

You select the build method with the language field:

Language	Build method	Required commands
auto	Railpack buildpacks (zero-config detection)	none
nodejs	Platform-generated Dockerfile	start command
python	Platform-generated Dockerfile	build and start
go	Platform-generated Dockerfile	build and start
docker	Your repo’s own Dockerfile	—

Static projects are exempt from command requirements — the framework’s default build command (npm run build) and its conventional output directory are used unless you override them.

Supported frameworks and languages

Railpack auto-detects and builds a broad set of languages and frameworks with zero configuration:

• Node.js (including Next.js, Nuxt, SvelteKit, Remix, and other JS frameworks)
• Python
• Go
• PHP
• Java
• Ruby
• .NET
• Deno
• Rust
• Elixir
• Static sites

For the frameworks the auto-detect classifier recognizes as pure client-side apps, the build output is published to the CDN as a static site with no pod. Everything else builds as a container.

Node version auto-selection

For Node.js projects, Railpack auto-selects the Node version. You do not have to pin it manually for a build to succeed — the buildpack picks a compatible version based on your project.

Dockerfile override

If you need full control over the build, commit a Dockerfile to your repo and set the language to docker. PandaStack builds the image from your Dockerfile exactly as written.

A root Dockerfile also affects auto-detection: it normally forces the project onto the container path. The one exception is a proven-static SPA whose Dockerfile is a provably-trivial dev-server one (FROM node, npm install, CMD npm run start), which is demoted to a static CDN deploy.

Build cache

Builds use dependency-layer caching: the dependency-install layer is split from the source layer in the generated Dockerfiles, so a redeploy that doesn’t change your lockfile reuses the cached dependency layer and builds faster.

Build source scanning

Before any build for a container, auto, or Git-static project, PandaStack runs a source scan over the repository to reject malware and abuse kits. A repo that fails the scan does not build.

Deployability check

Public-repo deployability is probed live against the GitHub API at deploy time (the stored is_public column is NULL on nearly every legacy project, so it is not trusted). Private repositories require a GitHub App installation token — connect GitHub under Integrations first.

Live build logs

Build logs stream live while the build runs — you see output as it happens, not only after the build finishes. If a build fails, the logs are where you find the error. Static projects that run no application server show build logs by default (there are no separate application logs to stream); container projects stream application logs after the build completes so you can watch the app boot.

The deploy backbone

Create and deploy write the Project and Deployment rows plus a transactional outbox row in one database transaction (topic deploy.requested). An outbox relay publishes the request to Google Pub/Sub, and the worker’s subscriber processes it. Deployment status moves through queued → running → succeeded (or failed).

Related

• Auto-detect deploys
• Container apps
• Static sites
• Environment variables & secrets — build-time inlining
• Deploy to PandaStack button