We wanted to make a tool that (a) would make it easy to build delightful apps, and that (b) builders would find easy to use.
This got us into making things that touch both local-first and AI.
On the local-first side, we took on problems like offline-mode, real-time, and optimisitc updates.
On the AI side, we built a multi-tenant abstraction, so you can spin up as many apps as you like, and focused on great DX/AX so agents found Instant easy to use too.
Though, their console feels like it didn't get the love that the rest of the infra / website did.
Congrats on the 1.0 launch! I'm excited to keep building with Instant.
We're going to redesign the dashboard in the next few weeks.
One interesting observation from our users: though they use the dashboard less in some ways (the AI agents spin up apps and make schema changes for them), we found people use them _more_ in other ways. Instant comes with an Explorer component, which lets you query your data. We found users want to engage with that a lot more.
I think there's two surprises about this:
1. If it was easier to make apps multiplayer, I bet more apps would be. For example, I don't see why Linear has to be multiplayer, but other CRUD apps don't.
2. When the abstraction is right, building apps with sync engines is easier than building traditional CRUD apps. The Linear team mentioned this themselves here: https://x.com/artman/status/1558081796914483201
One problem you may encounter with the 5 usd node: how do you handle multiple projects? You could put them all in one VM, but that set up can get esoteric, and as you look for more isolation, the processes won't fit on such a small machine.
With Instant, you can make unlimited projects. Your app also gets a sync engine, which is both good for your users, and at least in our experiments, the AIs prefer building with it.
And if you ever want to get off Instant, the whole system is open source.
I still resonate with a good Hetzner box though, and it can make sense to self-host or to use more tried-and-true tech.
For what it's worth, with Instant you would get a lot more support for easy projects. At least in our benchmarks, AI
Instant crosses that persistence boundary, your app can propagate updates to any one who has subscribed to the abstract datastore — which is on a server somewhere, so you the engineer don't have to write that code. Right?
But how is this different/better than things like, i wanna say, vercel/nextjs or the like that host similar infra?
This can work great, but you lose some benefits: your pages won't work offline, they won't be real-time, and if you make changes, you'll have to wait for the server to acknowledge them.
Instant pushes handles more of the work on the frontend. You make queries directly in your frontend, and Instant handles all the offline caching, the real-time, and the optimistic updates.
You can have the best of both worlds though. We have an experimental SSR package, which to our knowledge is the first to combine _both_ SSR and real-time. The way it works:
1. Next SSRs the page
2. But when it loads, Instant picks it up and makes every query reactive.
More details here: https://www.instantdb.com/docs/next-ssr
I'd suggest including a skill for this, or if there's already one linking to it on the blog!
npx skills add instantdb/skills
Would recommend doing `bunx/pnpx/npx create-instant-app` to scaffold a project too!
https://github.com/instantdb/instant/pull/2530
It should be live in a few minutes.
But pairing Instant with Vercel works great too! We have a tutorial on how you can build an app with Instant and deploy it to vercel here
Here is how I built it in a WUI: I sent SSE events from Server -> Client streaming web-search progress, but then the client could update a `x` box on "parent" widget using the `id` from a SSE event using a simple REST call. The `id` could belong to parent web-search or to certain URLs which are being fetched. And then whatever is yielding your SSE lines would check the db would cancel the send(assuming it had not sent all the words already).
You kick off an agent. It reports work back to the user. The user can click cancel, and the agent gets terminated.
You are right, this kind of UX comes very naturally with Instant. If an agent writes data to Instant, it will show up right away to the user. If the user clicks an `X` button, it will propagate to the agent.
The basic sync engine would handle a lot of the complexity here. If the data streaming gets more complicated, you may want to use Instant streams. For example, if you want to convey updates character by character, you can use Instant streams as an included service, which does this extremely efficiently.
More about the sync engine: https://www.instantdb.com/product/sync More about streams: https://www.instantdb.com/docs/streams
I cover it in the essay here:
https://www.instantdb.com/essays/architecture#:~:text=is%20t...
To summarize:
In places where we process throughput, we generally stick a grouped queue and a threadpool that takes from it. The mechanics for this queue make it so that if there's one noisy neighbor, it can't hog all the threads.
There's more too (runbooks, rate limiting systems, buffers, isolated instances), but I thought this particular data structure was really fun to share.
If Instant is compromised, then that's a lot more dangerous. We minimize this risk following security best practices: keeping data encrypted at rest, keeping secrets hashed at creation time, etc.
1. Unlimited projects: when you spin up traditional backends, you usually use VMs. It's expensive to start many of them. With Instant, you create unlimited projects
2. User experience: traditional CRUD apps work, but they don't feel delightful. I you want to support features like multiplayer, offline mode, or optimistic updates, you'll have to write a lot more custom infra. Instant gives you these out of the box, and the agents find it easier to write than CRUD code
3. Richer features: sometimes you'll want to add more than just a backend. For example, maybe you want to store files, or share cursors, or stream tokens across machines. These often need more bespoke systems (S3, Redis, etc). Instant already comes with these out of the box, and the agents know how to use them.
There are a few demo sections in the post that show this off. For example, you can click button and you'll get a backend, without needing to sign up. And in about 25 lines of code, you'll make a real-time todo app.
ladon86•1h ago
Would love to check out /docs but it's currently a 404.
nezaj•1h ago