Runtimes & site profiles

A site profile decides how your repository is built and how the result is served. managed.dev resolves a profile during the detect stage of the build pipeline, then uses it to pick the build steps, the artifact shape, and the serve model — a long-running container or a static file tree behind the edge.

The platform is deliberately built runtime-agnostic. WordPress is the launch runtime, not the foundation: the core resources — site, environment, build, deploy, domain, TLS, backup, observability — are defined without any WordPress-shaped assumption. That discipline is what lets a new runtime inherit the entire platform — auth, jobs, streaming logs, observability, billing — for free. The API surfaces this as capability discovery: a client asks a site “what can you do?” rather than hard-coding if runtime == "wordpress". See capability discovery.

Profiles available today

bedrock

The bedrock profile is the git-deploy WordPress profile. It expects a Bedrock-style layout: a composer.json at the repo root, dependencies (including WordPress itself and your plugins/themes) managed by Composer, and configuration driven by environment variables rather than committed wp-config.php.

• Builds: composer install in the egress-restricted sandbox via the build proxy, plus any asset build your project defines.
• Served as: a container on the FrankenPHP runtime.
• Use it when: you want a real dependency-managed WordPress codebase in git, with plugins and themes pinned in composer.json.

vanilla

The vanilla profile serves a conventional WordPress tree — the layout you get from a standard install or an existing site migrated in — without requiring Composer. Your wp-content (themes, plugins, uploads) is the source of truth, and managed.dev provides the WordPress core and runtime around it.

• Builds: prepares the WordPress tree and any defined asset steps; no Composer dependency resolution is assumed.
• Served as: a container on the FrankenPHP runtime.
• Use it when: you’re migrating an existing site or prefer the classic WordPress layout over the Bedrock convention.

static

The static profile builds a site to a directory of static files and serves them directly from the edge — no PHP process in the request path.

• Builds: runs your build command (for example a static-site generator) in the sandbox and captures the output directory as the artifact.
• Served as: a static file tree behind the edge cache and automatic TLS.
• Use it when: the site is fully static — a docs site, a marketing page, or a JAMstack front end. A static site reports components.plugins, database, and magic_link as unsupported in capability discovery, because there is no dynamic application layer to act on.

How detection chooses

During the detect stage, managed.dev inspects the pushed commit and resolves exactly one profile from the repository shape:

Signal in the repo	Resolved profile
composer.json with a Bedrock-style layout	bedrock
A WordPress tree without Composer-managed core	vanilla
A build that emits a static output directory	static

Pin it explicitly

You can pin the profile in your repository’s managed.dev config rather than relying on detection — useful when a repo is ambiguous or you’re mid-migration. See config & secrets.

Serve models

Two profiles run as containers; one is served as static files. The serve model is what the platform attaches to your environment after rollout:

Profile	Build does	Serve model	Dynamic app layer
bedrock	composer install + assets	container (FrankenPHP)	plugins, themes, content, cron, DB
vanilla	prepare WP tree + assets	container (FrankenPHP)	plugins, themes, content, cron, DB
static	run build → static dir	static (edge)	none

The dynamic application layer is the part the API exposes as capability-gated sub-resources: plugins, themes, content, cron, and the database exist for the WordPress profiles and are structurally absent for static. That is the whole trick — a static site and a WordPress site are the same resource type with different advertised capabilities.

The wasm runtime: hosted functions

The runtime catalog — GET /v1/runtimes — already lists a third runtime alongside wordpress and static: wasm. It serves hosted functions: single-file WebAssembly functions that run on the platform’s isolated functions capacity, next to your sites rather than inside them. You manage them with the mf CLI — mf functions create, build, deploy, and rollback drive the functions API as async jobs, and mf fn dev builds and serves a function locally while you iterate.

Functions are an adjacent capability for the glue around a site — a webhook receiver, a small edge endpoint — not a way to host WordPress. The profiles a WordPress or static site resolves to remain bedrock, vanilla, and static.

Roadmap runtimes Preview

The runtime-agnostic core is built to take on more runtimes without foundation changes — the platform model already understands additional builders beyond WordPress.

Designed, not yet shipped

Drupal and Node runtimes are on the roadmap. Adding one requires no change to the foundational resources — only a runtime-catalog entry and the agent’s capability probe — so a new runtime inherits environments, builds, jobs, observability, and the API on day one. Treat these as forthcoming; today’s shipped profiles are bedrock, vanilla, and static.

When a runtime ships, clients discover it the same way they discover everything else: GET /v1/runtimes lists the catalog, and GET /v1/sites/{id}/capabilities reports what a given site can do. Code that drives the API through capability discovery picks up new runtimes with no rewrite.

Next steps

The build pipelineDetect → build → sign → roll, the path every push takes.

The FrankenPHP runtimeHow WordPress profiles are served — worker mode, throughput, HTTPS from the first request.

Capability discovery (API)Ask a site what it can do instead of branching on runtime.

Runtimes & capabilities referenceThe full runtime catalog and the capabilities each advertises.