Deploy to Vercel from OpenClaw

Once OpenClaw can open pull requests on GitHub, the natural next step is letting it ship. Vercel is a deployment platform built around Git: every push to a branch gets a preview URL, and merges to your production branch update the site visitors see. Connect Vercel and your Operator.io agent can deploy a repository through the REST API, watch a deployment as it builds, and report back the URL, all from a message. Setup is one token, plus the GitHub token you may already have.

The Vercel skill calls POST /v13/deployments with a gitSource block pointing at your GitHub repo, branch, and latest commit SHA. Vercel pulls the code from GitHub using that metadata, runs the build on its infrastructure, and returns a deployment ID and URL immediately while the build continues in the background.

The agent can poll that deployment until the status flips to ready, or list recent deployments on a project to spot failures. The deployments API reference documents the full request and response shape.

If you have only ever deployed to Vercel by hand, Vercel's own product walkthrough imports a project, sets its environment variables, and ships it from the dashboard, which is the same build the agent triggers through the API.

What you get

The Vercel skill gives OpenClaw three moves:

• Deploy a GitHub repository, to either a preview or production.
• List the recent deployments on a project.
• Fetch the details of a single deployment.

The preview and production split is the thing worth understanding before you start. A preview deploy gets its own throwaway URL so you can look at a change in isolation, and a production deploy is the one that updates the site your visitors see. Vercel treats every branch except your production branch as a preview branch by default, so a feature branch and a hotfix branch each get their own URL without touching production. The Git integration docs explain how branch pushes map to preview and production environments.

The agent reads the repository straight from GitHub, so a deploy uses your Vercel token and your GitHub token together, and it helps to set up GitHub first. The skill fetches the repo ID and latest commit SHA from the GitHub API, then passes both to Vercel so the deployment targets an exact commit rather than whatever happens to be on the branch at an ambiguous moment.

Because deploying and checking on a build are separate actions, the agent can run a real loop. It ships a branch to a preview, hands you the link, and promotes the same code to production once you say go. While a build is in flight it can poll the deployment and tell you the moment the status flips to ready, or read back the last several deployments and flag the ones that failed.

The first time it deploys a repo, Vercel detects the framework, whether that is Next.js, Astro, a Vite app, or a plain static site, and creates the project for you, so there is nothing to wire up in advance.

Step 1: Create a Vercel access token

Go to vercel.com/account/tokens. Make sure you are under your Personal Account in the top left, not a team, unless you specifically want a token scoped to a team. Click Create, give it a descriptive name, choose the scope, and set an expiration if you want one. Copy the token when it appears, since Vercel shows it only once. The Vercel REST API docs have more detail on tokens and what they can reach.

If you deploy for a team rather than a personal account, create the token under that team's scope. A personal token only reaches personal projects, and a team scoped token needs the appropriate team selected when you create it.

One thing to understand before you generate it: Vercel scopes tokens to an account or a team, not to a single project, so the token your agent holds reaches every project under that scope and can do more than ship code. The same credential reads and changes a project's environment variables and settings through the API. The clean way to bound that is to keep the agent on an account or team that holds only the projects you are happy for it to deploy, give the token an expiration, and replace it when the work is done.

Step 2: Add the token to Operator

Open Environment in your Operator dashboard, add a variable named VERCEL_TOKEN, and paste the token. If you have not connected GitHub yet, add your GITHUB_TOKEN too, since the deploy step reads the code from your repository before it ships. Both are encrypted and shown once, and the Vercel skill is already installed on every Operator instance.

Step 3: Ship something

Connect Telegram or Discord on the channels page, then put it to work:

Deploy the main branch of my-org/landing to production and send me the URL when it's live.

What were the last three deployments on the marketing project, and did any of them fail?

A useful pattern is to keep risky changes on previews until you have seen them. Ask it to deploy a branch to a preview, review the link it sends back, and only then say "looks good, promote it to production."

The reason to lean on that loop is that a production deploy is the build your visitors land on, and once the agent ships it, nothing sits between the finished build and the live site. Anyone who can message the agent on the channel you connected can ask for that production deploy, so if the instance talks to a shared Telegram or Discord, decide up front whether production is something you trigger yourself while the agent only ever takes a branch to a preview. The arrangement that holds up is the agent deploying previews on its own, you reading the link it sends, and promotion to production waiting on your word.

Sensitive build values like API keys belong in the Vercel dashboard under the project's environment variables, not in the deploy command, and Vercel applies them on the next build.

How Vercel builds your project

When a deployment starts, Vercel runs a build step that installs dependencies and runs your framework's build command. For Next.js that is typically next build. For a static site it might be nothing at all. Vercel detects the framework from your repo's config files and applies sensible defaults on the first deploy. You can override the build command, output directory, and install command in the Vercel dashboard under Project Settings if the defaults do not fit.

Build limits depend on your plan, and the one that shows up in agent work is how many builds can run at once:

Forty five minutes per deployment is more than enough for most web apps. The concurrency limit is the one to watch, since triggering several deploys at once on Hobby leaves the later ones queued until the single slot opens.

Good to know

A token scoped to your personal account reaches your personal projects; for a team's projects, create the token under that team's scope instead. If a deploy cannot find the repository, check that your GitHub token has access to it, since the code is read from GitHub before it ships to Vercel. On the Hobby plan, Vercel caps deployments at 100 per day; Pro allows 6,000. That is generous for normal use, though an agent redeploying the same branch every few minutes could hit the cap on a busy day.

Hobby accounts also cannot connect projects to Git repositories owned by a GitHub organization. If your repo lives under an org, you need a Pro team or a personal fork. Tokens you give an expiration will need replacing on that date.

The deploy skill returns the preview URL as soon as Vercel accepts the deployment, before the build finishes. Ask the agent to watch the deployment if you want a message when the site is actually live, not just queued.

If a production deploy turns out wrong, you have two ways back. The agent can redeploy a known good commit to production, which rebuilds and replaces the live site the normal way. For a faster path that skips the build, Vercel keeps every past production deployment, and its Instant Rollback points your domain back at an earlier one at the routing layer, so the site flips back in seconds; you run that from the Deployments tab or the vercel rollback command.

On the Hobby plan you can only roll back to the immediately previous deployment, while Pro and Enterprise can pick any earlier one. A rollback changes which deployment the domain serves rather than rebuilding, so it does not undo a change you made to environment variables. Those you fix in the dashboard and redeploy.