# Elements vs Bolt

Bolt is an AI app builder made by StackBlitz. You describe a website, web app or mobile app in a chat at bolt.new, and [Bolt's agent](https://support.bolt.new/get-started/intro-bolt) writes it as a JavaScript project, runs it inside your browser on StackBlitz's WebContainers, and shows a live preview. Bolt offers [two agents, Standard and Max](https://support.bolt.new/building/using-bolt/agents), and picks the models behind them. [Bolt Cloud](https://support.bolt.new/cloud/bolt-cloud), which Bolt describes as "powered by trusted platforms like Netlify and Supabase," hosts the finished app at a `bolt.host` address and provides custom domains and Bolt Database, with sign-in, file storage and server functions. Projects can sync to GitHub, payments connect through Stripe, and mobile apps build through Expo. Building is paid for in tokens from a monthly plan, and hosting plans set monthly limits on bandwidth and requests.

Elements also turns what you ask an AI agent for into a working app. The agent is whichever one you already use, and it works in a folder on your computer rather than in a WebContainer in a tab. Elements gives it a project server and a default framework with sign-in, background jobs, realtime and email ready to use, Postgres in the box, a test runner, and a deploy command that targets any Ubuntu server you rent, over SSH. You pay for Elements by the machine; it sells no tokens and meters nothing ([pricing](/pricing)).

The difference is what finding a mistake costs and where the app lives. On Bolt, every message to the agent spends tokens, and Bolt says most of them go to re-reading your project, so a larger project uses more tokens per message. The finished app runs on Bolt Cloud, within traffic limits Bolt sets, and its sign-in is powered by Supabase. In Elements, each change your agent saves goes through the compiler and your tests right there on your computer, within moments, and the check costs nothing extra. Sign-in, jobs and realtime are part of the framework, their data lives in a Postgres database that ships with Elements, and the app runs on a server you control.

| | Elements | Bolt |
|---|---|---|
| Where you build | Your computer, next to your editor, Git and browser | A browser tab at bolt.new |
| The agent | The one you choose: Claude Code, Codex, Cursor and others | Bolt's Standard or Max agent, on models Bolt picks |
| How the agent's work is checked | The compiler and your tests, reported by one local command | The agent re-reads the project; each Attempt fix spends tokens |
| What finding a mistake takes | One command, answered in milliseconds on your machine | Agent messages that spend tokens, more for larger projects |
| Database, sign-in, file storage | Postgres and sign-in built in; uploads stored in the same database by the manual's file upload recipe | Bolt Database, with sign-in powered by Supabase, or Supabase itself on paid plans |
| Email | Built in; in development mail goes to the log, with no account; in production, any SMTP provider | An email provider account plus a custom domain, a paid feature |
| Taking your data elsewhere | Standard Postgres; `elements db dump` writes it out as SQL | Claim the database into Supabase, on Pro or Teams |
| Where the app runs | Ubuntu servers you control, deployed over SSH | Bolt Cloud, or Netlify for the frontend |
| Traffic limits | None set by Elements | Monthly bandwidth and request limits per account |
| Price | One subscription, with nothing metered | Plan tokens, plus pay-as-you-go traffic on Pro |

## Mistakes Are Found by the Build, Not by Re-Reading the Project

Bolt's [token guide](https://support.bolt.new/account-and-subscription/tokens) says "Most of your token usage comes from Bolt reading, understanding, and syncing your project files, so larger projects use more tokens per message." Its advice for keeping costs down includes clearing the agent's context, splitting large files and [deleting unused ones](https://support.bolt.new/best-practices/maximizing-token-efficiency). When something breaks, Bolt offers an **Attempt fix** button, and its guide warns: "each attempt uses tokens. Avoid clicking **Attempt fix** over and over, hoping for things to eventually work out."

Elements finds a broken change with a command, and the command spends no tokens. Nothing has to re-read the project, because the project server holds the build graph and build state in memory and redoes only what a change touches. On every save the build state is updated almost instantly: it builds in milliseconds and answers agents and humans in microseconds ([build](/learn/man/build)). After each edit your agent runs:

```bash
elements build -json    # prints ok, or every error by file and line
```

The answer covers four kinds of mistake:

- **Type errors.** Browser code and server code are each checked against the types they actually have ([typescript](/learn/man/typescript)).
- **Broken features.** The build includes your tests, so a change that breaks something that used to work fails it ([tests](/learn/man/tests)).
- **Schema mistakes.** Migrations, the files that change your tables, are applied to the development database as you go, and a batch that fails is rolled back completely ([migrations](/learn/man/migrations)).
- **Leaks to the browser.** A call to server-only code like `sql()` or `session.login()` from browser-reachable code fails to compile, right at that line ([rpc](/learn/man/rpc)).

The agent goes straight to the file and line, fixes it and asks again. For how a page looks, the agent screenshots it in about a second with the browser your computer already has, and clicks through it the same way ([browser](/learn/man/browser)).

## Bring the Agent You Choose

That check works the same for any agent, because the agent is yours. Claude Code, Codex, Cursor or any agent that can run a command works in an Elements project, on your own account with its provider. Bolt decides which models run its agents; with Elements, when a stronger model ships, you switch to it the day your agent offers it.

What an agent gains most from is correction, being told about a mistake the moment it makes one, not a platform's services. Bolt's agent builds on Bolt's platform: Bolt Database for data, Supabase for sign-in, Netlify behind hosting, and Stripe and Expo through their own connections. Each service brings its own API for the agent to look up and its own seam where the app meets it. A service is a shortcut only for work an agent cannot write quickly from standards, and in most apps that is a short list.

Little in an Elements app is new to a coding agent: it is TypeScript, HTML, CSS and SQL, shipped over SSH to Ubuntu. Queries are `sql()` calls, sign-in is `session.login()`, and the code a page calls on the server is a function marked `@rpc`, all in the app's own files. The one addition is Elements HTML, plain HTML with a small extension for reactive expressions, and an agent picks it up from the manual ([html](/learn/man/html)). That is the plumbing an app needs. Past it, each added layer costs an agent more than it saves, so Elements stops there and puts its engineering into the check: as one coherent system, it sees everything the agent writes and reports each mistake in microseconds.

## Your Project Runs on Your Own Machine

An Elements project lives on your computer, next to your editor, your Git history and your browser, rather than inside a browser tab. Elements installs once, as one coherent system. From then on, `elements create myapp` makes a project, and `elements start` opens it in your browser, already connected to a Postgres database on your machine ([getting started](/learn/man/start)). Your agent works with the same files, terminal, Git history and browser you do, and a new project comes ready for it.

## The Backend Is Part of the App

Most apps need the same pieces behind the page: a database, sign-in, file storage, server code and email. On Bolt, Bolt Database provides data, sign-in, files and server functions, and Bolt's [email guide](https://support.bolt.new/cloud/database/send-emails) says "Bolt's authentication is powered by Supabase." On Pro and Teams plans you can use [Supabase](https://support.bolt.new/integrations/supabase) directly instead. Hosting can move to Netlify, which, Bolt notes, ["can't host your database or a traditional backend."](https://support.bolt.new/integrations/netlify)

In Elements these pieces come with the framework or are documented in its manual, and the same build checks them with the rest of the app:

- **Sign-in and sessions.** Not Supabase: each session is a row in your database, and routes, server functions and pages all read it the same way ([session](/learn/man/session), [authentication recipe](/learn/man/recipes/authentication)).
- **Database.** Elements installs Postgres for you, locally and on each server you deploy to ([database](/learn/man/database)).
- **Server code.** Mark a function `@rpc` and pages call it like a local function, with every call site checked by the build ([rpc](/learn/man/rpc)).
- **Realtime.** A LiveTable keeps a set of rows current in each open browser as the rows change ([livetable](/learn/man/livetable), [channel](/learn/man/channel)).
- **Files.** An upload reaches the server as a `File` object, inside the same form as everything else. The file upload recipe stores them in Postgres, and larger files go to any object store ([file upload recipe](/learn/man/recipes/file-upload)).
- **Jobs.** Background jobs and cron schedules queue in the same database ([jobs](/learn/man/jobs)).
- **Email.** A message is a template in the HTML your pages use. Until production it lands in the project server log, so there is no email account to set up; in production, any SMTP provider delivers it ([email](/learn/man/email)).
- **Payments.** The manual's payments pages take the agent through Stripe Checkout, and you supply one value, a Stripe secret key ([payments](/learn/man/payments)).

The data, sessions, LiveTable change feed and job queue all live in one standard Postgres database, so they move together. Moving them is one SQL file from `elements db dump`, loadable by any Postgres 16 or newer, and one `DB_HOST` change to aim the app at it ([database cli](/learn/man/database/cli), [setup](/learn/man/deploy/setup)).

## Your Code and Your Data Stay on Machines You Control

A Bolt project can be downloaded as a zip of its code. The data does not come with it. Duplicating a project copies the Bolt database's tables and columns ["but not the data itself"](https://support.bolt.new/building/using-bolt/projects-files), and the supported way to take a Bolt database elsewhere is to [claim it in Supabase](https://support.bolt.new/integrations/supabase), which needs a Pro or Teams plan and a Supabase organization owner.

An Elements app is a folder on your computer, and its data is in a Postgres database you run. You keep the code in Git, on any host. Instead of Bolt Cloud, the app runs on a server of yours, any Ubuntu machine you can SSH into, down to a small VPS ([deploy](/learn/man/deploy), [DigitalOcean pricing](https://www.digitalocean.com/pricing/droplets)). On the first deploy, Elements sets up the machine: the bundled Postgres, the built-in load balancer, and HTTPS certificates from Let's Encrypt ([what deploy does](/learn/man/deploy/what-happens)). That Postgres is enough until the app needs several servers, or a provider to handle backups and scaling; then `DB_HOST` can name a hosted one like Amazon RDS or DigitalOcean Managed PostgreSQL. The code is standard TypeScript on Node.js and Postgres, so any agent can read it or port it to another stack.

## Deploys Are Gated by Your Tests

Publishing puts a new version of the app in front of users. An Elements deploy does that only when your own tests pass. The tests run on every machine, and pending migrations run once, on the first machine. If anything fails, the running app keeps serving until a good release swaps in atomically ([what deploy does](/learn/man/deploy/what-happens)).

There is no publish button, and only changed files are sent. The first deploy to a new machine takes a few seconds; after that, a deploy often lands in under a second ([deploy](/learn/man/deploy)).

## If Your Laptop Is Up, Elements Is Up

In a browser-based builder, your project lives on the platform, so the platform's uptime is your uptime. Bolt's [status page](https://status.bolt.new) posted incidents of its own from July through September 2026 including "Bolt Prompting is down," "Issues accessing bolt.new" and "Issues saving project files," and reported prompting degraded on six days in September. The same page tracks the services Bolt depends on, including Anthropic, Cloudflare, GitHub and Supabase. An unpublished project's database can stop too: "if your database has low usage for six days or more, Bolt may automatically pause it" ([database](https://support.bolt.new/cloud/database)).

An Elements project is a folder on your computer, built by Elements on your computer, and your app runs on your server. No hosted editor or platform database sits between you and your code, so a platform outage does not stop the build or the app. If your laptop is up, Elements is up.

## One Price, With Nothing Metered

Bolt's [hosting plans](https://support.bolt.new/cloud/hosting/plans) give each account a monthly allowance of bandwidth and requests, shared by every site it publishes. A Free site that reaches its allowance stops serving until the next billing cycle. On Pro, you can buy more traffic pay as you go, up to a spending cap you set, and at the cap the site pauses. Custom domains are a [paid feature](https://support.bolt.new/cloud/hosting). Building draws on a separate [token allowance](https://support.bolt.new/account-and-subscription/tokens).

Elements has a single subscription ([pricing](/pricing)), and it covers a license for your development machine and one for your deploy machine ([purchase](/learn/man/purchase), [licenses](/learn/man/licenses)). Nothing is metered: Elements sets no bandwidth or request allowance, and agent work, requests and realtime messages never appear on the Elements bill. Hosting is a VPS you rent by the month, and the agent stays on whatever plan you already pay its provider for. The runtime packages such as `@elements/app` are MIT licensed, so you own the code you ship outright.

## Questions

### Is Elements a Bolt alternative?

Yes. You still describe what you want to an AI agent, as on Bolt. Here it is your own agent, editing a project on your computer, and the Elements build checks each change within moments of saving. Sign-in, the database, realtime and jobs are built in, and the app deploys to a server you control.

### Can I move my Bolt app to Elements?

Yes. Take the code out as a zip download or through GitHub sync, open it locally, and have your agent rebuild it in Elements with the Bolt code as its spec. Tables become SQL migrations in the bundled Postgres, rows come over from a dump of the database once it is claimed into Supabase, and `elements build -json` checks every step of the port.

### Do I need Supabase or Netlify with Elements?

No. Postgres, sign-in, realtime, background jobs and file uploads ship with Elements, and the app deploys over SSH to any Ubuntu server. If you want a managed Postgres, set `DB_HOST` to its address.

### Does Elements charge tokens when the agent fixes errors?

No. Elements does not sell tokens or bill agent work. The compiler and the test runner find errors on your machine and hand the agent each file and line, and your agent's provider bills its work on the plan you choose.

### Does Elements limit bandwidth or requests?

No. Elements sets no traffic allowance, and nothing in its price is metered. Your app serves traffic from your own server, at the price your server provider charges.