Run it yourself. Nothing held back

The hosted plan is a convenience, not a lock. The same code that runs the hosted one is the code you can run, and there is no edition with the good parts missing.

Five commands

Point Tuval at a Postgres it can reach, apply the migrations, lift the hosted-service limits, and build the folder of static files. Read every one of them first if you like; they are in the repository.

• git clone https://github.com/namlifurkan/tuval && cd tuval
• cp .env.example .env.local # add your Supabase URL and anon key
• npx supabase db push # apply the schema
• psql -c "update public.tuval_settings set self_hosted = true where id = 1" # lift seat, storage and API limits
• npm install && npm run build # serve dist/ from anything

What it needs

A Supabase project

Hosted Supabase or the self-hosted stack. The schema is a folder of migrations you can read before you run them.

Object storage

The private Supabase Storage bucket created by the migrations holds images and attachments behind signed URLs.

Any static file host

The app builds to a folder of files. Anything that can serve them with the documented SPA fallback will do.

Nothing is held back

No separate edition and no feature flags. Seats, storage and the API are limited on the hosted plan because those are what cost money to serve; on an install you run yourself they are not limited at all.

Access is decided by the database

Every rule about who may read or write what is a row-level security policy, proven by a suite of access checks that runs against the real schema before any change ships. An interface that hides a button is not security; this is.

And you can leave

One file holds every page, board, issue, database, tag and link, and restores into any workspace.