Handing projects, servers and services to a teammate

A handover gives one or more of your projects to someone on your team, so that they become the owner in their own account. The servers and services a project runs on go with it. It is not a copy: once they accept, it is theirs, and it leaves your account.

Use it when you have built something for a client or a colleague and they should own it from now on.

Who can send one, and to whom

• You can hand over only projects you own, from your own workspace. A teammate working in your workspace cannot hand over your projects.
• The person taking over must be an active member of your workspace. If they aren't yet, invite them first (see working with your team) and wait until they join.
• Your email address must be verified.

Handovers are always done by people in the app. An AI coding agent connected through The Deployer's MCP server can see that a handover exists, but it cannot send, accept, decline or cancel one.

Sending a handover

1. Open Team in the sidebar and choose the Handovers tab, then click Hand over projects. You can also click the handshake icon on a project's card on the Projects page, which starts with that project picked.
2. Under Who is taking over, choose the member. Under What you're handing over, tick the projects. A box below tells you what would move, including the servers and services those projects run on.
3. Click Review. This step lists:
   • Fix these first: anything that stops the handover (see below). Where another project is involved, a link lets you include it.
   • Moves to: each project, server and service, with their environment values, settings, history and domains.
   • Stays with you: your cloud and Git connections, your billing, your activity history and your other projects.
   • Changes for people: uptime and deploy emails go to the new owner, teammates of yours who had access lose it, and any scheduled start and stop runs carry on for the new owner.
4. Click Continue. Add an optional note for them, type the project's name (or "2 projects", and so on) to confirm, and enter your password, plus your authenticator code if you use one.
5. Click Send handover.

Nothing moves yet. The other person gets an email and sees A handover is waiting for you in the app. You get an email too.

What stops a handover

The review step won't let you continue while any of these is true:

• A server is shared with a project you didn't pick. A server moves with everything on it, so include that project or move it off the server first.
• A service is also used by a project you didn't pick. Include that project, or detach the service from it first.
• Another environment (Dev, UAT, production) of the same app isn't included. Environments are handed over together.
• A project is deploying right now, is being deleted, or has a done-for-you order that isn't finished.
• You received the project in the last 24 hours. For that day it can only go back to the person who gave it to you.

A project can have only one handover waiting at a time.

What never moves

Credentials are never copied. Your cloud accounts, Git accounts and package repository connections stay in your account. The new owner connects their own, and every part of the project that used one of yours is switched to theirs.

Your billing, your activity history, your saved blueprints and your other projects stay with you. Saved IP groups that a project's access rule uses are copied to the new owner, so who can open the app doesn't change.

What runs in the cloud stays where it is. Servers, databases and buckets are not rebuilt or moved: only who owns them in The Deployer changes. That is why the new owner must connect the same cloud account. Adopted apps are handed over as a record only, and nothing in the cloud is touched.

Accepting, step by step

When a handover is waiting for you, click Review next to it on the Handovers tab.

1. What you get. The projects, servers and services, the sender's note, and how many days are left to accept. A handover is open for 14 days.
2. Your plan. Whether it fits your plan's deployed projects and services. If it doesn't, upgrade first and come back. If your plan lacks a feature the sender had (push-to-deploy, uptime and deploy alerts, custom domains), it is listed: everything keeps running, and only that feature is off until you upgrade.
3. Your accounts. For each cloud account, Git account and package repository the projects use, choose one of your own. Each choice is checked straight away: it must be yours, of the right kind, verified, and for a cloud account, the same account the project already runs in. If The Deployer can't tell from the credentials, tick I confirm this is the account it runs in. A package repository is optional; without one, builds use public sources. If you have none of the right kind yet, use Connect one, then refresh.
4. Confirm. Tick that you understand it becomes yours, including what it costs to run in your accounts (your cloud provider bills you directly), and enter your password and authenticator code if you use one. Click Accept and take ownership.

Everything is checked again at that moment. If something changed after the handover was sent (a project joined a shared server, say), you'll be asked to have it sent again.

Declining and cancelling

• Declining: on the first step, click Decline…, add a reason if you like, and click Decline handover. Nothing moves, and the sender is told.
• Cancelling: the sender can click Cancel next to a waiting handover until it is accepted.
• A handover that isn't accepted within 14 days expires. Nothing moves, and both of you are told.

There is no undo after acceptance. The way back is for the new owner to hand it to you.

After the handover

The new owner sees a Next steps list on the completed handover. Some follow-ups run on their own, such as closing terminals the previous team had open and registering the push-to-deploy webhook with the new owner's Git account. If one of them fails, it's marked there with the reason. Click Retry next to it.

The list also suggests checks worth doing, such as changing database passwords and asking the previous owner to revoke any keys they hold.

Common problems

• The person isn't in the list. They must have joined your workspace, not just been invited.
• "That connection is a different cloud account." The recipient picked a connection to another account. It must be the account the project runs in.
• "This doesn't fit your plan yet." The recipient needs more deployed-project or service slots on their plan.