If your company runs more than one site or web app on Vercel (a site per brand or market, a landing page per campaign, a customer portal) and your developer or agency sets up each new one by hand, so no two come out the same, this is for you. If you launch one site a year, skip it: the dashboard is faster. It is not for a company whose platform team already scripts its hosting. If your sites still run on an old server, the move comes first; our hosting page sets out what it involves. The Vercel SDK lets a script, or an agent, do those steps the same way every time. This post is about when that pays off, and how little access it should have, so you can say who holds the keys.
Which SDK is this, and which one is it not?
The Vercel SDK, published as @vercel/sdk, is "a type-safe Typescript SDK that allows you to access the resources and methods of the Vercel REST API." It is the platform's control panel, in code. It is not the AI SDK, the library for calling models.
The names get mixed up (most of the top US search results for "vercel sdk" on 16 October 2026 were about the AI SDK), so if your agency says "use the Vercel SDK", ask which one. Your developer installs it and gives it a Vercel access token, a key, and from then on it can do what the dashboard does: projects, deployments, domains, keys, the firewall and more.
When does scripting the setup pay off?
Script the setup when you have done it twice by hand and the second copy already differs from the first. That is our rule, not Vercel's. One setup a year is faster in the dashboard. A setup you repeat for every brand or campaign is a list of steps somebody will eventually skip.
What drifts is predictable. A missing environment variable in the preview environment. A domain added to production but not to the staging branch. Preview links left open to anyone who has the URL. Each one is small, and each one turns up later as a broken form, a page live too early, or a question on a security review you cannot answer.
What can one setup script do?
One script can run the whole first hour of a new site. These calls are all in the SDK's endpoint list:
- 01Create the project and connect it to your Git repository.
- 02Add environment variables for production, preview and development, each set separately.
- 03Add the domain and run the verification call.
- 04Set protection on preview deployments, so only your team and your agency see them.
- 05Prepare the handover with a project transfer request, once the build is signed off.
The win is not speed. It is that the setup becomes a file your team can read, review and change in one place. When someone asks why preview links need a login, the answer is a line in that file, and every other site has the same line. Preview links are where clients review the work, so they are worth getting right: previews for every change explains how we use them.
Which token should the script hold?
Give the script the narrowest token that does the job. Vercel tokens come in three scopes, and the difference matters more than the code.
A project-scoped token "denies any request to another project, to a user-level resource, or to a team-level resource." That is the property you want for anything that runs unattended. Team and project tokens also carry their scope with them, so requests do not need a teamId.
Two details catch teams out. The token's value is shown once, at creation, so store it in your secrets manager at once. And the API includes a call that returns the decrypted value of a project's environment variable. A broad token left in a build log can read the keys of every site you run, including the one your CRM form uses. A project token can read one.
This is also your answer when a client's security questionnaire asks who can change production: the list of tokens, their scope, who holds each one and when it expires. Which other answers Vercel's own reports give, and which stay yours, is in our security questionnaire post.
When the script gets a 403 with a valid token, the SDK docs list three causes: the token expired, it has the wrong scope, or the feature is not on that team's plan. Their example is access groups, an Enterprise-only feature, called with a token for a Pro team. Build that check into the script's error message, so nobody spends an afternoon on it.
What would you let an agent run with it?
If your agency offers to let an AI agent set up sites, the answer is reads on its own, writes behind a gate. The same SDK a script calls, an agent can call, and the endpoint list includes calls that create projects, write environment variables, delete deployments and return a decrypted secret. So the question is not whether an agent can run your setup. It is which of those calls it may make alone.
Our rule, the same one we use on agents in production: the agent holds a project-scoped token, reads whatever it needs, and writes a plan of the calls it wants to make. A person approves that plan before any create, delete or environment write runs. Every call is logged with the token's name and the job that made it, so you can answer "who changed this project" from the log, not from memory. The team token that mints project tokens stays with a person, never with the agent.
What does it cost to run, and what is the other route?
The SDK is free to install and its docs list no price for it. The cost is the plan behind it. As of 16 October 2026, Hobby is for non-commercial, personal use only, so a business site belongs on Pro or Enterprise, and some endpoints work only on Enterprise. Pro is USD 20 a month with one deploying seat and USD 20 of usage credit. Each extra deploying seat is USD 20, and viewer seats are free. So a company with one in-house developer and one agency developer pays USD 40 a month (about AED 147). If the sites stay inside Pro's included traffic (1 million CDN requests and 1 TB of data transfer a month) and the USD 20 usage credit, that is the month; add-ons such as password-protected previews are priced on their own.
If your developer already describes your hosting in files (infrastructure as code), there is another route. Vercel publishes a Terraform provider, vercel/vercel, at version 5.21.1 on the Terraform Registry on 16 October 2026. Terraform suits a setup you describe once and review like a document. The SDK suits a script that reacts to an event, such as a new campaign page being approved. Ask your developer which one they already use, and keep to it. Either way the steps are Vercel-specific, so keep them as a plain written list too. The list survives a move off Vercel; the code does not.
The bigger cost is upkeep. A setup script is code: when Vercel adds a setting, or you change how you protect previews, someone updates the script and reruns it on the older sites. Budget that as part of running the sites, not as a one-off. Our Run plans are priced on that page for exactly this kind of work.
What does this look like for a Dubai retail group?
Here is a worked example, not a client. A Dubai retail group runs a site for each of three brands and a landing page for each seasonal campaign, built by its digital agency in Next.js. Each new site needs a project, keys for the CRM form in three environments, a domain and protected previews.
The agency writes the steps down first, and the head of digital signs the list. Then the agency turns it into one script that holds a team token. For each site, the script also creates a project-scoped token for that site's scheduled jobs. Domains need one change: Vercel's list of top-level domains it can register had 556 entries on 16 October 2026, and .ae and .in were not among them. So .ae names stay with a local registrar, and the script only adds and verifies them.
When a site is signed off, the script prepares a transfer, and the group accepts the project into its own Vercel team. The account and the bill are in the group's name, not the agency's, so a change of agency does not take the site with it. The next campaign page is the same file with a new name.
One more fact for Gulf companies: Vercel lists 19 compute regions and none is in the UAE or Saudi Arabia. Mumbai (bom1) is the nearest. If a client asks where their data sits, the honest answer is the region you picked, and it is not in the UAE or Saudi Arabia. Records that must stay in-country belong in a system hosted there.
What should you check before you write the script?
Have these five answers on paper first. A script that encodes a wrong step repeats it for every site.
- 01The setup steps written as a list, with the person who signs them off.
- 02The plan each project runs on, and whose name is on the bill.
- 03Where each domain is registered, and who can change its DNS.
- 04Which person or system holds each token, and when it expires.
- 05How the project moves into your own team at handover, and who holds access after.
We are not a Vercel partner, and we do not resell its plans. We build on it when the job fits, and say so when it does not. For the wider picture of how we build and run sites there, start at our Vercel overview.
If your sites never change after launch and nobody plans to hand setup to an agent, skip the script: there is nothing to keep in step. If you run more than a handful and they keep drifting, send us the steps your developer or agency follows today. The written assessment is free: it says whether a script is worth it, which tokens exist today and who holds them. The first build week is a fixed AED/SAR 14,900, credited in full if you sign the build within 60 days. We call the method Preview every change: every change the script makes lands first on a preview link, a copy only your team can open, and reaches the live site only after someone has checked it there.
