Vercel on-premise - what it takes to run the same workflow yourself

Disclosure up front: we build Stormkit, one of the options below. The short answer to the question in the title is a fact rather than a pitch, so it goes first.

Vercel does not offer an on-premise edition you can install in your own datacentre. What it offers instead is bring your own cloud on AWS: your compute, build artifacts and application data run inside your own AWS account and VPC, while Vercel continues to operate the control plane on top of them. At the time of writing that is a private beta, AWS only, and not something you can sign up for — you talk to their sales team. Netlify has no generally available self-managed edition either.

That distinction is the whole article. Bring your own cloud answers "our account, our VPC, our security group". It does not answer "our building", it does not answer "no route to the public internet", and it does not answer "the platform keeps working if the vendor stops" — because the control plane is still theirs and still hosted. If your requirement is one of those three, or if you need something generally available today on a cloud other than AWS, you are not looking for a licence — you are looking for a replacement.

That is a more tractable problem than it sounds, because the thing you actually depend on is a workflow, and the workflow is made of about six parts.

What "on-premise" means in practice

Worth pinning down, because three quite different requirements arrive under the same word and they cost wildly different amounts of effort:

• Your own hardware — a rack in your building, or a colocated cage. Rare now, and usually driven by a contract or a regulator.
• Your own cloud tenancy — a private VPC in AWS, Azure, GCP, OVHcloud or Hetzner, where "on-premise" means "our account, our network, our security group" rather than "our building". This is what most people mean, it is by far the easiest of the three, and it is the one Vercel's bring-your-own-cloud beta is aimed at.
• Air-gapped — no route to the public internet at all. Genuinely hard, and the section below is mostly about why.

If you have not yet worked out which one you are being asked for, do that before choosing any tooling. The gap between the second and the third is larger than the gap between any two platforms you might pick.

What you are actually replacing

Strip the marketing off and the Vercel workflow is:

1. A push triggers a build. A webhook from GitHub, GitLab or Bitbucket, a checkout, an install, a build command.
2. Every branch gets a URL. Preview deployments are the feature people miss most when they leave, and the one most self-hosted setups quietly drop.
3. Environments carry their own configuration. Variables and domains per environment, not a single .env on a server.
4. Something serves the result. Static assets, SSR, API routes — with sensible caching and no cold-start surprises.
5. TLS renews itself. Nobody wants to be the person who forgot.
6. Rollback is one click. The previous deployment is still there and going back does not mean rebuilding.

Everything else you might miss — a database, auth, cron, transactional email — sits alongside the platform rather than inside it. Whether they come with your replacement or become four more things to run is the main thing that separates the options.

The parts that get hard behind a firewall

This is the section that tends to be missing from write-ups, and where projects lose their schedule.

Builds need the internet even when your application does not. npm install reaches out to a registry. Docker pulls base images. A build platform inside an air-gapped network needs a package mirror — Verdaccio, Nexus or Artifactory — and a registry mirror, and someone to keep both current. This is usually the single largest piece of work, and it has nothing to do with which deployment platform you chose.

TLS is different inside a private network. Automatic certificates normally work by proving control of a public domain over HTTP. With no inbound path from the internet, that fails, and the answer is to stop issuing certificates on the box: bring your own, from an internal CA with the root distributed to your machines, or issued out-of-band and installed. Whichever platform you pick, check that it accepts a certificate you supply per domain rather than assuming it can always fetch one. Decide this before installation, not after.

Git has to be reachable from the builder, not just from developer laptops. A self-hosted GitLab or a network path to your provider.

Secrets probably already have an owner. If Vault or a cloud secrets manager is the standard in your organisation, check how the platform expects to receive environment variables before you commit to it.

Build capacity becomes a resource you plan. On a managed platform, ten people merging at once is someone else's problem. On one machine, it is a queue. Either size for the peak or push builds out to your existing CI.

Putting it back together

The self-hosted Vercel alternatives roundup compares the platforms in depth — Coolify, Dokploy, Dokku, CapRover, Kamal and Stormkit — and the choice there does not change much just because the network is private. The short version: container platforms if you are running a lot of software you did not write, an application platform if you are running a product you did.

Where Stormkit is relevant to this particular question is that it installs onto machines you control and expects nothing from us at runtime:

curl -sSL https://www.stormkit.io/install.sh | sh

It ships as Docker images for amd64 and arm64, installs via Docker Compose on a single machine or Docker Swarm across several, and is tested on Ubuntu, Debian, Fedora, Rocky Linux and macOS. Preview URLs per branch, environments with their own variables and domains, and one-click rollback all survive the move — which is the part people assume they are giving up. Builds run on the workerserver service by default, or you can hand them to GitHub Actions if you would rather your existing CI owned that. On the TLS question above, domains with no public inbound path take a custom certificate you supply as PEM, per domain, instead of automatic issuance.

The services that usually arrive as separate vendors are part of it: PostgreSQL attached to an environment with migrations on deploy, end-user authentication, transactional email, periodic triggers, persistent volumes and server-side analytics. In a private network that consolidation matters more than it does on the public internet, because every external service you remove is one less firewall exception to justify.

Pick it if you want the Vercel workflow specifically — previews, environments, rollbacks — inside your own network, with the application services included.

Look elsewhere if what you actually need is somewhere to run a lot of off-the-shelf containers. Coolify covers that better, and the roundup explains why.

If the driver is jurisdiction rather than network topology, the data residency write-up is the more directly useful one — the answer there is often an EU region rather than a migration.

Frequently asked questions

Can I buy Vercel Enterprise and run it on our servers? Not on your own servers. The closest thing is bring your own cloud, which places the compute and data in your AWS account while Vercel runs the control plane — private beta, AWS only, enterprise sales rather than self-serve. There is still no build of Vercel you install on hardware you own, and nothing that runs without a control plane operated by Vercel.

Is a private VPC good enough to count as on-premise? For most auditors and most contracts, yes — the requirement is usually about control and network isolation rather than about owning the building. Check the actual wording you are being held to. "Our own infrastructure" and "our own premises" are different promises, and only one of them requires a rack.

Does Stormkit work fully air-gapped? The platform installs and runs on machines with no inbound internet access. The harder question is builds, which need a package registry and a container registry — mirror both internally and you are in business. If you are planning a genuinely air-gapped deployment, talk to us first rather than discovering the gaps during a pilot.

What happens if the vendor disappears? This is the underrated argument for self-hosting and the one regulators ask about directly under DORA. Software running on your machines keeps running. The Stormkit community edition is AGPL-3.0, so the source is available regardless of what happens to the company; some enterprise components are proprietary and ship in the published binaries.

How much machine do we need? Less than people expect for serving, more than people expect for building. The serving side is comfortable on a small VPS. Builds are CPU and memory hungry in bursts — size for your worst simultaneous merge, or offload to CI.