Any SQLite database, instant REST API. No config.
Every framework eventually makes you define a model, write a migration, create a controller, wire up routes. And then you're staring at SELECT * FROM users wrapped in forty layers of abstraction, thinking: the database already knows the schema. What are we doing here.
autocrud is 120 lines of bash. It reads an HTTP request, figures out which table you're asking about, runs the SQL, sends back JSON. It doesn't do anything clever.
socat pipes TCP to a script. sqlite3 runs queries and returns JSON. Both are old, stable Unix tricks:
DB_FILE=./myapp.db socat TCP-LISTEN:8080,reuseaddr,fork EXEC:./autocrud
Every table gets a REST API:
curl http://localhost:8080/api/users
curl http://localhost:8080/api/users/1
curl -X POST .../api/users -d '{"name":"Bob"}'
curl -X PATCH .../api/users/2 -d '{"name":"Rob"}'
curl -X DELETE .../api/users/2
Query parameters map to SQL. This convention comes from PostgREST:
GET /api/posts?select=title,body&user_id=eq.1&order=id.desc&limit=5
-> SELECT title, body FROM posts WHERE user_id = 1 ORDER BY id DESC LIMIT 5
The URL is the query. No ORM, no query builder.
| Method | Path | Runs |
|---|---|---|
| GET | /api/users | SELECT * FROM users |
| GET | /api/users/1 | SELECT * FROM users WHERE id = 1 |
| POST | /api/users | INSERT INTO users (...) VALUES (...) |
| PATCH | /api/users/1 | UPDATE users SET ... WHERE id = 1 |
| DELETE | /api/users/1 | DELETE FROM users WHERE id = 1 |
POST and PATCH read the JSON body and match keys to column names. A table with name and email accepts {"name":"Alice","email":"a@b.com"}. Extra keys are ignored. Missing columns get SQLite defaults. It reads pragma_table_info to know the columns, so any schema works.
This exists because other people did the actual work.
PostgREST figured out in 2014 that the database could be the backend. 40,000 lines of Haskell. If you need PostgreSQL at scale, use PostgREST.
Hasura took the same idea and built a platform around it: GraphQL, subscriptions, a web console. They raised over a hundred million dollars. That's not a dig. That's what it costs to do this right.
Datasette by Simon Willison proved SQLite deserves real tooling: exploration, visualization, publishing. Datasette is the gallery, autocrud is the vending machine in the lobby.
SQLite is one of the best pieces of software ever shipped. D. Richard Hipp put it in the public domain. The SQLite charter is three sentences long: "govern their interactions in accordance with the instruments of good works." That's the whole thing.
Douglas Crockford put "The Software shall be used for Good, not Evil" at the top of the JSON license and IBM formally asked for an exemption. This project borrows that license.
socat, bash, and sqlite3 have been on every Unix box for decades. The socat TCP-LISTEN EXEC: trick is at least twenty years old. All that happened here is someone noticed it worked and wrote it down.
apt install socat
That's the only one you might not already have. No package.json, no requirements.txt, no Docker, no build step.
autocrud is the answer to "what's the least I need to turn a SQLite file into a REST API." It's a single file you can read during a coffee break. It's useful for prototypes, hackathons, internal tools, and Raspberry Pis.
It is not fast (forks bash per request, maybe 30 req/s). It is not secure (single quotes are escaped, that's it). It is not a replacement for anything real. It's a 120-line script for when you need an API for a SQLite file and you need it now.
Should I use this in production? Probably not. Use PostgREST for PostgreSQL, Hasura for GraphQL, Datasette for exploration. Use autocrud when you need a quick API for a SQLite file and you're not mad at yourself.
Can I contribute? Please do. The whole thing is one file.
What's been built with this? If you make something interesting with autocrud, open an issue just to say so.