Elements vs Vercel
Vercel is a cloud hosting company. It builds web apps on its own build machines and runs them on its own infrastructure, with server code running as Vercel Functions. Vercel also develops Next.js, the open-source React framework, and gives it away. Its paid plans sell that platform: Pro charges a monthly fee per developer seat, which includes a usage credit, and past the credit it meters compute, function invocations, build minutes, image optimization and more, with CDN requests and data transfer billed per unit or in monthly capacity tiers (Vercel pricing).
Elements is not a hosting company. It is an integrated app environment for building web apps, built for people and their agents: one coherent system that includes a project server that runs while you work, a default app framework, a package installer, a test runner, a bundled Postgres database, and a deploy command. It deploys to ordinary Ubuntu servers you rent from any provider and reach over SSH. Elements charges for that tooling, per machine, and meters nothing.
The two companies charge for opposite things. Vercel gives the framework away and bills the hosting by usage, so the bill grows with your traffic. Elements charges a fixed monthly price per machine for the tooling, and you buy hosting separately: the server, the database and the CDN, each from the vendor you choose, at the price it publishes.
At a Glance
| Elements | Vercel | |
|---|---|---|
| What it is | Build and deploy tooling; your servers do the hosting | A hosting company |
| What you pay for | Tooling, per machine, per month (pricing) | Seats, plus metered compute, invocations, build minutes and image optimization, and CDN traffic per unit or by capacity tier (pricing) |
| Where your app runs | A long-running process on a server you pick | Vercel's infrastructure, as Vercel Functions |
| A deploy | Changed files only, usually under a second | A build on Vercel's build machines, capped at 45 minutes |
| Tests and migrations | Run on every deploy, and a failure stops the release | Not run by default |
| Database | Bundled Postgres, or any Postgres host | Other companies' products, through a marketplace |
| Leaving | With a hosted Postgres, change a server address and deploy | An adapter for another host, or Next.js's self-hosting checklist on your own servers |
Vercel Subsidizes the Framework and Bills the Hosting
Next.js is developed by a core team working full-time at Vercel (governance) and given away, and Vercel charges for the hosting. Its pricing is a two-part tariff: a monthly fee per developer seat, then metered usage once the included credit runs out (Vercel pricing). CDN requests and data transfer are metered too, or, with Flat Rate CDN, billed by a capacity tier that Vercel moves you up the month after your usage outgrows it (Flat Rate CDN). The second part grows with your app: the more it is used, the more you pay. Spend management's only built-in way to stop charges at a limit is taking your sites offline: with Pause Production Deployments on, at the limit Vercel pauses production for every project on the team, visitors get a 503 error, and each project stays down until you resume it by hand (spend management).
That is how a successful launch becomes an invoice. When the art app Cara grew from 40,000 to 650,000 users in a week in 2024, TechCrunch reported that its Vercel bill for that week came to $96,280. Vercel's vice president of product replied publicly that his team had tried to reach the founder ahead of time (TechCrunch).
Elements charges a fixed monthly price per machine, for the tooling (pricing, licenses). Nothing is metered: requests, bandwidth and build minutes never appear on an Elements bill. Your app runs on a server you rent at the price your provider publishes, and a small VPS runs an Elements app (deploy, DigitalOcean pricing).
Agents Need Correction, Not a Platform
Vercel's case rests on Next.js, the React ecosystem around it, and a dashboard that runs the servers for you. For an agent, the value is in none of those. It is in correction: finding out what it got wrong the moment it gets it wrong, before anything ships.
Frameworks still have a place. Agents do not write machine code, and some framework is plumbing every app needs: routing, typed server calls, sessions and a database driver. Between machine code and a package for subtraction, the right amount of framework sits at that plumbing, and past it the returns diminish. Each further framework abstraction, library or platform service is a shortcut only where it does something an agent cannot write quickly from standards it already knows (HTML, CSS, SQL, TypeScript, SSH, Ubuntu), and that surface is small.
The Elements app framework ships the plumbing, app.route(), @rpc, session.login() and sql(), and keeps the rest to HTML and CSS pages and TypeScript function calls, so nothing in an Elements app is proprietary to a host. Its engineering goes into correction instead. The framework and its build were made together, so the project server on your own machine checks every page, function, query, test and migration. It holds the build graph and build state in memory, builds in milliseconds and answers agents and humans in microseconds (build). One call to elements build -json after an edit reports every build error, from tests, migrations, program analysis and type checking, before anything is deployed.
Hosting Is a Commodity. Pick the Best Vendor for Each Job.
A web app needs a server, a database and, often, a CDN. Vercel sells the servers and the CDN as one platform, and runs no database of its own: Postgres and Redis come through a marketplace of other companies' products (Vercel Postgres, Vercel KV). Your code runs as functions on Vercel's infrastructure, with no machine of yours to log in to.
With Elements you choose each vendor directly, on its own terms:
- Servers: in place of Vercel Functions, a machine from DigitalOcean, Hetzner, AWS or another provider with Ubuntu and SSH (setup).
- Database: the Postgres Elements installs on the server, or a managed Postgres such as DigitalOcean Managed PostgreSQL or Amazon RDS, by setting
DB_HOST(setup). - CDN: any of them. Every browser file Elements emits has a content hash in its URL and can be cached long term, so CloudFront, Cloudflare, Fastly or Bunny can front it (load balancer).
On your own server, run elements ssh -remote=production for a shell inside the app or elements db -remote=production for psql, and list apt packages in the deploy config to have them installed (operations).
Deploys Usually Take Under a Second, Not a Fresh Build
By default, every Vercel deployment is a build on one of Vercel's build machines. A build can run up to 45 minutes before Vercel cancels it (limits), and Vercel publishes a guide to reducing Next.js build times that includes pre-rendering fewer pages and using faster build machines (Vercel guide). On paid plans, builds that skip the queue through on-demand concurrent builds are billed per build minute, and Hobby runs one build at a time (build queues, pricing docs).
An Elements deploy does not start over. The project server on your laptop and the one on the target machine each keep a manifest of every file, so the deploy sends only the files that changed, and the target, which keeps its build state between deploys, compiles only what those files affect. Setting up a new machine takes a few seconds, and a deploy after that is usually done in under a second (what deploy does). Because the work happens on machines you already have, nothing waits in a queue and no build minute is billed.
Every Deploy Runs Your Tests and Migrations
Vercel ships the code and leaves the schema to you. Elements treats the two as one change: the first machine migrates a test database, each machine compiles the release and runs your tests against it, and only after that does the first machine migrate the production database, in one transaction, before an atomic swap puts the release live. If compiling, testing or migrating fails, nothing swaps and visitors stay on the release they had (deploy, tests, migrations).
elements deploy -json returns each result, local and remote, labeled with its machine, in the same shape an agent already parses from elements build -json.
Your App Is a Server, So Realtime Works
Realtime features, like a chat or a live dashboard, keep a connection open to every browser. An Elements app is a long-running Node server, so it holds those connections as long as they are needed. Elements uses WebSockets for typed server function calls, for sessions that update the page when a user signs in, for database rows that stay in sync in every browser, and for server-to-browser channels. Postgres carries messages between machines (rpc, session, livetable, channel).
Vercel runs server code as functions with a time limit, 300 seconds by default (function limits). Its WebSocket connections "close when a Vercel Function reaches its maximum duration." For Next.js itself, the same page says it "does not expose an API for handling WebSocket upgrades" and points to a workaround (Vercel WebSockets).
Background jobs, cron, email and the load balancer, with its TLS certificates, run on your server too, as part of Elements (jobs, email, load balancer).
Leaving Is a Config Change
Since the app depends on nothing a host provides beyond Ubuntu and SSH, switching providers for an app on a hosted Postgres is three steps: rent the new server, put its address in config.jsoc and your DNS, and run elements deploy. Elements charges for the tooling, not the framework: the app framework and runtime packages such as @elements/app are MIT licensed, and everything you build is yours (licenses).
Leaving Vercel means re-platforming. On your own servers, Next.js's self-hosting guide lists what you take on once you run more than one: a custom cache handler, because the cache lives on each instance's filesystem; revalidateTag() that only invalidates the instance it ran on; a shared encryption key for Server Actions; and a deployment id to handle version skew (Next.js self-hosting). On another host, Next.js runs through an adapter for that platform (OpenNext).
Where to Run an Elements App
In place of a Vercel project, you need a server: Ubuntu with SSH, from DigitalOcean, Hetzner, AWS or anyone else. Put its IP addresses in config.jsoc and deploy (walkthrough):
elements deploy # production
elements deploy staging # a named environment
elements ssh -remote=production # log in, which a Vercel Function never allows
One server is a complete deployment: the app, the load balancer, TLS certificates and Postgres (deploy), a good fit for a prototype or a single-server app. When you need more servers, or backups and scaling run by a provider, add servers to the config and point them at a hosted Postgres such as DigitalOcean Managed PostgreSQL or Amazon RDS. Each server's load balancer then spreads requests across all of them (load balancer).
Questions
What is the difference between Elements and Vercel?
Vercel is a hosting company: it builds and runs your app on its infrastructure and bills by usage, and it gives away the Next.js framework. Elements is not a host. It is the tooling that builds, tests and ships your app to a server you rent wherever you like, priced per machine with nothing metered.
Is Elements a Vercel alternative?
Yes. Elements plus an ordinary Ubuntu server from any provider replaces Vercel: Elements builds, tests and deploys the app, and sets up the load balancer, TLS certificates and Postgres on the server.
How much does Elements cost compared to Vercel?
Vercel charges a two-part tariff: a monthly fee per developer seat on Pro, and then metered charges for compute, function invocations, build minutes, image optimization and more once usage passes the included credit, with CDN traffic billed per unit or by a capacity tier. The metered part is the part that grows with your app (Vercel pricing). Elements is priced per machine, per month, with nothing metered, so the price changes only when you add a machine (Elements pricing).
How fast is an Elements deploy?
Seconds for a new machine, and usually under a second after that, since only changed files travel and there is no remote build queue. Every deploy also runs your tests and migrations.
Can I deploy a Next.js app with Elements?
Not as a Next.js app. A Next.js app has to be built by Next.js's own build command, next build, which runs Turbopack by default or webpack as an option (Next.js Turbopack docs). Elements has no Next.js-specific support. The Elements build tooling works with TypeScript and JavaScript code in general, not with one framework, and an agent can port an existing Next.js app to the Elements app framework easily.
Where do I host an Elements app?
Wherever you can rent Ubuntu with SSH access: DigitalOcean, Hetzner, AWS and the rest. A single machine holds the app with its load balancer and Postgres, and you add machines when traffic calls for it.