Run the endpoint in your own cloud

A hosted access layer is a company standing between your agents and your accounts. It sees the requests, holds the credentials, and stores whatever the agents wrote. For plenty of teams that is the sentence that ends the conversation, whatever the product does.

Lanes Link answers it by moving rather than by promising. The endpoint you run on your laptop is the same endpoint you run in your own cloud project, and neither one calls home.

How Lanes Link does it

• One command, from nothing. lanes link deploy creates the project, links billing, enables the APIs, builds the image, and provisions the bucket, the runtime service account and its IAM bindings. See Deploying to Cloud Run.
• The same code, a different adapter set. A workspace names an adapter set and that is the only thing that changes: the encrypted credential file becomes Secret Manager, the local directory becomes a bucket. Connections, providers, policy and limits are declared once and apply to both.
• Two dependencies, and that is the list. Cloud Run and a bucket. No database to provision: state is one object per key and the audit log is one object per event, in the same bucket as memory, tasks, assets and skills.
• Nothing to transcribe. Every resource follows from what the workspace declares or from one answer at a prompt. lanes link deploy --dry-run prints every gcloud invocation before any of them run.
• Your perimeter, your keys. The deploy runs in a Google Cloud project you own, under a service account it creates there. Requests, credentials and stored context stay inside it.
• Reachable from anything. Once deployed, the same endpoint serves claude.ai, ChatGPT and a phone, with the same profiles and the same audit log it had on localhost.

The workflow

Start local. A directory and an encrypted file are enough to connect accounts, write policy and get your agents working, and none of that has to be redone later.

Deploy when you need the endpoint reachable from somewhere other than your machine, or when it has to serve people rather than just you. The connections and profiles you already declared come with it, because they were never properties of where it happened to be running.

From then on, the interesting question is who may call it. A profile's members list decides that, and an empty members list means nobody rather than everybody. Creating a profile puts you on it, so it is open to you and closed to everybody else until you say otherwise.

Set it up

You need a Google Cloud billing account and the Google Cloud CLI, authenticated. Notably not on the list: a project, a database, or a key pair minted in a console.

$ gcloud auth login && gcloud auth application-default login
$ lanes link deploy --workspace cloud

Then:

1. Check the plan first if you want it. lanes link deploy --dry-run prints the whole sequence without running any of it.
2. Say who else may use each profile. You are on the ones you created; lanes link profile members add adds anybody else, before they point a client at the URL.
3. Point your clients at the deployed address. The local one keeps working; they are the same endpoint with different adapters.

Further reading

• Deploying to Cloud Run: cold starts, scaling, IAM and the image.
• Access Profiles: members, grants, and what a profile keeps to itself.
• Security: the boundaries the endpoint enforces and where each one sits.
• Keep work and personal accounts apart: profiles as isolation, on one endpoint.

Browse the source at lanes-sh/link, Apache-2.0, or read the announcement.