Core concepts

Everything in managed.dev — the dashboard, the SSH gateway, and the public API — is built on one object model. Learn these terms once and the rest of the docs read cleanly. Each definition below links to its deep-dive page.

The objects

Account — your personal identity on managed.dev. An account holds your login, your personal API keys, and your membership in one or more teams. It is a person, not a billing entity.

Team — the unit of ownership, billing, and access control. A team carries a plan, members with roles (owner, admin, site_manager, observer, billing), an audit log, and all of its sites. Service tokens (mfs_live_…) act as a team.

Project — a folder for grouping a team’s sites — for example, one project per client or per product line. Projects organize the sites list and scope access; they don’t change how a site runs.

Site — a single WordPress (or static) property: a codebase, its environments, its domains, and its observability. Every site carries a runtime that determines what operations are possible against it.

Environment — a first-class, isolated copy of a site: production, staging, or preview. Each environment has its own database, its own files, and its own observability — a preview is a real clone of production, not a config flag. This is the object you push branches to and promote between. See environments overview and preview environments.

Runtime & site profile — the runtime describes what kind of application a site is (wordpress, static, and on the roadmap drupal, node). The site profile is how the build pipeline treats the repo: bedrock (the git-deploy WordPress profile), vanilla WP, or static. Clients — including the API — ask a site what it can do rather than hard-coding behavior per runtime; see runtimes.

Build — the result of detecting a repo, compiling it in an isolated sandbox, and content-addressing and signing an artifact. Builds run on a dedicated builders pool, never on the host serving your site, and you never handle Docker or a registry.

Deployment & release — a deployment rolls a signed build artifact onto a target environment; the running version it produces is a release. Because artifacts are immutable and addressed by content, promote and rollback move releases between environments without rebuilding.

Branch route — the rule that maps a git branch to an environment kind. Your default branch routes to production; other branches route to staging, preview, or ignore. Configure these per site in branch routes.

Snapshot — a point-in-time capture of an environment’s database and files. Snapshots back instant rollback and are the basis of snapshots and backups.

Job — an asynchronous unit of work. Anything that isn’t instant — a build, a deploy, a snapshot restore, a malware scan — runs as a job you can watch to completion. In the API, non-instant mutations return 202 Accepted with a job you can poll or stream; see async jobs.

The object graph

These objects nest predictably. A simplified view:

account
└─ team  (plan · roles · audit log · API tokens)
   └─ project
      └─ site  (runtime · profile · domains)
         ├─ environment: production  (db + files + observability)
         ├─ environment: staging
         └─ environment: preview/<branch>
            ├─ deployment → release   (from a signed build)
            ├─ snapshot(s)
            └─ branch route → environment kind

jobs    — async work across all of the above
events  — webhooks emitted as things happen

Next steps

Environments overviewHow production, staging, and preview environments are isolated, seeded, and promoted.

The build pipelineDetect → build → sign → roll: how a git push becomes a release.

Teams and rolesThe RBAC model that governs who can see and change what.

API resource overviewThe same object graph, exposed as a scoped, async-native REST API.