Deployment

A board can live in Git, SQLite or Postgres. Deploying it means choosing who reads its cards and who can change them. The right mode depends on whether you need to publish a snapshot, edit from one machine or let a team save changes from their browsers.

Data storage compares each method’s advantages, tradeoffs, backups and CLI, skill and MCP support.

Mode	Board changes and authentication	Saved settings
Static · no backend	Read-only build snapshot. Export move commands; the page cannot commit them. No GitHub sign-in or discovery of private sources.	Filters and layout: this browser only. Shared board configuration requires a commit and rebuild.
Local · local server	Commits to the checkout as its Git user; does not push. Local bearer token, no GitHub sign-in.	Card changes: local Git. Filters and layout: this browser only.
Hosted · remote backend with persistent authorization storage	Commits to each card’s source as the signed-in editor. Loads cards from all configured GitHub sources. GitHub App + backend required. CLI and MCP use source-bound tokens.	Card changes: Git. Configured sources, filters and layout: this browser only, separated by account. No preference sync between devices.
SQLite · Docker or Render with persistent disk	Stores changes and revisions in a database. GitHub login or explicit token access. GitHub and database sources can share one signed-in workspace. CLI and MCP use the same tokens and API.	Card changes: SQLite on persistent disk. Filters and layout: this browser only. No preference sync between devices.

What is remembered

The canvas remembers its filter, collapsed columns and panel sizes. Named filters are reusable views. Hosted entry loads every configured source into one canvas. Profile → Settings → Sources configures the sources; source: and project: filters select which cards to show. The setup page appears only when there is no source or no source can be read. Shared filters take precedence over the remembered view. A shared source link adds that authorized source to the workspace without hiding the others.

Browser preferences are not shared board configuration. Clearing browser data removes them; a browser that blocks storage keeps changes only for the current page. A backend makes card edits durable, but it does not currently store personal view settings. Columns and other board.yaml settings are edited in the source repository.

A valid hosted session can show its last checked board and repository list from browser storage while the backend revalidates them. Cached cards are read-only until access is checked again. The cache is bounded, tied to the backend, account session and configured sources, and discarded on sign-out or an authorization refusal. Confirmed card edits update the saved copy. The sync indicator describes backend data; personal preferences remain local.

GitHub authentication is a hosted capability, not a feature of GitHub Pages. The GitHub backend can run on your own HTTPS deployment. SQLite uses the same board API, with sign-in chosen independently of storage. Each GitHub source is a repository, branch and board folder, independently authorized by the backend. If one source fails, the others remain visible and its error appears in settings.

Static: the board as a published page

folio-agents build exports the kanban with the rest of the site. The page reads the board as it was at build time; a drag stages a move in the browser and Export moves prints the folio-agents board move commands to commit. Nothing runs after the build, so the export goes wherever static files go.

A static page can be published on GitHub Pages with deploy.provider: "github-pages" and the correct base path. Quickstart turns the canvas on. This site’s board uses a hosted API: GitHub Pages serves the page, and the backend supplies the authorized cards after sign-in.

Local: the board server on loopback

folio-board-server api runs beside the checkout that holds the board, and the same page edits cards, one commit per save. The server answers loopback only, asks for a bearer that is new on every start, and commits in the local checkout without pushing. Edit the board in the browser sets it up.

Hosted: a board a team edits

The kanban stays on GitHub Pages and the board server runs on Render, signed in with a GitHub App: collaborators edit from the browser, each commit under their own name, and nobody runs a machine. Deploy a hosted board takes it step by step.

SQLite: your own database and server

Choose board.store.kind: sqlite and a database file. The board API persists changes independently of GitHub. Keep the GitHub login and combine database and repository sources, or explicitly choose standalone token access. The server needs persistent storage, and view preferences remain in the browser. Configure SQLite covers local and HTTPS deployments.

Postgres: remote, portable persistence

Choose board.store.kind: postgres and a connection environment variable. Vanilla Postgres and Supabase use the same backend adapter. Database hosting, API hosting and sign-in remain separate choices. Postgres and Supabase documents configuration, free plan limits and backups.

Data storage

Git, SQLite, snapshots and browser storage: what each saves and costs.

SQLite

A persistent database, your own API and token access.

Deploy a hosted board

The GitHub App, Render, the kanban's api, and what each error in the log means.

Authentication

How people sign in, who reads, who writes, and whose name each commit carries.

Front and back

Why the page talks to a server, and the shapes that remain ideas.

Where it runs

Render today; a tunnel, the edge or a managed service as ideas.

API tokens and remote CLI connect tools to a single source. MCP serves the same operations at /mcp.

Render and Docker packages the API, SQLite, CLI and MCP with a persistent volume and documents the paid Render disk.