Supported Frameworks

Every Web Application and Background Worker declares a framework: the language or stack your code is written in. The framework selects the buildpack that turns your source into a runnable image — there is no Dockerfile, and no build happens without one, so the platform rejects any attempt to create an app without a supported framework with a validation error.

The framework list

These are the frameworks offered in the dashboard’s Create Resource form. The CLI value is what you pass to --framework.

Framework	CLI value	Builds
Ruby on Rails	`rails`	Ruby / Rails applications
Node.js	`nodejs`	Node.js applications
Python	`python`	Python applications
Go	`go`	Go applications
Rust	`rust`	Rust applications
Static Files	`static`	Static sites (HTML, CSS, JavaScript), served by nginx

Each build needs a few files at the app’s root; without them it fails right away:

Python — a Procfile naming at least a web (or worker) process — see Procfile.
Rust — Cargo.toml and Cargo.lock. Each [[bin]] target becomes a process type you can pick with the app’s Process setting.
Node.js — package.json.
Ruby on Rails — Gemfile and Gemfile.lock.
Go — go.mod. The main package becomes the web process, so a single-binary app needs no Procfile; add one to run something else.
Static Files — your site’s files in a public/ directory, with public/index.html as the home page. They’re served by nginx on $PORT. A static site has no /health page, so set the Health Check Path to / (new static web apps default to this when no explicit path is provided).

The framework does not have to match a specific web framework by name — a plain Express, Flask, or Axum app is just nodejs, python, or rust. Pick the language your code runs in; Static Files is for sites that are just files to serve, with no server-side runtime of their own.

Why it is required

The build pipeline uses the framework to choose which buildpack builds your commit. Without a valid framework there is nothing to build with, and the app would sit in a provisioning state forever waiting for an image that never arrives. The platform fails fast instead: creating or updating a Web Application or Background Worker without a supported framework is rejected with a validation error:

framework is required for web_app/worker resources (supported: nodejs, rails, python, go, rust, static)

A value that isn’t on the list at all — a typo like node — is rejected before that check, naming the field and the values it accepts:

Invalid JSON: Failed to deserialize the JSON body into the target type: framework: unknown variant `node`, expected one of `rails`, `nodejs`, `python`, `go`, `rust`, `static` at line 1 column …

Use the CLI values in the table above.

Setting the framework

In the dashboard, the Create Resource form shows a Framework dropdown whenever you pick the Web Application or Background Worker type. Choose one before creating the app.

With the CLI, pass --framework to paas apps create:

paas apps create web \
  -o acme -p shop -e production \
  --framework nodejs \
  --port 3000

You can change it later with paas apps update, for example if you rewrote the service in another language:

paas apps update web -o acme -p shop -e production --framework rust

The new framework takes effect on the next build.

Language version selection

The framework selects a builder; version declarations in your repository select its runtime. See Selecting Runtime Versions for exact pins, ranges, defaults, Ruby lockfiles, Go toolchain selection, and Rust channels. The Runtime Versions catalog separates downloadable releases from upstream maintenance and d2o verification.

Static Files can also build frontend assets with npm or Yarn before serving them. Its build-time Node.js inventory differs from the Node.js application builder. Go applications build directly from Go modules.

Next steps

Runnable examples

The language tutorials cover all six frameworks, with source downloads, dependency locks, health endpoints, database adapters, workers, and storage.

Keyboard shortcuts