Elements vs Lovable

Lovable is an AI app builder and host that you use in a web browser, made by Lovable. You describe the app you want in a chat, and Lovable's agent writes it as a React app. The backend runs on Lovable Cloud, which is built on Supabase and provides a database, sign-in, file storage and server functions. Lovable then hosts the finished app at a live URL. Projects sync to GitHub, GitLab or Bitbucket, shared workspaces let a team build together, and building and hosting are paid for from one balance of credits.

Elements starts from the same idea, an app you get by asking an AI agent for it, and moves it onto your own computer. You install one coherent system, and the agent you choose, such as Claude Code, Codex or Cursor, writes the app in TypeScript, HTML, CSS and SQL. Where Lovable Cloud supplies the backend, Elements supplies a project server, a default framework with sign-in, realtime, background jobs and email, a bundled Postgres database, a package installer, a test runner, and deploy to Ubuntu servers you rent from any provider. The project server holds the build graph and build state in memory as you work, so on every save the build state is updated almost instantly: it builds in milliseconds and answers agents and humans in microseconds. You pay Elements per machine, and nothing about it is metered (pricing).

That puts the checking of your agent's work in a different place. On Lovable, finding out whether a change works is part of the agent's work on Lovable's servers, and it draws on your credits. With Elements, the compiler and your tests check every change your agent makes, on your own machine, and report back in one answer. No check is ever billed. Your agent learns about every build error, from failing tests to type errors, before you see the page, and the finished app runs on a server you control.

	Elements	Lovable
Where you build	Your computer, in your editor	Lovable's editor, in the browser
The agent	Yours: Claude Code, Codex, Cursor or another	Lovable's agent
Checking that costs credits	None	Verification and browser checks raise a request's credit cost
When a build breaks	Your agent fixes it from the file and line, with no charge and no limit	A small allowance of free fixes, then credits
Pages	Elements HTML, rendered on the server and reactive in the browser	React
Sign-in, database, realtime	Built in, all stored in one Postgres database	Lovable Cloud, built on Supabase
Where the app runs	Ubuntu servers you control, over SSH	Lovable hosting; the frontend can move, the backend stays on Supabase
What is metered	Nothing	Database, network, storage, compute and realtime, in credits
Price	One subscription, with licenses for your development and deploy machines	Plan credits plus usage

Starting an App Takes Two Commands

Lovable starts in a browser: describe the app and publish it, with nothing to install and no backend to set up. Starting an Elements app takes two commands. After one install, elements create myapp makes a project, and elements start opens it in your browser, running against a real Postgres database (getting started). There is no database to provision, no auth service to sign up for and no build tool to configure. Your agent builds from there.

Elements Never Bills a Check

Lovable's pricing guide says requests that need "more codebase exploration, verification, browser checks, web search, or image and video generation" cost more credits.

When a build breaks, Lovable offers a Try to fix button. Each account gets a small allowance of free fixes, shared across all its workspaces and projects and with fixes from Lovable's Security view, and each one comes back a while after it is used (pricing). After that, Try to fix "is treated as standard build usage and consumes credits," and publishing stays blocked until the build passes.

In Elements, the checking is not agent work. The TypeScript compiler and the test runner do it, on your machine. The agent spends its effort on the fix instead of exploring the app to find out what broke, and Elements never bills for the check, however often the agent asks.

The browser check is local too. To see a page it changed, your agent takes a screenshot with the Chrome already on your computer, in about a second, and can click through the route the same way (browser). Nothing about it is metered.

Your Agent Hears About Its Mistakes in Milliseconds

Every check goes through the project server, which keeps the build state in memory as you work (build). After each edit, the agent runs elements build -json and gets one structured answer about the code on disk, with each error's file and line:

• Type errors. In browser code and server code, each checked for where it runs (typescript).
• Failing tests. Tests are part of the build. A change reruns only the tests it affects, and a failing test is a failing build (tests).
• Migration errors. Each migration, a file that changes your schema, is applied to the development database as you work, and if one in a batch fails, the batch is undone (migrations).
• Security mistakes. Some code must only ever run on the server, such as a database query with sql() or signing a user in with session.login(). Calling it from code that runs in the browser is a compile error at the line that does it (rpc).

The agent reads each error, fixes it and asks again, all before you open the page. Because a failing test fails the build, a change that breaks a tested feature never passes the build.

Bring Any Agent

An agent earns its keep through correction, hearing about each mistake as soon as it makes one, more than through the services a platform hands it. On Lovable, you build with Lovable's agent, inside Lovable's editor, against Lovable Cloud and a catalog of connectors that "add capabilities and external services that your published app can call." Every connector the app calls is one more API in the code and one more place where your app and someone else's service can disagree. A connector is a shortcut only for what an agent cannot write quickly from standards, and that list is short.

Elements works the other way around: you bring the agent, and the app stays close to standards. An Elements app is written in HTML, CSS, SQL and TypeScript and deploys over SSH to Ubuntu, standards that Claude Code, Codex and Cursor already know. The plumbing every app needs comes in the framework: data access is sql(), sign-in is session.login(), and server calls are functions marked @rpc, all inside the app. Past that plumbing, more layers would cost the agent more than they save, so Elements keeps them to a minimum. Because the framework and its build are one coherent system, every line the agent writes goes through one check, and elements build -json returns each mistake in microseconds.

Elements works well with any agent because it has a manual built into the binary. Because you choose the agent, you can move to a stronger model the day one ships.

Sign-In, Data and Realtime Share One Postgres and Move Together

Most apps need the same backend pieces: a database, sign-in, live updates, file storage and server code. Lovable provides them through Lovable Cloud, whose backend "utilizes Supabase's open-source foundation" for "a database, real-time updates, user authentication, and storage," alongside edge functions for server code.

