# Deploy application

Part of **Vercel**. Route queries via `POST https://www.company-skill.com/api/route`.

## What You Want to Do

You want to deploy a web application (such as a Next.js, Flask, or React project) to the Vercel platform, and choose the most suitable deployment method based on your development environment, code hosting setup, and automation requirements.

**Typical User Questions**:
- How do I deploy a GitHub project to Vercel?
- How to deploy a Flask app on Vercel?

## Decision Tree

Pick the path that best matches your situation:

- **If** your project is hosted on GitHub, GitLab, Bitbucket, or DevOps → Use Deploy from a Git repository (GitHub/GitLab/etc.) (jump to *vercel/vercel-deployment*)
- **If** you need to quickly deploy from a local folder or your project is not connected to a Git repository → Use Deploy a project manually with the CLI (jump to *vercel/vercel-deployment*)
- **If** you are building a custom CI/CD system and need programmatic control over deployment check status (e.g., Lint or performance tests) → Use Automate deployment creation via API (jump to *vercel/vercel-deployment*)
- **Otherwise (default)** → Use **Deploy from a Git repository (GitHub/GitLab/etc.)**, the most popular and most automated approach on Vercel, with support for Pull Request previews and automatic builds.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation Friendly | Key Fact | Detail Skill |
|------|----------|------------|---------------|---------------------|----------|--------------|
| Deploy from a Git repository (GitHub/GitLab/etc.) | Continuous integration scenarios that automatically sync code changes and deploy. | low | No | Yes | Supports framework presets (Framework Preset) such as Next.js, React, Django, Flask | `vercel/guide/vercel-deployment` |
| Deploy a project manually with the CLI | Push directly from a local development environment, or deploy non-Git projects. | low | No | Yes | The `vercel deploy` command supports prebuilt deployments and offline build environment variables | `vercel/cli/vercel-deployment` |
| Automate deployment creation via API | Custom CI/CD systems or programmatically triggered deployments. | medium | Yes | Yes | Relies on the Checks API and OAuth2 authentication to manage blocking / non-blocking check status | `vercel/api/vercel-deployment` |

## Path Details

### Path 1: Deploy from a Git repository (GitHub/GitLab/etc.)

**Best For**: Continuous integration scenarios that automatically sync code changes and deploy.

**Brief Description**: Use the **New Project** feature in the Vercel console, then choose **Deploy from Git** or **Import Third-Party Git Repository** to connect a remote repository. Supports **Branch Tracking**, automatically generates preview URLs for each branch or Pull Request, and lets you configure **Root Directory**, **Build Command**, and **Environment Variables**.

**Key technical facts**:
- Supported Runtimes: Next.js, React, Vue, Svelte, Astro, Nuxt, Django, Flask, FastAPI, Hono, TanStack Start

**When to Use**:
- User uses GitHub/GitLab/Bitbucket or another Git platform for version control
- Needs automatic build and deployment after every code push
- Wants automatic preview URLs generated for Pull Requests
- Project is based on Vercel-preset frameworks like Next.js, React, or Django

**When NOT to Use**:
- Project does not use Git for version control
- Needs to deploy directly from the local filesystem (no remote repository)
- Deployment flow must be fully programmatic (e.g., custom CI/CD systems)
- Cannot meet Git submodule public-access requirements

**Known Limitations**:
- Only supports deployments through Git repositories; cannot directly deploy local non-Git projects
- For private repositories the committer must be a Vercel project member or have access (a Pro team is required outside personal organizations)
- DevOps deployments require a pre-created empty Vercel project and a configured PAT token
- Git submodules must be publicly accessible over HTTP (see Build Features documentation)

### Path 2: Deploy a project manually with the CLI

**Best For**: Push directly from a local development environment, or deploy non-Git projects.

**Brief Description**: Use the **vercel deploy** command to deploy an application from a local directory, with support for **prebuilt deployment** (skipping remote build) and caching environment variables via **vercel pull**. Combine with **vercel promote** to promote a deployment to production, or use **vercel redeploy** to redeploy a specific version. Supports the **no-wait** flag for non-blocking deployments.

**Key technical facts**:
- (No specific runtime list, but the CLI can deploy any framework that builds locally)

**When to Use**:
- Developer works in a local environment and wants quick test deployments
- Project is not hosted in a Git repository (e.g., temporary prototypes or private filesystems)
- Need a scriptable deployment flow (e.g., integration with Makefile or shell scripts)
- Need offline access to environment variables (cached via `vercel pull`)

