Instant 1.0, a backend for AI-coded apps

Instant turns your favorite coding agent into a full-stack app builder. And we’re fully open source. [1]

Our claim is that Instant is the best backend you could use for AI-coded apps.

In this post we’ll do two things. First we’ll show you a series of demos, so you can judge for yourself. Second, we’ll cover the architecture.

The constraints behind a real-time, relational, and multi-tenant backend pushed us towards some interesting design choices. We built a multi-tenant database on top of Postgres, and a sync engine in Clojure. We’ll cover how all this works and what we’ve learned so far.

Let’s get into it.

Demos

When you choose Instant you get three benefits:

You can make unlimited apps and they’re never frozen.

You get a sync engine, so your apps work offline, are real-time, and feel fast.

And when you need more features you have built-in services: auth, file storage, presence, and streams.

To get a sense of what we mean, I’ll dive into each point and show you how they look.

Unlimited Apps

Traditionally, when you want to host apps online you either pay for VMs, or you’re limited. Many services cap how many free apps you can make, and freeze them when they’re idle. Unfreezing can often take more than 30 seconds and sometimes a few whole minutes.

We thought this sucked. So with Instant, you can spin up as many projects as you like and we’ll never freeze them.

We can do this because Instant is designed to be multi-tenant. When you create a new project, we don’t spin up a VM. We just insert a few database rows in a multi-tenant instance.

If your app is inactive, there are no compute or memory costs at all. And when it is active, it’s only a few kilobytes of extra RAM in overhead — as opposed to the many hundreds of megabytes required for VMs.

This means you can truly create unlimited apps. In fact, the process is so efficient that we can create an app for you right inside this essay. No sign up required.

If you click the button, you’ll get an isolated backend:

And with that we have our backend. Including the round-trip to your computer, the whole process takes a few hundred milliseconds. Actual time:

You get a public App ID to identify your backend, and a private Admin Token that lets you make privileged changes. This gives you a relational database, sync engine, and the additional services we mentioned, like auth and storage.

Combine limitless apps with agents, and you’ll start building differently. Today you can already use agents to make lots of apps. With Instant you’ll never be blocked from pushing them to production.

Sync Engine

But once you create an app, how do you make it good?

It’s easy to build a traditional CRUD app. Just get an agent to wire up some database migrations, backend endpoints, and client-side stores. But it’s hard to make these apps delightful.

Compare a traditional CRUD app to modern apps like Linear, Notion, and Figma. Modern apps are multiplayer, they work offline, and they feel fast. If you change a todo in Linear, it changes everywhere. If you go offline in Notion, you can still mark up your docs. When you color a shape in Figma, it doesn’t wait for a server, you just see it.

These kinds of apps need custom infrastructure. For real-time you add stateful websocket servers. For offline mode you store caches in IndexedDB. And for optimistic updates, you figure out how to apply and undo mutations in the client.

Linear, Notion, and Figma all built custom infra to handle this. As an industry we’ve called their infra sync engines [2]. Developers write UIs and query their data as though it was locally available. The sync engine handles all the data management under the hood.

If modern apps need sync engines, then you shouldn’t have to build them from scratch each time.

So we built a generalized sync engine in Instant. Every app comes with multiplayer, offline mode, and optimistic updates by default.

You can try it yourself. Since we’ve created our isolated backend, let’s go ahead and use it:

Spin up a backend to try the live demo.

What you’re seeing are two iframes that render a todo app. They’re powered by the backend you just created (we passed the iframes your App ID).

Now if you add a todo in one iframe, it will show up in the other. If you go offline, you can make changes and they will sync together. You can try degrading your network, and changes will still feel fast.

And here’s what the todo app’s backend code is like:

App.tsx

import{ init, id }from'@instantdb/react';const db =init({ appId:'YOUR_APP_ID'});functionApp(){const{ data }= db.useQuery({ todos:{}});constaddTodo=(text)=> db.transact( db.tx.todos[id()].update({ text, done:false}),);consttoggleTodo=(todo)=> db.transact( db.tx.todos[todo.id].update({ done:!todo.done}),);return(<TodoUItodos={data?.todos ??[]}onAdd={addTodo}onToggle={toggleTodo}/>);}

That’s about 25 lines. This is even more concise than if you had built a traditional CRUD app. You would have needed to write backend endpoints and frontend stores. Instead you just make queries and transactions directly in your frontend.

db.useQuery lets you write relational queries and they stay in sync. db.transact lets you make changes and it works offline.

This is better for you as a builder: the code is understandable and it’s easy to maintain. It’s better for your users: they get a delightful app. And it’s better for your agents. Sync engines are a tight abstraction [3], so agents can use them to write more concise code with fewer tokens and fewer mistakes.

Additional Services

You saw data sync, but it doesn’t stop there. Apps often need more than data sync.

For example, right now every person who opens our demo app sees the same set of todos. What if we want to add auth or permissions? We may also want to support file uploads, or a “who’s online” section. Or heck maybe we add an AI assistant, and would need infra to stream tokens to the client.

These are common features that most apps need. But often we have to string together different services to get them. Not only is that annoying, but it introduces a new level of complexity. When you manage multiple services, you manage multiple sources of truth.

So to make it easier to enhance your apps, we baked in a bunch of common services inside Instant. Each service is built to work together as a single, integrated system.

To get a sense of these services, let’s look at our todo app again, but this time we’ll add support for file uploads:

Spin up a backend to try the file upload demo.

What would be the traditional way to do this? We would first create a files table in our transactional database, and link it to todos. But then we would need to store the actual file blobs, so we’d probably add S3.

Once we add S3, we have multiple sources of truth to deal with. If we delete a todo for example, we’d need to run a background worker to get rid of the corresponding blob in S3.

With Instant, all of this is a non-issue.

You get File Storage by default, and file objects are just rows in your database. They’re just like any other entity: you can create them, link them to other data, and run real-time queries against them.

This means you can even create CASCADE delete rules, so you can say “when you delete todos, delete files”. There’s no need for background workers. Instead of multiple sources of truth, you get one integrated database. The shared infra handles all the edge cases under the hood [4].

And this is just Instant Storage. You also get Auth. You can use Magic Codes, OAuth, and Guest Auth out of the box. Plus when your users sign up, they’re just rows in your database too.

If you want to share cursors, typing indicators, or ‘who’s online’ markers, you can use Instant Presence.

And if you need to share durable streams, you get, well, Instant Streams.

If you’re curious, we have a bunch of real examples you can play with in the recipes page. You’ll notice that most of these services require little setup and little code. Bot