Kinto

Last reviewed Sep 13, 2026 · 801 words

Kinto sits in the file-sync category and will disappoint anyone who arrives expecting a Syncthing. It does not move files between machines. It stores JSON records on a server and lets applications you write pull and push changes to them, offline-first, with revision tracking so two devices can reconcile. Firefox uses it under the hood for Remote Settings, which tells you the audience: developers who want a Firebase-style backend they control. If that is you, it does one job well. If you wanted to sync a folder, Syncthing is the page you need.

The data model fits on a napkin

Buckets contain collections, collections contain records. A record is any JSON object; the server adds an id and a last_modified timestamp in milliseconds. Permissions attach at every level, so one bucket can be world-readable while a collection inside it lets only its creator write, and a personal "default bucket" gives each authenticated user private space without any admin work. Authentication comes from the bundled accounts plugin (username and password) or from an OpenID Connect provider if you already run one.

That is the entire conceptual load. There is no schema unless you add one (the collection can carry a JSON Schema and reject records that fail it), no query language beyond filters on fields, and no joins. It is a document store with permissions, and it is deliberately small.

The sync protocol is the whole reason to pick it

Every list endpoint accepts _since=<timestamp>, returns only records changed after that point, and includes tombstones for deletions. Responses carry an ETag, writes accept If-Match so a stale client cannot silently overwrite a newer record, and the history plugin keeps an audit trail per record. The kinto.js client wraps this into a local IndexedDB store with sync() that pushes local changes, pulls remote ones, and hands you conflicts to resolve with a strategy (client wins, server wins, or manual).

This is what makes it a plausible Firebase replacement for a small app: the offline-first loop is designed in, not bolted on. Most "backend as a service" projects give you realtime subscriptions and leave the offline reconciliation to you.

Running it is 256 MB and one INI file

The catalogue's Medium rating is about the concepts, not the install. Kinto is Python, needs PostgreSQL for anything beyond a demo, listens on port 8888, and is configured by a single kinto.ini:

[app:main]
use = egg:kinto
kinto.storage_backend = kinto.core.storage.postgresql
kinto.storage_url = postgresql://kinto:kinto@postgres/kinto
kinto.cache_backend = kinto.core.cache.memory
kinto.permission_backend = kinto.core.permission.postgresql
kinto.permission_url = postgresql://kinto:kinto@postgres/kinto
kinto.includes = kinto.plugins.accounts kinto.plugins.history kinto.plugins.admin
kinto.userid_hmac_secret = replace-with-64-random-characters

Run kinto migrate once against that config, then kinto start, or use the kinto/kinto-server image with the file mounted in. The admin plugin serves a React UI at /v1/admin/ for browsing buckets and editing records by hand, which is more useful than it sounds during development. Memory use idles well under the catalogue's 256 MB. If you already keep a Postgres for other services, the Postgres for everything pattern applies and Kinto is one more database on it.

PocketBase is the safer pick for a new project

Kinto was first released in 2015, has 4,417 stars, a small community, and a maintenance pace tied to Mozilla's needs rather than yours. For a new side project in 2026 I would reach for PocketBase first: one Go binary, auth, realtime, file storage and an admin UI, with a far larger pool of people who can answer questions. If you want the database itself exposed with row-level security, Supabase is the other candidate, and the PocketBase vs Supabase page splits them.

Kinto still wins in exactly two cases. You need the revision-based sync protocol with a real offline client and per-record permissions, which PocketBase does not offer. Or your stack is already Python and you want a backend you can read in an afternoon and extend with a Pyramid plugin. Neither case is common, which is why the star count has stayed where it is.

What I'd do

Decide on the sync requirement first. If the app must work offline and merge cleanly later, run Kinto on Postgres with the accounts and history plugins, behind a reverse proxy, and build on kinto.js. If the app just needs a backend with auth and a table or two, use PocketBase and never think about Kinto again. Do not deploy it because it was listed under file sync; it is a developer tool, and a good one, for a narrow job.