Vercel

Vercel is a managed platform that builds and deploys a project from its Git history: every push starts a deployment, and every non-production branch gets its own preview environment. Framework detection fills in the build and runtime settings automatically.

Serving happens over Vercel’s own network: static output from the CDN, server-side code as functions.

The deployment model

The shape is a connected Git repository: every commit or pull request triggers a deployment, and a change merged into the production branch (usually main) becomes a production deployment. Vercel defines three default environments, Local, Preview and Production, and every deployment gets a unique URL. A deployment can also come from the CLI (vercel, or vercel --prod for production), the dashboard, a Deploy Hook URL or the REST API; a broken release can be rolled back without a rebuild.

• Supported Git providers include GitHub, GitLab, Bitbucket, Origin and Azure DevOps Pipelines.
• Any branch can be deployed to preview, and the production branch can be changed.

Some of our projects deploy here from a Git repository with a preview per branch, while this site is served from a classic web host, from the same static build; the Git repository is the same in both cases.

Build and framework detection

A build runs for every deployment, in a clean and isolated environment. Popular frameworks are detected automatically, and the platform fills in the build command, the output directory and the install command, all of which can be overridden in the project settings.

• A purely static site needs no build step: the preset is Other and the build command stays empty.
• The repository is cloned shallowly by default (git clone --depth=10).

Functions and runtimes

Vercel Functions are server-side code: each request is a new invocation, they scale with traffic and drop to zero when idle. Serving a static file needs no function. Official runtimes cover Node.js, Bun, Python, Go, Ruby, Rust, Wasm and the Edge runtime, which is built on the V8 engine and needs no container. That asks for less of our own operations work than assembling the layer from Docker containers behind an nginx proxy.

• Functions run in a single region by default (iad1), which can be changed; several regions are available on Pro and Enterprise.
• Fluid compute reuses an instance for the next request and allows concurrent invocations inside one instance.
• The maximum duration is configurable, and a longer invocation is terminated.

Environment variables and limits

An environment variable is a key-value pair that lives outside the source code and holds a different value per environment. Values are encrypted at rest and visible to anyone with access to the project. Resource limits follow the plan and are documented publicly.

• A variable is either Config or Secret, a Secret is write-only after saving, and all variables of one deployment may use up to 64 KB together; a change applies only to new deployments.
• A build step is capped at 45 minutes per deployment, and how many deployments may run per day and at once depends on the plan.
• Functions default to a 300 second maximum duration, raisable to 800 seconds on Pro and Enterprise; memory is 2 GB, or 4 GB, and the uncompressed bundle is capped at 250 MB, or 500 MB for Python.
• The Build Output API and vercel.json are the platform’s own formats, so a setup built on them travels less easily elsewhere, and a single default region deserves attention.

Further reading

• Deployments
• Vercel Functions
• Environment variables

At CyberElectro Vercel is one of our deployment targets: projects ship there from a Git repository with a preview per branch, while this site is served from a classic web host, from the same static build.