Deploy to your own cloud

Deploy when you want to reach your endpoint from something that is not your laptop: claude.ai, ChatGPT, or a phone.

The same code and the same config run in both places. A workspace names a set of storage adapters, and that is the only difference. Locally, a directory and an encrypted file. Deployed, one bucket and Secret Manager. Connections, providers, permissions, and limits are declared once and apply to both.

What you need

• A Google Cloud billing account.
• The gcloud CLI, authenticated with gcloud auth login && gcloud auth application-default login.

That is the list. Note what is not on it: a project. There is no database to provision and no key pair to mint in a console. The first deploy creates the project, links billing, enables the APIs, mints the service account and the bucket, and builds the image.

The four commands

$ lanes link deploy --profile personal --workspace cloud --dry-run   # every gcloud command, none of them run
$ lanes link deploy --profile personal --workspace cloud             # creates the project and rolls a revision
$ lanes link connect gmail --profile personal --workspace cloud      # a browser consent per account
$ lanes link outputs --profile personal --workspace cloud            # the URL your agent needs

The order matters. connect comes after the deploy, because a credential store that does not exist yet is not somewhere to write a credential. And outputs comes after both, so register your agent last: a client reads the tool list when it connects and keeps it, so one registered before the accounts holds a list without them and has to be removed and re-added.

There is no second deploy. connect copies the config to where the running revision reads it and asks that revision to re-read it, so the account is reachable as soon as the browser consent is done. Deploying is how new code gets there, and authorising an account changes no code.

--workspace cloud is on every one of them because deploy is one of the commands that refuses a default. lanes set-workspace writes one and most commands use it, but publishing to the wrong place is the failure that flag exists to prevent. There is no environment variable to leave unset and nothing to forget: a command without it refuses rather than acting on local and leaving the deployment without the account.

cloud there is a name rather than a keyword. It is what the first deploy calls the workspace it creates, and lanes link workspace list shows what your profile declares.

Already built a workspace locally? lanes link secrets push --from local --to cloud migrates it instead of the connect step. It copies and never deletes, and skips anything the destination already holds unless you pass --overwrite.

Two answers in the first run decide whether an agent can reach it

deploy asks a short set of questions and writes the config from your answers. Two of them matter more than the rest.

Who may reach it. The default, iam, has Cloud Run demand a Google-signed identity token before the request reaches Lanes Link. No agent can mint one, so an MCP client sees nothing but 403s. If you intend to reach it from an agent, answer public. The endpoint is still gated; the gate is this application's bearer token rather than the platform's front door.

Whether you will add it to Claude or ChatGPT. Answering yes is what lets the endpoint issue its own tokens. Without it, a remote connector has no way to obtain one. There is nothing to set up for this: no OAuth client, no console, no redirect URI.

Both are editable afterwards, but a wrong answer here presents as "the server is unreachable" rather than as a configuration error, so it is worth getting right the first time.

Then register it

$ lanes link mcp add claude --profile personal --workspace cloud

Each workspace has its own credential store, so the deployed token is a different string from the local one. For claude.ai, ChatGPT, or a phone, add a custom connector by URL. See Add it to your agent.

Watching it from the dashboard

A deployed endpoint reads back into the Lanes dashboard the same way a local one does, so you can see what it holds without a terminal:

$ lanes link pair --workspace cloud

No certificate is installed for this — the platform already terminates TLS with one browsers trust — so the command writes a single credential and prints a link carrying it and the endpoint's address. Open it in any browser, on any machine.

The credential reads every connection, profile and audit entry in the workspace and can change nothing. Take it back with lanes link pair --workspace cloud --rotate; a rotation takes up to five seconds to be refused, because the endpoint caches what it read rather than calling Secret Manager on every request.

The dashboard holds several pairings at once, so a deployment and the laptop beside it both appear in its switcher.

A second deployment

Name it, and everything downstream takes the same flag:

$ lanes link deploy --profile personal --workspace staging          # its own project, bucket, and service
$ lanes link connect gmail --profile personal --workspace staging   # same ordering: accounts before the URL
$ lanes link outputs --profile personal --workspace staging

Every command that acts on one account names its profile and workspace, and nothing else supplies them. No environment variable, no key in a file. That is deliberate: a selection you did not type is one you cannot check. A shell alias is the way to shorten it, and it is yours to write.

deploy, status, and sync workspaces are the exception, and not because the rule is relaxed for them. Their subject is the endpoint, which serves every profile in the workspace, so they name the workspace and --profile narrows what they act on rather than selecting it.

Which profiles it serves

lanes link deploy --workspace cloud sends every profile that declares cloud, in one revision, and the endpoint serves all of them under one token. That set is the same one the endpoint will try to open, which is why it is derived rather than typed.

$ lanes link deploy --workspace cloud                        # every profile declaring it
$ lanes link deploy --workspace cloud --profile personal     # only this one

A first deploy is different: a workspace no profile declares yet has no set to derive, so name the profile it belongs to and deploy creates the workspace in it.

Two things it will not decide for you. Which profile owns the endpoint's token, because one token reaches every profile behind it, so you are asked once and the answer is remembered. And whether the profiles can share a credential store at all: references are flat, so two profiles in one project both declaring gmail/main are declaring the same secret, and deploy refuses rather than letting the second overwrite the first. Give the connections different ids, or use a second workspace in its own project.

If the workspace goes missing from your profile

The six lines declaring cloud in your profile are the only thing in the workspace pointing at the service, the bucket, and the credential store. Edit that file badly, or let a tool rewrite it, and every command reports the workspace as undeclared while the deployment carries on answering.

Nothing is lost. The bucket still holds the profile exactly as the last deploy left it, and sync workspaces merges the two copies back together:

$ lanes link sync workspaces --workspace cloud --dry-run   # see what each side is missing
$ lanes link sync workspaces --workspace cloud
personal
  ← workspaces.cloud             missing locally
  ← auth.authorization        missing locally
  ← connections.gmail.work    missing locally

It merges in both directions and never overwrites: anything one side is missing is copied to it, and anything both sides hold differently stops the run and prints the difference. --prefer local or --prefer remote decides those. Credentials, state, and the audit log are never copied.

If you have lost the workspace entirely, --discover asks the platform, and is the only route that works from nothing.

Storage is not optional up here

State, the audit log, memory, tasks, assets, skills, entities, and your own provider manifests all live in the bucket. A container filesystem loses every one of them on an instance recycle without reporting anything, so the deploy configures the bucket for you rather than leaving it to a flag.

A bucket it creates has Autoclass on, so an asset you have not opened in a year costs archive rates without you writing a lifecycle rule. Reading it back is free and immediate, which is the part that makes a cheaper class safe to sit under your own files.

Next: Deploying to Cloud Run covers cold starts, scaling, what the service account is granted and why, the image, using an identity provider you already run, and troubleshooting.