That foundation also decides where the app can go. Lovable's ownership guide says the editor and agent are "a managed service and cannot be self-hosted or deployed inside a customer VPC." For the backend, the supported destinations are managed or self-hosted Supabase, because "Moving the PostgreSQL database alone does not move authentication, storage, realtime, or Edge Functions." Moving to plain PostgreSQL "means implementing equivalents yourself, and Lovable does not support it."

In Elements, your data, sessions and job queue all live in one standard Postgres database, and realtime updates run through it, so they move as one. Point DB_HOST at any Postgres 16 or newer, and all of it comes with the app (setup). The pieces are part of the framework:

• Sign-in. A signed-in session is a row in your own database. Routes, server functions and pages read it through one API, and a page that shows it updates the moment someone signs in (session, authentication recipe).
• Database. Plain Postgres, not a Supabase project, installed by Elements on your computer and on each server you deploy to (database).
• Realtime. A LiveTable is a live set of rows: the server renders them into the first response, then updates every open browser when a row changes (livetable, channel).
• Server code. In place of edge functions, a page calls @rpc functions directly, and the build verifies the arguments each call passes (rpc).
• Files. Uploaded files arrive as File objects in the form sent to an @rpc. Store them in Postgres or any object store, and a route serves them back with cache headers (file upload recipe, assets).
• Jobs and email. Background jobs queue in the same database, and each cron run is recorded there. Email templates are written the same way as your pages (jobs, email).

Pages Are Standard HTML, Fast Without Tuning

Every Lovable app is a React app, and new projects now use TanStack Start. React pages are built from components that re-render as data changes. Re-renders are easy to trigger by accident in React, and keeping a page quick has become a skill of its own.

An Elements page is HTML as the standard defines it, plus a few attributes like e:if and e:for and {} around values that change (html). Each page is rendered on the server with its data, and afterwards the browser touches only what changes, so it is fast without any tuning.

That is why Elements does not use React, and why it is not React compatible: an agent gets standard HTML right more often, and the page is fast in the browser without extra work. An agent bringing a Lovable app over rewrites each React component as an Elements HTML template, and the build checks every step.

Deploys Are Gated by Your Tests

Lovable blocks publishing while the latest build fails, so its gate is that the app builds. An Elements deploy is gated by your own tests. Before a new release goes live, the tests run on every machine, and pending migrations run once. If anything fails, the previous release keeps serving (what deploy does).

Instead of Lovable hosting, the app goes to your own server: any Ubuntu machine reachable over SSH, with a small VPS a workable start (setup, deploy, DigitalOcean pricing). On the first deploy, Elements sets up the server, with the bundled Postgres, the built-in load balancer and TLS certificates. Stay on that Postgres for a prototype or a single server. With several servers, or when a provider should own backups and scaling, Elements suggests a hosted Postgres like Amazon RDS or DigitalOcean Managed PostgreSQL, wired in through DB_HOST. Each deploy after the first carries just the changed files and often finishes in under a second.

An Elements app is a folder of code, so a team shares it the way it shares any code, in Git, and every member's agent gets the same answer from the build.

If Your Laptop Is Up, Elements Is Up

On a hosted platform, the platform's uptime is your uptime. Lovable's status page posted 35 incidents from July through September 2026, among them "Social login unavailable," "Errors signing in and performing account actions" and "Project previews and publishing not working." Billing can stop an app too: "apps that rely on the built-in backend (Cloud) can pause until credits are added" (project usage). When the backend pauses, sign-in, data and storage pause with it.

Your tools live on your computer and your app on your server, and neither has a credit balance to run dry, so the project server keeps building whether or not another company's service is up. If your laptop is up, Elements is up.

One Price, Known Up Front

Lovable bills everything from one credit balance: "Credits let you build apps, chat with Lovable, run deployed apps, and power AI features from one balance." Cloud usage is metered by database instance and storage, network, file storage, compute and realtime messages, and Lovable notes that it "usually increases when more people visit your app."

An Elements subscription (pricing) starts with two licenses, one for the machine you develop on and one for the machine you deploy to (purchase, licenses). More visitors add nothing on the Elements side, because requests, realtime messages, bandwidth and agent work go unmetered. Your server provider charges its own monthly price. The runtime packages such as @elements/app are MIT licensed, so the code you ship carries no Elements license. That code is TypeScript, HTML, CSS and SQL on standard Node.js and Postgres.

Questions

Is Elements a Lovable alternative?

Yes. You still build by asking an AI agent for what you want, but your agent works in the project on your computer, and the Elements compiler and test runner check each change as you work. Sign-in, the database and realtime are built in, and the app deploys to a server you control.

Can I move my Lovable app to Elements?

Yes. Lovable syncs to GitHub, GitLab or Bitbucket, so clone the repository and give your agent the job of porting it to Elements, with the current code as the spec. Your tables are Postgres, so they carry over as SQL migrations, and Supabase auth and row-level security become Elements sessions and checks in your @rpc functions. elements build -json checks every step of the port.

Do I need Supabase with Elements?

No. Sign-in, realtime, background jobs and file uploads are built into Elements and run on the Postgres it bundles. If you want a hosted Postgres anyway, set DB_HOST and point the app at it.

Does Elements charge credits when the agent fixes errors?

No. Elements is a subscription and never meters agent work, traffic or requests. The errors your agent fixes are found by the compiler and the test runner on your machine, so the agent spends its effort on the fix. You pay for the agent itself directly, to the vendor you choose.

Does Elements use React?

No. Elements pages are written in Elements HTML: standard HTML with a few added attributes for loops, conditions and values that change. Pages render on the server with their data and update in the browser with no re-render tuning.