Elements gives you, your engineering team and your agents the project server, the framework, the database, the build and the deployment, engineered to work together. Write the code yourself or with your agent. Deploy to your own server. Your app works the first time, and keeps working.
Your project is ready. What would you like to build?
Elements gives you and your agent everything needed to build a web application correctly.
We'll ask Google AI if Elements is the right fit for what you'd like to build.
Every demo is a starting point. Each one has its source on GitHub, and you and your agent can create your app from it with one command.
Elements is the foundation you and your agent build on: a new framework and build tooling, architected from the ground up for the agent era. The building blocks are in place from the first day: sign-in, payments, live data, jobs and email, and a complete library of pre-made UI templates. The project server guides your agent as it builds, so the app is built with confidence. Whatever you start with today grows into the product, in one app with one database.
“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.”
“My agent says a marketing site needs a static site generator.”
“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.”
Why Elements is the natural choice for building applications with agents.
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. Elements is built for engineering teams and enterprise applications, and just as much for one person building a business alone at a laptop, or a team of agents on VMs. 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.
You and your agent can build a complex app extremely quickly, because everything you need is already here. Features like realtime pubsub, database migrations, sessions and authentication all ship with Elements.
The build has already run by the time you or your agent asks: type check, program analysis, migrations and tests. Your editor, your terminal and your agent all read the same diagnostics from the project server. Your agent corrects the code before reporting the work finished.
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.
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.
Elements is built for engineering teams and enterprise applications. It began at a fast growing healthcare fintech company, where a team of engineers built the company's systems on it: hundreds of millions of dollars in transactions, scaled to a multi-machine architecture with HIPAA compliant security. That is enterprise software, and an engineering team built it on Elements. The code is HTML, CSS, SQL and TypeScript, so any engineer can read it, and every machine runs the same build with the same checks. The project server is one server per project that stays running between commands, and every tool call goes through it: each elements command, the tests, and your editor and your agent over LSP. All of them see the same build state, and a build query answers in microseconds. An agent needs exactly the same thing, so the same architecture serves a person, a team, an agent, or a team of agents.
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.
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.
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.
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.
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.
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.
Any Ubuntu Linux box, at any provider. Elements provisions the machine, installs the load balancer and TLS certificates, builds the release, ships it, runs the migrations and hot reloads the app. No server restart, no dropped connections, and nothing to set up on the machine by hand.
Ask your agent to deploy from your laptop, or even from your phone, or run elements
deploy yourself. Either way the deploy is the same fixed sequence, run by Elements the same way every time. Your agent runs elements deploy -json and reads the result. It never copies files to a machine, edits a running server or restarts a service by hand, and an error in any step stops the deploy before anything changes.
On every deploy, Elements migrates the test database and makes sure every test passes on the deploy machine, running only the tests the change requires. Only then does it migrate the app database and switch to the new release. A failing test or migration stops the deploy, and the previous release keeps serving traffic.
A deploy either succeeds completely or the release is halted. There are no partial failures: nothing reaches your users until every step has passed. When the release lands, the running server hot reloads the changed modules in memory and every connected browser hot reloads with it. No restart, no dropped connections. From the time you run elements deploy, the change is usually on screen within a few seconds.
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.
To handle more traffic, add a machine to config.jsoc and deploy. It joins the cluster with its own load balancer and takes its share of requests. Every app server is a long-running process with no cold starts, and the price per machine stays fixed. A cluster of low-cost servers serves the traffic a serverless platform meters you for. Deploys do not slow down as the cluster grows: every machine receives, builds and tests the release at the same time, so ten machines deploy as fast as one. These are the fastest deployments available anywhere.
Every machine runs its own load balancer and they find each other automatically. Whichever machine takes a request balances it across the cluster, with failover to the ones still answering.
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.
In production, point your app at a managed Postgres such as Amazon RDS by putting its connection settings in your app's config. Every machine in the cluster shares it, and the provider handles backups and failover. There are no row-level security policies to write, because nothing in the browser reaches the database: queries run in server functions, and the compiler stops any attempt to call them from the browser. For a prototype, Elements installs and manages Postgres on the deploy machine itself, with nothing to set up.
Elements handles the provisioning and the deployment. All you have to do is ask your agent to spool up a virtual machine and add its IP addresses to your app's deploy config. From there, the Elements binary, your packages, the load balancer, the certificates and every release are installed and kept current by each deploy. What remains is the operating system. Ubuntu installs its security updates on its own at most providers, and your agent is very good at the rest: a reboot after a kernel update, a firewall rule. There is no console to configure and no pipeline to maintain.
Elements comes with a default app framework that gives you every building block an app needs: routing that serves pages and APIs alike, rpc functions, reactive HTML, sessions, sql and migrations, live tables, channels, jobs and email. It was engineered by necessity for production applications, not by committee, and it is a far better framework than Next.js and the other frameworks that accumulated their features as add-ons over the years: no bloat, no rendering modes, no hooks, no caching directives, and nothing in it an app does not need. The design philosophy is simple. Keep the framework's own abstractions to a minimum, so nothing gets in the way of you or your agent, and stick to the standards: HTML, TypeScript, SQL and CSS. Then give the primitives super powers. A server function is called from the browser like any function. A page is HTML that updates when its data changes. A query is SQL. A live table keeps every browser in sync.
File or File[] 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.The ui package is its own package, separate from the app framework. It holds the most used UI templates on the web, written in Elements HTML: dialogs, menus, command palette, forms, combobox, date and range pickers, data table, charts, kanban, and the chat templates for an AI app: the message list, the prompt input with attachments and the streaming reply. Pick a theme and the entire set changes its look. Open the catalog and play with every one of them live.
Elements is modular. The app framework is one package and the ui package is another. The Elements Team regularly creates new packages that help speed up app development for specialized use cases, MIT licensed and available as they are ready. You add a package to your app with the elements install command, and any package from the npm ecosystem installs the same way. See the packages from the Elements Team on GitHub or in the manual.
You pay for Elements, and you own everything you build.
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/ui is MIT licensed too. A built app runs on plain Node.js.
Elements was built with painstaking care to stay on standards. Pages are plain HTML in .ehtml files. The only new syntax is a constructor, expressions in braces and a few directive 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 you, your agent and the database: no ORM API to learn or get wrong, only SQL your agent writes fluently and you can read.
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.
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.
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)
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. This is the way to build web apps now, for one person, a team of engineers, or a team of agents.
Install Elements