Handing an App over

You built a site for a client and the engagement is ending. They want to own it, or they have hired somebody else to look after it. The site has to go on answering at the same address the whole time.

Hand the App over. It moves to their workspace with its Functions, its files, its environment and its custom domain. Their visitors never notice.

Before you can offer it

The App needs a custom domain that is already serving. Without one the address carries your workspace name, so the site would change address the day it changed hands — which is the one thing this exists to prevent. Attach a domain the client’s business owns, wait for it to serve, and offer the App then.

The page tells you if anything else is in the way.

Make the offer

Open the App, go to Handover, and read what it says the offer will move. You get the list of every environment variable key that travels. Rotate the ones that are yours — your own provider keys, your own tokens — before you hand anything over. The values go with the App, secrets included, and nobody can read one back out of the platform.

Then offer it to an email address. They do not need an account here. The link works for a fortnight, and while it stands nothing has moved: the App is yours, it deploys as normal, and you can take the offer back from the same page.

Only the workspace owner can offer an App. It is not something a deploy credential does.

What moves and what stays

Moves with the App:

• every Function and every version of it
• the static files
• the environment, secrets included
• the schedules
• the custom domain
• what the App has run, without the log bodies

Stays with you:

• the invocation log bodies, which are your client’s own end users’ data
• the usage rollups this App has already been billed on

What they do

They open the link and see what is on offer before they agree to anything. They pick what the App is called in their workspace — yours is the default, and a name they already use is refused, so they choose another. If they own more than one workspace, they also pick which one the App lands in. The App can only land in a workspace they own.

If they are not on a paid plan, accepting gives them thirty days at no cost. It is a real plan with custom domains and schedules, and they choose what to pay before the thirty days are up. Somebody with no workspace gets one for the App to land in; somebody who already has one on the free plan keeps it, and the App lands there. Somebody who already pays keeps the plan they pay for.

Their Billing page says they are on a handover grant, what plan it runs them on and the day it ends. They pick a plan there, any plan, whenever they like — during the thirty days or after them. Choosing one ends the grant. If nobody chooses, deploys pause and schedules stop, in that order, and the site goes on answering at its own address throughout. Custom domains come with the paid plans, so when the thirty days end with no plan chosen, we email them, and the custom domain stops 30 days after that email. Choosing a plan brings it back.

We email them a week before those days run out, and again on the day. Neither email asks for a payment: there is no card on the workspace and no invoice to settle. Each one names the day the grant ends and the two dates that follow it — deploys two weeks after, schedules a month after — and says the site keeps answering throughout.

While it is being copied

Accepting starts the copy. Both of you can see where it has got to — you on the App’s Handover tab, them on their own Apps page.

Throughout the copy:

• the site keeps answering, at the same address
• its schedules keep firing, and its runs keep running
• deploys into the App are paused. A deploy part way through would write files the copy was already working from, so it would never catch up. This is the one thing you give up, and it lasts minutes for most Apps.

If the copy has not finished within a day it is abandoned. Nothing moves, deploys start working again, and the App is exactly where it was. You are both told.

When it lands

The App moves in one step. Before it, it is entirely yours; after it, entirely theirs. There is no moment where it is half of each.

You both get an email. The App leaves your list and appears in theirs, and the slug you gave it comes free for you to use again.

What ends with the move:

• your deploys into it, which now refuse — that is the handover working, not an outage
• any client you invited to watch it
• any preview links on it
• deploy credentials of yours that named only that App

Nothing of yours is deleted. The copy added to their side; it took nothing from yours.

There is no undo. Two people who want the App back where it was do a second handover in the other direction.