ilbert

Crazy how versatile SQLite is!

Nice suggestion! I've been working on https://github.com/ilbertt/nibrunner now to give people an easy and fast way to turn theri VPS into a microVM host

I build a lot of small apps, and often times most of the effort goes into the infra rather than the app. I typically only need a machine and a disk where to run the compiled binary, but I can't find it on any of the existing cloud solutions. The "batteries included" platforms give you Postgres and object storage but nowhere to run your own binary. Vercel and friends will run your code as a function with an ephemeral filesystem, so an SQLite file is gone the moment the request ends unless you configure additional services. Using a VM means ssh, a firewall to open, TLS to renew, and an OS to keep updated. They're all either difficult to configure and maintain or an overkill, or both.

It doesn't happen only when I build my apps, but also every time I find a good open-source project that ships as a single binary. Hosting it means one of the above again, or wrapping it in a container image when it was already deployable as a single file. Self-hostable single-binary projects are great until you have to host them.

So I built nibrun. You upload a binary executable, and you get an isolated Firecracker microVM (1 vCPU, 256 MiB) and an 8 GiB persisted volume. The volume is all yours to use, as if it was your local machine: write your SQLite file, JSONs, assets uploads. And it's instantly available via HTTPS. No extra config file or Docker image needed. It sleeps after 5 minutes idle and wakes up on incoming requests in ~120 ms.

For example, you can deploy PocketBase (single-binary Supabase clone) in one click: https://nibrun.com/deploy/pocketbase

And when you want to leave, the export button gives you back the binary and everything in the volume, so leaving only costs you the download of a zip file.

All open source, so you can even run the whole platform on your own AWS account: https://github.com/ilbertt/nibrun

Actually, after reading more carefully, it seems that custom notifications won't be supported anymore in favor of the `subscriptions/listen` RPC endpoint. Maybe the upcoming extensions will make it possible?

Thanks for sharing this SEP. Yeah some system notifications will go away, but servers will still be able to send custom notifications. Those can be turned into push notification on the device of the user or even actions that the user's device can do programmatically.

Really cool, same concept as Pocketbase.

Starred!

Software like this make me questioning a lot the defensibility of products such as Wispr Flow.

A friend of mine created something similar with just a few prompts, allo working locally, and he's stopped using Wispr Flow

That's actually the library that inspired me the most for building bun-sqlgen

sql<type>`query` is the reason why I started bun-sqlgen, to not have to write types manually

I've updated the READMEs by the way

Really cool! I see you don't discover the SQL in the code right?

Kysely is really cool, but I don't like that you are not writing SQL directly

No real reason, I was working with Bun's SQL module for a project and felt the need for such codegen. I'm thinking of generalizing it to Node.js

Yeah, I'm still iterating on the docs

I actually took a lot of inspiration from sqlx, which is really nice. The main differences are:

- in JS/TS you don't have compile-time scripts that you can run like with Rust's macros, so you need to run a codegen command before running the type checks (disadvantage)

- I had to create a TS parser that goes and finds the tagged template functions with the sql statements, while sqlx has them "for free" because sql statements are the input to the macro itself (disadvantage)

- I use an in-memory Postgres (PGLite) to describe the queries, instead of requiring a running pg instance (advantage)

- I don't cache the statements and codegen for now like sqlx does, something that can be added later

I think they are similar in that they both substitute the dynamic params with no-ops like $1, $2, etc. before handing the sql statement to the pg's DESCRIBE function

I was targeting Bun because I really like its built-in SQL module. I can tweak the TS parser to look for e.g. postgres.js tagged template functions and make it work for that as well. I don't really see any blockers

The cli config supports specifying the PGLite extensions (the codegen uses PGLite as an in-memory light postgres), see this example: https://github.com/ilbertt/bun-sqlgen/tree/main/examples/wit....

You'll still probably have to manually override some column types using PG comments like: https://github.com/ilbertt/bun-sqlgen/blob/dee757ebc9c38aec7...

PGLite extensions: https://pglite.dev/extensions/#postgis

I think with some tweaks to the TS parser that goes and looks for the sql statements it's doable. How are you solving the problem right now?

I write Bun.sql with raw SQL and no ORM, and the one thing I kept missing was types. You write a query, get back `any[]`, and hand-write a row type that silently drifts from the actual columns. Drizzle/Kysely fix this by moving the query into TypeScript, but then you're not really writing SQL anymore.

bun-sqlgen goes the other way. You keep writing raw SQL queries, just give each one a name.

A codegen step reads your migration `.sql` files, stands up a throwaway Postgres via PGlite (so no Docker) or SQLite, prepares every tagged query against it, and writes a `.d.ts` that maps each query name to its real result type. After that, plain `tsc` does the rest: `user.notExistingField` won't compile, and `display_name.length` gets flagged because the column is nullable.

Nullability was the annoying part. Postgres's describe doesn't hand you per-column nullability, so I infer it from the query plan plus the catalog, with manual overrides for the cases that genuinely can't be inferred. SQLite works too.

The runtime stays 100% Bun.sql, the generated file is the only artifact (commit it), and codegen is fast enough to rerun on save.

It's early (v0.1, built it for my own projects) so I'd mostly like to hear where it falls over.

In the last couple of companies I've worked in, I've felt both overwhelmed by PRs to review and disappointed by my teammates that were just rubber-stamping my PRs

That's a good framework and I like that the creator took the same design choices as the FastAPI framework.

Although I think a type-safe language is a better fit for CLIs, to let coding agents iterate faster and have less runtime bugs (help messages not updated, unknown flags, etc.)

I've noticed that the TypeScript ecosystem around CLIs is fragmented, and for that reason (and because I love type-safe code), I've built parsh.

It's extensible by design, and you can test single commands atomically.

I think there's a good opportunity for it to become the Next.js/Vercel of CLIs.

Repo: https://github.com/ilbertt/parsh

Great idea! Are you also considering fine-tuning models as a "side-effect"? Basically, you collect traces of the agent's mistakes from your proxy, and you fine-tune a smaller model that you can offer specifically for that agent as a cheaper alternative?

Really cool! Just as feedback, the 3D worldview seems to have low quality on my browser

It produces an arithmetic program but with wrong operands. The frozen LLM's hidden states for "two" and "2" are nearly orthogonal (cosine sim 0.09) in this context, so the head can't extract the right numbers. "2 plus 3" works fine and draws 5. The model understands the task structure but can't bridge word-form to digit-form without token generation

A self-hosted WhatsApp router for fleets of OpenClaws, called waclaw. It lets you host many OpenClaw instances behind a single WhatsApp Business account, acting as a "proxy" that routes the inbound messages to the OpenClaw instance associated to that phone number.

Really nice and simple stack: Bun + SQLite.

https://github.com/onfabric/waclaw

We built waclaw to let you host many OpenClaw instances behind a single WhatsApp Business. Inbound messages are routed to the right openclaw by phone number.

Good for personal use (one bot, one number) or for companies that want to give each of their users their own AI assistant reachable over WhatsApp.