Why I built this. In my work I make a lot of little tools and they all end up as spreadsheets. Spreadsheets are fine but the UI is limiting. I wanted real apps a non-technical person can just open and use, without standing up a server or making an account. So I borrowed the spreadsheet model and ran with it. Free and open source, because I like making things that help people.
getvessel.dev
Since a .vessel can carry code someone else wrote, isolation was the main thing I designed around. Each one runs sandboxed and can only reach the network origins it declares up front. Your data stays a plain SQLite file too. Unzip a .vessel and you can open the database in any SQLite tool. Nothing locked away.
getvessel.dev
#localfirst #selfhosted #privacy #sqlite #python #pyodide #ai #opensource
The use case that surprised me most: Vessel is a good home for AI-generated tools. Most AI artifacts are throwaway and spread across files a non-technical person won't touch. With Vessel, an agent can emit one real file with a working backend and a database that persists. There's an authoring skill in the repo, and every example in the gallery was built with it.
MCP server development is underway.
getvessel.dev
A bit on how Vessel works under the hood. The Python backend runs under Pyodide in a Web Worker, so there's genuinely no server in the loop. The worker can't even open a socket. The UI talks to FastAPI through a fetch bridge, and SQLite rides along inside the file. All local, all offline.
getvessel.dev
#pyodide #python #webassembly #sqlite #opensource #localfirst
I made a thing called Vessel. A .vessel is a single file holding an app's whole UI, a Python (FastAPI) backend, and an SQLite database, with the data living right inside the file. You install a small host once, then any .vessel opens locally and runs like a normal app. Think of it like a spreadsheet, except the document is a real web app instead of a grid!