# Elements vs Base44

Base44 is an AI app builder owned by Wix, which [acquired it in 2025](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif). You describe an app in a chat, and [Base44's AI](https://docs.base44.com/Building-your-app/AI-chat-modes) builds it as a React app on Base44's own [managed backend](https://docs.base44.com/developers/backend/overview/features): a NoSQL database, user sign-in, backend functions that run on Deno, built-in integrations for email, file uploads and AI calls, and hosting with custom domains. On paid plans, a model picker offers Base44's own model alongside models from Anthropic, OpenAI and Google, and a [testing agent](https://docs.base44.com/documentation/managing-app-data/testing-agent) can run browser tests of the app's key flows. Apps can sync to GitHub on higher plans, and developers can use the same backend from their own code through the Base44 CLI and SDK. Base44 charges in two kinds of [credits](https://docs.base44.com/Account-and-billing/Credits): message credits for building, and integration credits for the app's live use of Base44's services.

Elements answers the same request, an app described to an AI agent, but the agent and the finished app both end up on machines you control. Your agent, whichever one you use, works on your computer in a project where sign-in, background jobs, realtime and email are application code rather than a hosted backend, next to a Postgres database, a test runner and a deploy command. Elements ships the result over SSH to an Ubuntu server from any provider, and it is priced per machine, with no credits of any kind ([pricing](/pricing)).

The difference is who runs the app and who meters it. A Base44 app runs on Base44's backend and draws on credits as people use it: each email it sends through Base44, each file uploaded to Base44's storage and each LLM call it runs through Base44. When those credits run out, the app's users see an error. An Elements app runs on a server you control. Its database, sign-in, files and jobs are part of the app, and Elements meters none of it. Building spends no credits either: the compiler and your tests check each edit your agent saves, locally, within moments, and Elements charges nothing for it.

| | Elements | Base44 |
|---|---|---|
| Where you build | Your computer, in your editor | Base44's editor, in the browser |
| The agent | The one you choose: Claude Code, Codex, Cursor and others | Base44's AI in the editor, or your own agent through the Base44 CLI, in beta |
| How the agent's work is checked | Every build error, tests and migrations included, reported in microseconds at no charge | A testing agent that clicks through flows in a browser, spending credits on every run |
| Database | Postgres, bundled on your server, or any Postgres 16 or newer | Base44's NoSQL database, with no enforced schema |
| Where the app runs | A rented server you hold the keys to | Base44's infrastructure |
| What the running app is metered on | Nothing | Integration credits for Base44's services: emails, uploads, LLM calls, workflow steps |
| Leaving | Standard TypeScript code and a Postgres database, both movable to any server | Code syncs to GitHub on Builder plans and up; data and sign-in stay on Base44's backend, and functions run there |
| Price | A per-machine subscription ([pricing](/pricing)) | Monthly plans sized by message and integration credits |

## Elements Puts No Meter on the Running App

Base44's [credits page](https://docs.base44.com/Account-and-billing/Credits) prices the running app by action. Sending an email through Base44 is about 1 integration credit, or about 2 from your own domain. A file upload is about 1. An LLM call through Base44 is about 1 on the automatic model, and from about 3 on a model you pick, depending on the model and the length of the prompt and answer. Workflow steps use credits too. Calling an outside service with your own API key skips integration credits, and that service bills you instead. Base44 says "There is no way to preview an integration credit cost before running an action." When integration credits run out, an action that needs them fails, and someone using your app "receive[s] a generic error message without any reference to integration credits." Credits reset monthly, and unused ones expire at the reset.

In Elements, each of these is code in your own app, built with its default framework or the recipes in its manual, and Elements bills none of them:

- **AI calls.** A server function calls the model provider you choose, with your key, at that provider's price ([rpc](/learn/man/rpc)).
- **Email.** Messages use the HTML your pages are written in. While you develop, they go to the project server log and need no account; in production, any email service that speaks SMTP sends them, at its own price ([email](/learn/man/email)).
- **Files.** An uploaded file is one more field on the form, a `File` object. The recipe saves it in Postgres, or in any object store when it is large ([file upload recipe](/learn/man/recipes/file-upload)).
- **Jobs.** Background jobs and scheduled tasks queue in your own database ([jobs](/learn/man/jobs)).
- **Server code.** An `@rpc` function runs on your server when a page calls it, in place of a Deno function on Base44, and the build checks each call ([rpc](/learn/man/rpc)).
- **Sign-in and sessions.** Sessions are rows in your own Postgres, and routes, server functions and pages read them through one API ([session](/learn/man/session), [authentication recipe](/learn/man/recipes/authentication)).
- **Realtime.** LiveTables carry row changes from your Postgres to each open browser ([livetable](/learn/man/livetable), [channel](/learn/man/channel)).
- **Payments.** Stripe Checkout, set up by your agent from the manual's payments pages; the one thing you provide is a Stripe secret key ([payments](/learn/man/payments)).

Elements has no balance to run out, so none of them stops working at the end of a month.

## Your Agent Hears About Its Mistakes in Milliseconds

On Base44, each prompt spends message credits, and Base44 says "Credits are non-refundable for tool behavior and AI mistakes." Its testing agent checks flows in a browser, and each run spends credits, with generating the tests costing credits too ([plans](https://base44.com/pricing)).

Elements catches these mistakes in the build, before anyone opens a browser, and the build spends no credits. The project server, a background process that runs while you work, 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    # ok, or a list of errors with file and line
```

The answer covers four kinds of mistake:

- **The types disagree.** Browser code and server code are each checked against the types they actually have ([typescript](/learn/man/typescript)).
- **A test fails.** Tests run inside the build, so breaking a feature that worked yesterday breaks the build today ([tests](/learn/man/tests)).
- **A migration fails.** Schema changes apply to the development database while you work, and when a batch fails, every part of it rolls back ([migrations](/learn/man/migrations)).
- **Server code leaks.** If browser-reachable code calls `sql()`, `session.login()` or other server-only code, that line gets a compile error ([rpc](/learn/man/rpc)).

The agent fixes each error from its file and line and asks again, all before you open the page. A failing test also stops a deploy, so a change that breaks a tested feature does not reach your users ([what deploy does](/learn/man/deploy/what-happens)). Checking how a page looks takes about a second, a screenshot from the browser already installed on your computer ([browser](/learn/man/browser)).

## Bring Any Agent, and Own the Backend It Writes

Base44 builds with its own AI in the editor. Its [backend service](https://docs.base44.com/developers/backend/overview/introduction) can also be driven by your own coding agent through the Base44 CLI, which Base44 labels "currently in beta." Either way, the backend is Base44's: the app reaches its data, sign-in and functions through the Base44 SDK, they run on Base44's infrastructure, and the running app spends integration credits.

For the agent, the SDK is the expensive part. Every Base44 SDK call is an interface it has to look up rather than one it already knows, and a boundary between the app and Base44's backend where a wrong guess breaks the app. An SDK is a shortcut only past what an agent writes quickly from standards, and for a typical app's data and sign-in that surface is small. Past it, each extra interface costs more to learn than it saves. What does make an agent productive is correction: learning what it got wrong the moment it gets it wrong.

With Elements, the agent you choose builds an app whose backend is its own code. Claude Code, Codex, Cursor or any agent that can run a command works in the project, on the plan you already pay its provider for. No SDK sits in between. The backend is TypeScript and SQL the agent writes, with `sql()` for queries and `session.login()` for sign-in, the pages are HTML and CSS, and a deploy is SSH to Ubuntu, all of it familiar to any coding agent. Pages add Elements HTML, a light reactive extension of standard HTML that the agent reads about in the manual ([html](/learn/man/html)). Because that backend lives in the app, the one build that compiles the pages also checks every query, sign-in call, test and migration, and `elements build -json` reports each mistake in microseconds.

## A New App Runs on Your Machine in Two Commands

Elements installs once, as one coherent system. Then it is two commands: `elements create myapp` for the project, and `elements start` to open it in your browser, already talking to a local Postgres ([getting started](/learn/man/start)). There is no backend service to sign up for, no SDK to link and no build tool to configure. The new project comes ready for your agent from its first prompt.

## Standard Postgres You Can Take Anywhere

A Base44 app keeps its data in Base44's NoSQL database, where "Schemas are not enforced," and its code reaches that data through the Base44 SDK. Syncing to GitHub takes the code; the data and sign-in stay on Base44's backend.

An Elements app keeps its data in Postgres, with a schema your migrations define and the build checks. Sessions and the job queue sit in that same database beside the data, so one move takes all three. What `elements db dump` writes is plain SQL that loads into any Postgres 16 or newer; set `DB_HOST` to that database and the app follows ([database cli](/learn/man/database/cli), [setup](/learn/man/deploy/setup)). The code is standard TypeScript running on Node.js, with its data in Postgres, so any agent can read it, and the app runs on any Ubuntu server.

## Every Page Arrives With Its Content

Base44's [site hosting](https://docs.base44.com/developers/backend/overview/features) "currently supports Single Page Applications (SPAs) only," and "Server-side rendering or server components are not supported." Every Elements page is rendered on the server with its data, then updated in the browser only where values change ([html](/learn/man/html)). The page arrives complete on the first request, so search engines and link previews read its content without running any JavaScript.

## The App Runs on a Server You Control

A Base44 app, and the backend it calls, run on Base44's infrastructure. An Elements app goes to any Ubuntu machine you can open an SSH session on, and a small VPS is enough ([deploy](/learn/man/deploy), [DigitalOcean pricing](https://www.digitalocean.com/pricing/droplets)). The first deploy prepares it: Elements installs the bundled Postgres and its built-in load balancer, and gets HTTPS certificates from Let's Encrypt. Keep that database for a prototype or a single machine. Once there are several servers, or you want backups and scaling run for you, switch `DB_HOST` to a hosted Postgres such as Amazon RDS or DigitalOcean Managed PostgreSQL ([setup](/learn/man/deploy/setup)).

From then on, a deploy sends only the changed files, so it often lands in under a second. A release goes live only when your tests pass on every machine, with pending migrations run once, on the first; if anything fails, the running app keeps serving ([what deploy does](/learn/man/deploy/what-happens)).

## If Your Laptop Is Up, Elements Is Up

On Base44, the editor, the database and the running app all live on Base44's infrastructure, so its uptime is your uptime. Its [status page](https://status.base44.com) lists incidents such as "Service Disruption: Investigation Underway," "App preview and published apps not loading for some users" and "Issues creating and updating apps."

You build on your own computer, and the app is served from your own server. There is no hosted editor between you and your code, so an outage at Base44 does not stop your work. If your laptop is up, Elements is up.

## One Price, Known Up Front

Base44's [plans](https://docs.base44.com/Account-and-billing/Billing-and-plans) are sized by credits: each tier sets a monthly number of message credits and integration credits, shared across every app in the workspace. The credits used by an action "are calculated after the action runs," and a busier app uses more of them.

Elements is one subscription ([pricing](/pricing)) with two licenses inside, one for the computer you build on and one for the server you deploy to ([purchase](/learn/man/purchase), [licenses](/learn/man/licenses)). Nothing is metered: emails, uploads, requests, realtime messages and agent work never appear on the Elements bill. The rest is a VPS at its provider's monthly rate, the agent plan you already pay for, and any outside service you choose, such as an email provider, at its own price.

## Questions

### Is Elements a Base44 alternative?

Yes. You still describe the app to an AI agent. With Elements the agent is your own, working in a project on your computer, and the Elements build checks each change within moments of saving. Sign-in, the database, file uploads and jobs are part of the app, email goes out through any SMTP service you choose, and the app runs on a server you control.

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

Yes, from a Base44 plan that includes GitHub sync. Push the code to GitHub, clone it to your computer, and have your agent rewrite it for Elements, treating the current app as the spec. Base44 entities become Postgres tables with SQL migrations, SDK calls become `@rpc` functions, and `elements build -json` checks every step of the port.

### Does Elements charge per email or per file upload?

No. Elements bills nothing the app does. Email goes out through the email service you choose, at that service's price, and uploads are stored in your own database or object store.

### Can an Elements app stop working when a balance runs out?

No. Elements has no credits or usage balance. It is a per-machine subscription at a price known up front, and nothing the app does draws it down.

### What database does Elements use?

Postgres. Elements bundles it and sets it up on your machine and on every server you deploy to, with schemas defined by migrations the build checks. You can also point the app at any Postgres 16 or newer with the `DB_HOST` setting.