# Elements vs Retool

Retool is a platform for building internal tools, made by the company of the same name. Teams use it to put apps and automations on top of the databases and APIs they already run: admin panels, dashboards, approval flows and support consoles. Apps connect to business data through [resources](https://docs.retool.com/build/apps/concepts/how-it-works), and Retool offers two ways to build them. In the [new app builder](https://docs.retool.com/changelog/app-builder), you prompt Retool's AI agent and it writes a React 19 app, which you can also edit by hand in a Code tab. Apps made in the earlier builder, which Retool now calls classic apps, are assembled in a drag-and-drop IDE. Retool Workflows run scheduled and triggered automations, and Retool Agents run AI tasks. Apps are hosted on Retool Cloud, and Enterprise plans can also self-host ([pricing](https://retool.com/pricing)).

Retool belongs to the category usually called internal tool builders: hosted platforms where a team assembles business apps on company data without starting a codebase.

Elements builds those same apps. An admin table with inline actions, a dashboard that updates as a job recomputes it, and a role-gated back office are each worked examples in the manual ([admin table](/man/recipes/admin-table), [live dashboard](/man/recipes/live-dashboard), [admin roles](/man/recipes/admin-roles)). Elements is a project server that runs while you work, and it ships with a default framework that just works: sign-in, a Postgres database, realtime, background jobs and email, designed to work together ([getting started](/man/start)). You tell Claude Code, or the agent you already use, what the tool should do. Elements builds in milliseconds and answers your agent in microseconds, so each change is checked before you look at the page. When the tool is ready, one command deploys it to a server you control ([deploy](/man/deploy)). You pay Elements per machine, and nothing is metered ([pricing](/pricing)).

That changes who pays and what you keep. On Retool, every person who builds or uses an app is a seat, and background runs, AI prompts and agent time each draw on a separate allowance. With Elements, the people who use your tool never need a license, the tool is a folder of standard code in your own repository, and it runs on a server you control on every license.

| | Elements | Retool |
|---|---|---|
| What you build | A complete web app: pages, server code, Postgres, sign-in, jobs and email | Apps, workflows and agents on Retool's platform |
| How it is built | You and your agent write HTML, TypeScript and SQL in a project on your computer | Prompting Retool's agent, or the classic drag-and-drop IDE |
| The agent | Yours: Claude Code, Codex, Cursor or another | Retool's agent, drawing on a pooled balance of AI credits |
| Who is billed | A license per machine that runs Elements; the people who use the app need none | Every builder and every internal user, per month; external users past 50 on Business |
| Editing an app | A commit in your repository | Makes the editor a billed builder for that cycle |
| Background work | Jobs and cron built in, with no run count | Workflows, with 500 or 5,000 runs a month by plan and more sold in packs |
| Git | Every app is a folder of code in Git | Git source control on Enterprise |
| Where it runs | Any Ubuntu server you reach over SSH | Retool Cloud; self-hosted or air-gapped on Enterprise |
| What is metered | Nothing | Workflow runs, AI credits, agent hours and external users |
| Price | One subscription, with licenses for your development and deploy machines | A price per builder plus a price per internal user, by plan |

## Everyone in the Company Can Use the Tool

Retool prices each plan per user, in two kinds of seat. Its [pricing page](https://retool.com/pricing) defines a builder as "A user who created or edited an app or workflow this billing cycle," billed "per builder, per month," and an internal user as one of the "Employees in your organization who use apps for daily work," billed per internal user. Billed annually, Team is $10 per builder and $5 per internal user each month, and Business is $50 per builder and $15 per internal user. On Business, people outside the company are metered as external users: the first 50 are free, and each one past that adds a monthly price by tier.

An internal tool earns its keep when more of the company uses it, so on Retool its cost grows with each person who opens it. A colleague who fixes one label in an app has created or edited that app, so that month they count as a builder.

Elements licenses machines, not people. A license covers one machine that runs `elements`: your laptop, a teammate's laptop, a deploy server ([licenses](/man/licenses)). The people who sign in to the finished tool run nothing but a browser, so ten users or the entire company add nothing on the Elements side, and a fix to a label is a commit like any other.

## Your Agent Builds the Tool in Code You Can Read

Retool's new builder is driven by Retool's own agent. Its docs say "The primary development experience of apps is by prompting an AI agent with natural language" ([how apps work](https://docs.retool.com/build/apps/concepts/how-it-works)), and each prompt draws on a monthly pool of AI credits: the pricing page estimates "each AI prompt uses about 12 credits, and a typical app takes 3–6 prompts to build" ([pricing](https://retool.com/pricing)). Classic apps are laid out by hand in Retool's [drag-and-drop IDE](https://docs.retool.com/apps/concepts/ide).

With Elements, you bring the agent, and nothing it does is metered by Elements. 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. A page is standard HTML with a few attributes such as `e:if` and `e:for` and `{}` around values that change, rendered on the server with its data and reactive in the browser ([html](/man/html)). Anyone on the team who reads HTML can read every page of the tool, and a manual built into the binary gives every agent the same reference.

Your agent can see its own work too. It takes a screenshot of the page it changed with the Chrome already on your computer and clicks through the route the same way ([browser](/man/browser)).

## The Build Checks Every Change Before You Look

Every check goes through the project server ([build](/man/build)). After each edit, your 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](/man/typescript)).
- **Failing tests.** Tests are part of the build, and a failing test is a failing build ([tests](/man/tests)).
- **Migration errors.** Each schema change is applied to the development database as you work, and a batch that fails is undone ([migrations](/man/migrations)).
- **Security mistakes.** A database query with `sql()` or a sign-in with `session.login()` must only run on the server. Calling either from browser code is a compile error at that line ([rpc](/man/rpc)).

For an internal tool, that last check matters most: the tool sits on company data, and a query called from browser code is a build error before the change ships.

## Data, Sign-In and Live Updates Are Part of the App

An internal tool needs data, a sign-in that knows who is acting, and screens that stay current. In Elements, each of these is part of the default framework:

- **Database.** Elements installs its own Postgres and creates the app's databases, on your computer and on each server you deploy to ([database](/man/database)).
- **Sign-in and roles.** A session is a row in your own database, read through one API in routes, server functions and pages ([session](/man/session)). A role column checked in one shared guard gates admin pages and server calls ([admin roles](/man/recipes/admin-roles)).
- **Live screens.** A LiveTable is a live set of rows: the server renders them into the first response, then every open browser updates when a row changes, so two people working the same queue see each other's actions ([livetable](/man/livetable)).
- **Server code.** A page calls `@rpc` functions directly, with typed arguments and return values ([rpc](/man/rpc)).
- **Your existing systems.** Every npm package installs as is, so the client for the payments API, cloud service or database your business already uses works in an Elements app the way it does anywhere. Your agent builds from that package and the standards it knows, with no connector catalog to learn.

## Background Work Has No Run Count

Retool runs automations as Workflows, and its [pricing page](https://retool.com/pricing) counts them: "Every time a workflow successfully executes when triggered counts as a run." Free includes 500 runs a month and Team and Business 5,000, with "Additional runs are available at $75 per 5,000 runs per month." Retool Agents are billed separately, by the hour of runtime, with up to 20 free hours a month on every plan. When those are used, "Agent execution pauses" until you upgrade ([pricing](https://retool.com/pricing), [agents billing](https://docs.retool.com/support/billing-usage/agents)).

Elements ships with jobs and cron built in ([jobs](/man/jobs)). A job is a TypeScript class in your app, run by a worker process and retried when it throws, and a cron schedule lives in the same code and enqueues jobs. A nightly sync, a reminder every five minutes and a report each morning run on your server as often as the tool needs, and nothing is metered.

## Every App Lives in Git

An Elements app is a folder of code, so a team shares it the way it shares any code, in Git. Every change is a reviewable diff in TypeScript, HTML and SQL, and every teammate's agent gets the same answer from the build.

On Retool, Git source control is an Enterprise feature ([pricing](https://retool.com/pricing)). Source-controlled classic apps are written out as [Toolscript](https://docs.retool.com/source-control/concepts/toolscript), "a JSX-style markup language built to serialize Retool apps," and Retool's guidance is that "Retool recommends you not modify Toolscript files directly and only make changes when resolving merge conflicts."

## Deploy to Servers You Control on Every License

Retool's Free, Team and Business plans run on Retool Cloud, and self-hosted or air-gapped deployment comes with Enterprise. Retool's FAQ says "Enterprise plans support both options" ([pricing](https://retool.com/pricing)).

Every Elements license deploys to servers you control. Run `elements deploy` and Elements ships the app to any Ubuntu server you reach over SSH, at any provider or inside your own network ([deploy](/man/deploy)). The first deploy sets up the server with Postgres, the built-in load balancer and TLS certificates. Before a release goes live, your tests run on the server and pending migrations apply, and if anything fails the previous release keeps serving ([what deploy does](/man/deploy/what-happens)). An incremental deploy completes in under a second. One server is a complete deployment, and several servers share one Postgres you run or a managed provider through `DB_HOST` ([setup](/man/deploy/setup)).

## One Price, Known Up Front

On Retool, the bill is seats plus allowances: builders, internal users, external users, workflow runs, AI credits and agent hours ([pricing](https://retool.com/pricing)). Each one grows as the tool succeeds.

An Elements subscription ([pricing](/pricing)) starts with two licenses, one for the machine you develop on and one for the machine you deploy to ([licenses](/man/licenses)). Users, requests, job runs and agent work are not metered. Your server provider charges its own monthly price, and you pay for your agent directly, to the vendor you choose. The runtime packages such as `@elements/app` are MIT licensed, so the tool you ship carries no Elements license, and it runs on standard Node.js and Postgres.

## Questions

### Is Elements a Retool alternative?

Yes. You and your agent build the same internal tools, such as admin tables, dashboards and approval flows, as complete web apps in HTML, TypeScript and SQL. Sign-in, Postgres, realtime and background jobs are built in, the code lives in your Git repository, and the app deploys to a server you control.

### Does Elements charge per user?

No. Elements is licensed per machine that runs Elements, such as your laptop and your deploy server. The people who use the app you build only need a browser, and nothing is metered.

### Can I self-host an Elements app without an enterprise plan?

Yes. Every Elements license deploys to any Ubuntu server you reach over SSH. The first deploy sets up Postgres, the load balancer and TLS certificates on that server.

### Can an Elements app connect to the databases and APIs we already use?

Yes. Every npm package installs as is, so the client library for your payments provider, cloud service or database works in an Elements app. The app's own data, sessions and job queue live in the Postgres that Elements installs.

### Do I need to know how to code to build an internal tool with Elements?

No. You tell Claude Code or another AI agent what the tool should do, and it writes the code. Elements checks every change and tells the agent what to fix. You can read and change every line yourself whenever you like.

### Does Elements meter background jobs or AI?

No. Jobs and cron schedules are built in and run on your server with no run count. You bring your own agent and pay its vendor directly, and Elements never bills for the checks the agent runs.

### Can I move a Retool app to Elements?

Yes. Give your agent the job of rebuilding the tool in Elements, with the current app's screens, queries and permissions as the spec. Tables in Postgres carry over as SQL migrations, and `elements build -json` checks every step.