Connect git & deploy

managed.dev deploys from git. You add a remote, push a branch, and the platform builds the commit and rolls it onto the right environment. There’s no Docker, no registry, and no deploy key to manage — the platform detects, builds, signs, and rolls the artifact for you.

Add the remote

Every site has a managed.dev git remote. Copy it from the site’s Deploys tab in the dashboard, then add it to your local clone.

1. Open your site in the dashboard and copy the git remote URL.
2. Add it as a remote named managed.
3. Push your default branch to deploy production.

Add the managed.dev remote

# from your project root
git remote add managed git@git.managed.dev:acme-team/acme-store.git
git remote -v

Deploy production

git push managed main

Note

The managed remote is an addition, not a replacement. Keep pushing to GitHub, GitLab, or wherever your code already lives — managed is just the deploy target. Many teams push to managed from CI instead of from a laptop.

What a push does

The branch you push determines the target. By default the rule is simple, and you refine it with branch routes:

You push…	…and managed.dev	Target
your default branch (main)	builds and deploys the live site	production
any other branch	provisions an isolated, production-seeded environment	preview
a branch routed to staging	builds and deploys the singleton staging env	staging
a branch routed to ignore	builds and deploys nothing	—

A push to main is a production deploy. A push to feature/checkout provisions a preview environment with its own database and files, cloned from production, and returns a live URL.

The build runs automatically

Every push triggers a build. The platform detects what the repo is — Bedrock, vanilla WordPress, or a static site — builds it in an isolated sandbox, and content-addresses and signs the artifact before rolling it onto the target.

The push returns a deploy job that runs asynchronously. You can watch it complete in the dashboard, or follow it through the API as an async job. When it finishes, the environment serves the new commit.

acme-store — git push managed

~/acme-store ❯ git push managed feature/checkout
Enumerating objects: 41, done.
Writing objects: 100% (28/28), 6.2 KiB, done.
managed.dev  ▸ detected runtime: bedrock
managed.dev  ▸ building artifact in sandbox
managed.dev  ▸ provisioning environment for feature/checkout
managed.dev  ▸ cloning database + files from production
managed.dev  ✓ deploy job_01J9F2K7QH succeededhttps://acme-store-feature-checkout-a1b2c3.preview.managed.dev

Supported repositories

The git-deploy flow targets the bedrock profile — a Bedrock-structured WordPress repo with Composer dependencies. Vanilla and static profiles deploy through the same push model. The platform inspects the repo on each push, so you don’t declare the runtime yourself; see runtimes for what’s detected.

Push from CI

Because a push is the entire deploy interface, wiring it into CI is one step: add the managed remote and git push on merge. The preview-environment-per-PR guide walks through the full GitHub Actions setup.

Why git push, not a one-click button

An honest comparison

Most managed hosts give you a “Copy to Staging” button in a dashboard and call that a workflow. That’s fine until you want it in CI, reviewable per branch, or reproducible. A git push is the workflow your team already has — managed.dev maps it to real, isolated environments instead of a single shared staging slot.

Next steps

Branch routesControl which branches deploy where — live, staging, preview, or ignore.

Preview environmentsHow per-branch previews are provisioned, shared, and torn down.

The build pipelineDetect → build → sign → roll: what happens between push and live.