Vercel Expands Vercel for Platforms With User-Owned GitHub Deployments.

Vercel is removing a significant integration hurdle for businesses that offer deployment inside their own products. Vercel for Platforms can now create deployments directly from customers’ GitHub repositories, without requiring those customers to install the Vercel GitHub App.

The capability, announced in Vercel’s changelog, gives multi-tenant platforms a more direct way to let users bring existing code into a hosted workflow. It should be particularly relevant to AI app builders, website platforms and developer tools that use Vercel as underlying infrastructure while presenting their own interface to customers.

Instead of directing a user through a separate Vercel app installation, the platform can supply a GitHub access token when it calls Vercel’s deployment API. Vercel then retrieves the repository source and builds the deployment.

The new process is implemented through Vercel’s existing create-deployment API. When creating a deployment, a platform passes two relevant parameters:

• gitSource, which identifies the Git repository and source revision
• gitAccessToken, which authorizes Vercel to retrieve that source from GitHub

According to the deployment documentation, Vercel temporarily stores the access token in encrypted form while it fetches the source. The token is not stored on the resulting deployment.

Vercel recommends that platforms use read-only tokens scoped to the specific repository being deployed. Tokens should also remain valid for no longer than 24 hours. Those constraints reduce the access available if a credential is exposed, although platform operators are still responsible for securely obtaining, handling and passing the token.

This is an API-level addition rather than a new end-user dashboard. Platform builders will need to incorporate GitHub authorization into their own onboarding or import flow, then pass the resulting credential to Vercel. The announcement does not specify a bundled authentication component or a managed user-facing connection screen.

For customers, the immediate benefit is a shorter path from repository to deployment. A user can authorize access within the product they are already using rather than leave that experience to install and configure another GitHub integration.

For platform operators, the change makes it easier to support user-owned repositories while keeping their own product as the control layer. That matters for services where each customer may connect a different repository, choose a branch or trigger deployments from an internal workflow. It also gives builders more control over how GitHub access is requested and explained.

The update fits a broader push by Vercel to support code coming from developer environments beyond a conventional repository connection. The company has also put deployment of Cursor Origin repositories into public beta, addressing projects created through Cursor that may not begin in a standard Git workflow.

There are practical implementation details to consider. Platforms will need a strategy for refreshing expired authorization, handling inaccessible or deleted repositories, and reporting source-fetch failures to users. Because Vercel recommends repository-specific, short-lived credentials, reusing a broad, long-lived GitHub token would run against its security guidance.

The change is available now, based on Vercel’s August 18, 2026 announcement. Vercel did not disclose separate pricing for the capability or identify plan-specific restrictions in the supplied changelog.

What is Vercel for Platforms?

Vercel for Platforms is Vercel’s infrastructure offering for teams building multi-tenant products, such as website builders, AI app platforms and other services that deploy projects for their own users. The new capability lets those teams deploy code from a user’s GitHub repository through Vercel’s API.

Does a user need to install the Vercel GitHub App?

No. A platform can pass a gitAccessToken alongside gitSource when creating the deployment. Vercel uses that token to retrieve the repository source and does not save it on the deployment.

What permissions should the GitHub token have?

Vercel recommends a read-only token scoped to the requested repository and valid for 24 hours or less. The token is stored temporarily in encrypted form while Vercel retrieves the source.