The Deployer documentation
Creating & deploying a project

Bring in apps already running in your cloud

If an app already runs in your cloud account, made by hand or by another tool, you don't have to start again. Adopt existing takes a read-only look at the account, groups what it finds into applications, and brings an application in as a project without changing anything. From there you choose, service by service, what The Deployer may manage, and you can move services onto new infrastructure with the original kept running as your way back.

It works with AWS, Google Cloud, Azure and DigitalOcean accounts you have connected.

Who can do it

The workspace owner, admins, and members with the Adopt existing apps permission can scan and adopt. A member also needs Use on the cloud account (see sharing services and connections).

Some steps stay with the workspace owner, because they let The Deployer change production that already exists: granting control of a service, deploying in place, switching traffic, and marking an original as retired.

1. Scan your cloud account

  1. Click Adopt existing in the sidebar.
  2. Under Which accounts should we look at?, tick one or more connected accounts. Pick more than one to map an app that spans clouds.
  3. Click Scan this account.

This is a read-only scan. It calls your provider's list and describe functions only. Nothing is created, changed or deleted, and secret values are never read, only which secret each service points at.

If you scanned before, you can Use last scan, or Re-scan this account if something changed since.

2. Inventory and applications

Inventory lists every resource found, with a search box. Click through to Applications: resources that belong together (a stack, shared tags, connected resources, matching names) are grouped into an application.

For each application you can:

  • rename it, or move resources into another application or a new one;
  • set its Source repository, if it wasn't detected;
  • answer Is this managed by Infrastructure-as-Code? (Terraform, Pulumi, CloudFormation or CDK).

3. Check and adopt

  1. Click Check what we can deploy. Each service gets a verdict: Can deploy in place, Needs host access, Rebuild recommended, Observe only or Needs a repo.
  2. Choose How should we take over deploys?
    • Rebuild alongside (recommended): a fresh copy of each service is built next to the one you have. The original isn't touched, and you switch only when the copy is proven healthy.
    • Deploy in place: new code is pushed onto the servers you already have. Nothing new is created, but deploys will change those machines. Only offered when a service passed the in-place check.
  3. For each service The Deployer may change, tick Grant control of that service (owner only). With Deploy in place, a box shows exactly what we will touch on each granted service. Databases, storage, DNS and every service you didn't grant stay as they are.
  4. Pick a Git account and click Adopt and choose what to move.

The application becomes a project. Nothing in your cloud has changed. An adopted app counts as a project on your plan.

4. Deploy in place or rebuild

Open the project's migration screen (Manage migration on its card on the Projects page).

  • Deploy in place: click Deploy in place now. It needs at least one granted service and the app's source repository. If the resources look managed by Terraform or CloudFormation, you're warned that the tool's next run may undo the deploy, and you must click Deploy anyway to go ahead. Rebuilding alongside is the safer route.
  • Services on virtual machines need a way in. Under Access to your servers, set up access one machine at a time: The Deployer adds its key through your cloud provider, or gives you one command to run on the machine.

5. Move services to new infrastructure

Under Which services do you want to move?, click Migrate this on each service. Each one then goes through these steps on its own:

  1. Build copy alongside. You continue through the project's Environment, Architecture and Workflow steps and launch. The original keeps serving traffic the whole time. When the deployment succeeds, the service shows Running side by side.
  2. Verify the new copy. The Deployer checks the new copy answers. If it isn't healthy, you can't go further, and your original is unaffected.
  3. Switch traffic over (owner only). The Deployer doesn't silently change your DNS. Point your domain at the new copy in your DNS provider, or attach the domain on the project's Domains tab if it is managed in The Deployer. The original stays running, on standby.
  4. Roll back to original is there at every step once the copy exists. Your original becomes primary again, and the copy is left in place so you can retry without rebuilding. Point your domain back at the original if you had moved it.
  5. Mark original as retired (owner only), once you have shut the original down yourself in your cloud console. Type RELEASE to confirm. This only updates the records: it doesn't touch your cloud, and the one-click rollback for that service goes away.

The Deployer never stops, changes or deletes your original resources. Retiring the original is always your own action, in your own cloud account. Rolling back covers traffic; data written to the new copy after you switched may need to be brought back yourself.

While both copies run, your cloud provider bills you for both, directly.

Drift

The migration screen shows Changes in your cloud since you adopted: what is live now compared with a snapshot taken when you adopted. Click Re-check to look again. The Deployer only tells you; it never changes your cloud to match.

With an AI coding agent

An AI coding agent connected through The Deployer's MCP server can run the scan, read the applications, adopt, and move a service through build, verify and switch, with the same permission checks as you. See use The Deployer from your AI coding tool.

Common problems

  • "Run readiness analysis before adopting." Click Check what we can deploy first.
  • Deploy in place isn't offered. None of the services passed the in-place check. Use Rebuild alongside.
  • "Rebuild needs a source repository." Set the application's source repository, then try again.
  • "Verify the new copy is healthy before switching traffic to it." Run Verify the new copy until it passes.
  • The new copy failed to build. Open the deployment from the migration card, fix the problem and click Try the build again. Your original is still serving.