An Elements app, running on your machine.
An agent can build a complex app extremely quickly, because everything it needs is already here. Features like realtime pubsub, database migrations, sessions and authentication all ship with Elements.
Build apps with AI, on your machines.
Elements is the integrated app environment for building and deploying apps: an app framework and an always-on project server, engineered from the ground up to work together. The project server answers build state queries in microseconds. Your app works the first time, and keeps working.
$100/ month / machine
Your initial purchase includes two machines for the price of one: your computer and a deploy server. 14-day free trial.
- No lock-in: pay for Elements, own the output, MIT licensed runtime
- Standard languages humans and agents already know: HTML, CSS, TypeScript and SQL
- Deploy to Linux boxes you control; a hot deploy takes about a second
- Database, migrations, tests, jobs, email and deploy, included
Created the project on Elements
Started Elements. The build is green
Your project is ready. What would you like to build?
Elements
State:Ok
Elapsed:0.000231s
Step 1 of 5
Your agent uses Elements
Elements gives you and your agent everything needed to build a web application correctly.
Built with Elements.
Should I use Elements?
We'll ask Google AI if Elements is the right fit for what you'd like to build.
Elements fixes common problems.
“I'm paying credits for the agent to fix its own bugs.”
“The agent keeps going in circles on the same bug.”
“Every new feature breaks something that used to work.”
“The agent wiped my database.”
“I don't want to pay a lot for hosting.”
“I can't get my app out.”
“My app took off, and so did my bill.”
“When my app breaks, there's no support to help me fix it.”
Agents don't need framework ecosystems.
Packages are great: your agent can install any npm package in Elements, from Stripe's SDK to a charting library. What an agent doesn't need is a framework ecosystem: the layer of adapters and wrapper libraries that frameworks like React and Next.js depend on for auth, data, forms and state. Each one is another API, with its own versions and conventions, for your agent to learn and get wrong. That layer mattered when humans wrote most of the code, because it meant answers to framework-specific problems and people to hire who knew the framework. What matters now is what makes the agent productive: standard languages it writes fluently, the primitives a real app needs built in, and a build that reports whether each change is correct. An Elements app has all three.
A closer look.
Why Elements is the natural choice for building applications with agents.
You and your agent build on Elements.
You bring the agent. Elements brings the project server, build tooling, app framework and deployment. The result is correct code the first time, and still correct a hundred agent sessions later. Keep building on your own machine, then deploy to commodity hardware in seconds. The price is predictable per month, not based on usage or other metered variables.
The build state is ready before you or your agent asks.
The build has already run by the time you or your agent asks: type check, program analysis, migrations and tests. Your agent reads the diagnostics and corrects the code before reporting the work finished.
An always-on project server, to make your agent smarter.
One server per project. The first command starts it and everything after connects to the same one: elements build, elements test, elements install, and your editor over LSP. It holds the build state in memory, so checking costs microseconds instead of seconds, and you and your agent can check after every change rather than at the end.
The project server answers in microseconds.
Save a file and the rebuild and the full type check are already done, because the build state never left memory. Your editor shows the result as you type, and your agent asks the same question with -json and reads the answer without parsing a screen.
State: Ok
Elapsed: 0.000006s
j/k: down/up G/g: bottom/top y: copy q: quit
{
"path": "/Users/cmather/elements/projects/myapp",
"ok": true,
"errorCount": 0,
"warningCount": 0,
"message": "The build is ok.",
"buildGen": 15,
"buildRanAt": "2026-09-21T12:08:15.74752-07:00",
"started": "2026-09-21T12:09:41.121451-07:00",
"finished": "2026-09-21T12:09:41.121457-07:00",
"elapsedSeconds": 0.000006
}
Your agent reads the manual with elements man, and it is online too.
A build is everything required to release the app.
Read the config, install packages, crawl, type check, run program analysis, emit, migrate the test database, run the tests, collect diagnostics, migrate the app database, release atomically, hot reload connected browsers.
One of the fastest package installers ever built.
Packages install as part of the build, automatically. It is npm compatible. Install one at version local and it resolves from your package search path, gets watched like the rest of the project, and ships on deploy. No monorepo, no file links.
State: Ok
Elapsed: 0.000857s
PACKAGES:
@elements/app @0.7.0
@elements/style @0.7.0
@types/node @22.20.3
tslib @2.8.1
5 root, 29 total packages
j/k: down/up G/g: bottom/top y: copy q: quit
Your database stays in sync automatically.
A migration is a .sql file. No ORM, no migration DSL, nothing to learn on top of sql you already know, which is also why an agent writes and edits them correctly, and why you can always run one directly against a database if you need to. Write one and it is applied on save, to the test database before the tests run and to the app database after. Nothing to remember, nothing to run.
State: Ok
Elapsed: 0.035618s
MIGRATIONS:
node_modules/@elements/app/migrations/2026-07-11-000000-app-baseline.migration.sql [ok]
The application framework baseline migrations.
app/migrations/20260915155829-add-chat.migration.sql [ok]
add chat
j/k: down/up G/g: bottom/top y: copy q: quit
Tests are fast enough to be useful.
The test server runs several processes at once, so tests execute in parallel against the freshly migrated test database. Those processes take part in hot module reload, and a test is rerun when its dependencies change, so a typical test takes a few milliseconds. Fast enough that they stop being the thing you write to be compliant and start being how you find out what you broke.
State: Ok
Elapsed: 0.000014s
TESTS:
app/pages/home/test.ts [pass]
└─ home [pass]
├─ a fresh install has a channel to open on [pass]
├─ an anonymous visitor cannot create a channel [pass]
├─ a guest creates a channel too [pass]
├─ a signed in user creates a channel under a slug [pass]
├─ a channel name that slugifies to nothing is refused [pass]
└─ two channels cannot share a name [pass]
j/k: down/up G/g: bottom/top y: copy q: quit
Program analysis stops unsafe code.
A database call reachable from the browser does not compile, so it never ships. The report carries the fix and the path that got there.
State: Error
Elapsed: 0.000010s
ERRORS:
You have 1 error:
1. app/pages/home/template.ehtml:6:10
Security error: cannot call server code from the browser without going through an rpc
function.
Try:
Put the server code inside a function with an @rpc build tag. For example:
/**
* @rpc
*/
export function fn() {}
Then call fn().
5: function onSignIn(email: string) {
6: return sql(`select id from users where email = ${email}`).first();
7: }
Call stack:
2. app/pages/home/template.ehtml:6:10 sql
1. app/pages/home/template.ehtml:32:49 onSignIn
j/k: down/up G/g: bottom/top y: copy q: quit
Deploy to your own servers, with one command.
Any Ubuntu box you can ssh into. Elements builds the release, ships it, runs the migrations and hot reloads the app. No server restart, no dropped connections. A load balancer and TLS certificates come with every deploy machine.
State: Ok
Elapsed: 0.720184s
Peer to peer, and incremental.
A deploy is your project server talking directly to the one on each machine. Yours sends the source graph it already holds, theirs diffs it against the graph it already holds, and only what changed crosses the wire. Both ends are already hot. No queue behind a million other people's builds, no container image to assemble and push, and nothing rebuilt from scratch on the far side.
Load balancing on every machine.
Every machine runs its own load balancer and they find each other automatically. To grow the cluster, add the IP address to config.jsoc and deploy. Whichever machine takes a request balances it across the cluster, with failover to the ones still answering.
Automatic SSL on every machine.
Set a domain, point DNS at the machine, open 80 and 443. Elements issues the certificate through Let's Encrypt on the first request and renews it before it expires. Adding a domain or rotating a certificate takes effect without dropping connections.
Integrated Postgres.
Elements installs and manages Postgres on every machine, so a single-machine app has a database with nothing to set up. For a cluster of several machines, point them at one shared Postgres, on a server you run or with a managed provider.
A completely integrated app framework that just works.
Everything a real application needs, with no external packages. Your app is standard HTML, TypeScript, SQL and CSS. The HTML is the HTML you and your agent already know, made reactive and dynamic, not JSX with a tree diffing algorithm between you and the page.
- html
- Standard HTML, made reactive and dynamic. TypeScript expressions in attributes and body, and templates with typed attributes. Renders on the server, updates in place in the browser, with no virtual DOM diffing.
- rpc
- Call a server function from the browser like any other function. The compiler turns the call into a request and keeps the body out of the browser bundle.
- routes
- Declared in TypeScript with a typed request and response. Return a page, or return data.
- auth
- Login, logout and authorization primitives are built in. Works in routes, rpc functions, and reactively in Elements HTML.
- sql
- Write sql in your code. It is parameterized at build time, against the Postgres the install already gave you.
- migrations
- Applied by the build: the test database before the tests run, the app database after.
- live tables
- Real time publish and subscribe for your data, with optimistic mutations. Declare the set of rows a page needs and every browser subscribed to it stays current: insert, update or delete anywhere and the change arrives everywhere, painting locally before the server has answered.
- channels
- Broadcast from the server to every browser listening, on every app server.
- jobs and cron
- Queue work off the request path, or schedule it. A job server starts with the project, on your machine and on every machine you deploy to.
- Write mail in the same Elements HTML as your pages. The compiler inlines the stylesheets so it renders in a mail client.
- files
- Bind a file input to a
FileorFile[]and the browser reads the bytes for you. An rpc stores them in Postgres or in any object store, and a route serves them back with content-hashed caching. - tests
- Run across child node processes with hot reload on, against a freshly migrated test database, as a phase of every build.
import { sql } from "@elements/app";
/** @rpc */
function save(name: string) {
sql(`insert into names (name) values (${name})`);
}
<html (name: string = "world")>
<h1>Hello, {name}!</h1>
<input value={name}>
<button onclick={() => save(name)}>Save</button>
</html>
The difference between an app that works the first time and an afternoon of telling your agent to try again.
It matters more the larger the app gets. Save any file in the project and it is checked against every page, every route and every test, so you or your agent can change a schema in a codebase nobody remembers and find out immediately that it broke something three files away. Nothing regresses quietly, and an app you shipped six months ago is still one you can change with confidence.
No lock-in.
You pay for Elements, and you own everything you build.
MIT licensed runtime packages.
You pay for Elements, not for the runtime packages. Elements is the project server, build, test runner and deploy that make your app work and keep it working. @elements/app is MIT licensed, and it includes the runtime your Elements HTML runs on, which is where you write most of your app. @elements/style is MIT licensed too. A built app runs on plain Node.js.
Standard languages your agent already knows.
Elements was built with painstaking care to stay on standards. Pages are plain HTML, with TypeScript expressions in braces and a few attributes, so anyone who knows HTML can read and change them: easier to maintain than a React component. Logic is TypeScript, queries and migrations are SQL on Postgres, and styles are CSS. Agents have read more of these languages than any framework's own, so they write them well. There is no ORM between your agent and the database: no ORM API to learn or get wrong, only SQL your agent writes fluently and you can read.
Start a real app on the free trial.
A real app, not a sandbox: the database, sessions, jobs, email and deploy are there from the first prompt. Everything you and your agent write is yours, in standard languages any developer or agent can keep building on.
Pay for Elements, not for your success.
When a free framework is paid for by hosting, the bill grows as your app does. Elements is one subscription per machine, and that is the price, however far the app grows. You keep the agent subscription you already have, with no credits per prompt. The price is predictable per month, not based on traffic, requests or revenue, and you deploy to servers you control.
Community, without gatekeepers.
We value the people building on Elements. We do not value gatekeepers. In the age of AI, what matters is standard languages and concepts, not framework abstractions only insiders can read. What you learn building on Elements is HTML, TypeScript, SQL and CSS, and it goes wherever you go.
When we started building Elements, the plan was better tooling for people, to make building web apps dramatically simpler. It turns out that same tooling is the linchpin that lets agents build apps that actually work and stay maintainable.
You own the output. We only get paid by making the best tooling in the world, so you can stay focused on building.
Chris Mather (Creator of Elements)
The integrated app environment.
A project server, build tools, app framework and deployment, as one carefully engineered system. Built from the ground up to work together, on your own machines.
Install Elements