**When NOT to Use**:
- Team needs Git changes to automatically trigger the deployment pipeline
- No command-line access available (e.g., browser-only operations)
- Deployment needs deep integration with a third-party CI/CD system (non-standard CLI invocation)
- Project depends on Git history for deployment (CLI deployments can specify a SHA but not by default)

**Known Limitations**:
- Requires the Vercel CLI to be installed and authenticated in advance (via `vercel login` or by setting a TOKEN)
- Not suitable for purely cloud-based scenarios without a local development environment
- Cannot automatically watch Git changes (commands must be triggered manually)
- Advanced features such as rolling releases require additional CLI commands (e.g., `vercel rolling-release`)

### Path 3: Automate deployment creation via API

**Best For**: Custom CI/CD systems or programmatically triggered deployments.

**Brief Description**: Programmatically manage deployment lifecycle events through the Vercel **Checks API**, using **OAuth2 authentication**. Key endpoints include **POST /v1/deployments/{deploymentId}/checks** to create a check, **PATCH /v1/deployments/{deploymentId}/checks/{checkId}** to update its status, and you can react to **deployment.created webhook** events. Checks can be marked as **blocking checks** or **non-blocking checks**, and their **status** and **conclusion** determine whether the deployment is allowed to proceed.

**Key technical facts**:
- auth_method: OAuth2 authentication

**When to Use**:
- Need to integrate deployment status checks (e.g., Lint, performance tests) into a custom CI/CD system
- Need programmatic updates of deployment check status (blocking/non-blocking)
- Need to coordinate with Vercel webhooks (e.g., deployment.created)
- Building advanced deployment workflows (e.g., automatic approval/rejection based on check conclusion)

**When NOT to Use**:
- Only need basic deployment creation (no check requirements) — use the CLI or Git integration instead
- Lack OAuth2 integration capability (the API requires a Bearer token)
- Need to upload a code package directly (the API documentation does not mention such an endpoint)
- Expect simple API key authentication (OAuth2 is actually required)

**Known Limitations**:
- Documentation only explicitly mentions the Checks API (for deployment checks); a complete deployment-creation API is not specified
- Requires implementing an OAuth2 authentication flow (not a simple API key)
- API endpoints focus on post-deployment checks rather than initial deployment creation
- Lacks specific API examples for deployment creation (e.g., uploading code or specifying a Git reference)

## FAQ

Q: Which path should I start with?
A: If your project is on GitHub/GitLab/Bitbucket/DevOps, prefer **Deploy from a Git repository**; if it's a temporary local project, use **Deploy manually with the CLI**.

Q: What if my project doesn't use Git, but I picked "Deploy from a Git repository"?
A: You won't be able to complete the deployment, because that path **only supports deployments through Git repositories and cannot deploy local non-Git projects directly** (see limitations).

Q: What if I need to run tests in CI/CD before deciding whether to go live, but I only used the CLI to deploy?
A: The CLI itself does not provide a pre-deployment check mechanism. You'd need extra script logic, while the **Checks API** natively supports **blocking checks** and **non-blocking checks** and can integrate with the **deployment.created webhook** for automatic approval.

Q: My private GitLab repository's committer is not a Vercel project member — can I still use Git deployment?
A: No. **Private repositories require the committer to be a Vercel project member or to have access (a Pro team is required outside personal organizations)**, otherwise the deployment will fail.

Q: Can I upload a ZIP file directly to deploy via the API?
A: In Vercel's public documentation, the **Checks API** is only used to manage post-deployment check status, and **does not document support for code upload or deployment creation**. Use the CLI's `vercel deploy` or the Git integration instead.

Q: When deploying with the CLI, how do I avoid entering environment variables every time?
A: Use the `vercel pull` command to cache remote environment variables into the local `.vercel` directory. Subsequent `vercel deploy` runs can reuse these **build environment variables**.

## Related queries

deploy app, how to deploy, deploy application, vercel deploy, git deployment, CLI deploy, API deploy, New Project, Deploy from Git, Import Third-Party Git Repository, Branch Tracking, vercel build, prebuilt deployment, Checks API, OAuth2 authentication, deployment.created webhook, blocking checks, n

---
Part of [Vercel](https://www.company-skill.com/p/vercel.md) · https://www.company-skill.com/llms.txt