Quickstart

This is the fastest path from nothing to a production site plus a preview environment you can share. It assumes you have a WordPress repository — Bedrock, vanilla, or static — that you can push. If you’re moving an existing site off another host, start with migrate a site instead and come back here for the deploy step.

1. Create an account. Sign up at app.managed.dev/signup. Starter includes a 14-day free trial, no card required to start.

2. Create or import a site. From the sites list, choose New site. Point it at a git repository, or import an existing one — managed.dev detects the runtime (Bedrock, vanilla WP, or static) for you. You don’t pick a stack or write a Dockerfile.

   The “New site” dialog in app.managed.dev: a site name field, a git repository URL, an auto-detected runtime badge reading “WordPress (Bedrock)”, and a “Create site” button.

3. Connect your git remote. managed.dev gives you a remote you push to. Add it alongside your existing origin:

   Add the managed remote

   git remote add managed git@git.managed.dev:acme/acme-store.git
   git remote -v

   The “Connect repository” panel in the site’s Settings tab, showing the copyable git remote URL, a deploy SSH key fingerprint, and the current branch-route mapping.

4. Deploy production. Push your default branch. managed.dev builds the artifact on the builders pool, signs it, and rolls it onto production.

   Deploy to production

   git push managed main

   The default branch (here main) maps to production. You control how every other branch is treated with branch routes.

5. Push a feature branch for a preview. Any non-default branch becomes a fully isolated environment — its own database and files, seeded from production — with a live URL:

   Open a preview environment

   git switch -c feature/checkout
   git push managed feature/checkout

   acme-store — push a preview

   ~/acme-store ❯ git push managed feature/checkout
   managed.dev  ▸ build queued on builders pool
   managed.dev  ▸ artifact content-addressed + signed
   managed.dev  ▸ provisioning environment for feature/checkout
   managed.dev  ▸ cloning database + files from production
   managed.dev  ✓ environment livehttps://acme-store-feature-checkout-a1b2c3.preview.managed.dev

   Open the URL, share it with reviewers, and QA against production-like data without touching production.

6. Promote. When the branch is approved, promote it to production from the environment’s page in the dashboard — or merge to your default branch and push. If anything regresses, roll back from a snapshot in a click.

Prefer the command line?

Everything above has an API and a CLI equivalent. The mf CLI and the public API can create sites, open environments, and trigger deploys from CI. See the API quickstart and the mf CLI once you’ve done the loop once by hand.

Connect over SSH

Every plan includes an SSH gateway and full WP-CLI, scoped to your team and a single environment. Connect to any environment to run WP-CLI directly:

SSH

Open a shell on an environment

ssh acme-store@ssh.managed.dev

WP-CLI over SSH

Run WP-CLI without an interactive shell

ssh acme-store@ssh.managed.dev wp plugin list --status=active

See the SSH gateway and WP-CLI for the full connection and addressing model, including how to target a specific environment.

Next steps

Core conceptsThe site / environment / runtime model that the deploy loop is built on.

Connect git in depthDeploy keys, the managed remote, and how pushes become builds and releases.

Preview environmentsWhat's in a preview, how it's seeded and isolated, and its lifecycle.