Checking against doze Modules are the plugins that run Postgres, Valkey, Kafka and the rest. Add one to doze.hcl and doze fetches it for your machine, checks it, and pins it in doze.lock, so the next fetch is the same bytes.
No "most downloaded" sort: doze sends no telemetry, so nobody counts downloads. Why
doze AWS as one service: S3, SQS, DynamoDB, Lambda and 13 more on one endpoint, with its console.
$ doze add awsMongoDB-compatible: any Mongo client connects. FerretDB 2 over a private Postgres.
$ doze add ferretdoze Kafka: a Kafka-protocol broker in one Go binary. No JVM, no ZooKeeper, no KRaft.
$ doze add kafkaThe Redis protocol on RocksDB: durable, and the data lives on disk, not in RAM.
$ doze add kvrocksMySQL-compatible. Databases, users and grants declared in doze.hcl.
$ doze add mariadbReal Postgres, declared not scripted: roles, schemas, grants and extensions.
$ doze add postgresA local Temporal dev server with its Web UI. One Go binary, SQLite store.
$ doze add temporalIn-memory cache that speaks the Redis protocol: any redis client works.
$ doze add valkey"Needs" is the oldest doze each release is stamped with. On an older doze? Check the catalog against it: every module still has a release that runs on 0.1.1.
Not modules. doze add mongo writes a service block that runs your installed binary, a container or a pinned download. doze gives it a name, a port, sleep and wake; doze does not sign it.
Dates are when each build was uploaded: doze-dev/doze-modules for six modules, doze AWS and doze Kafka from their own repositories. Older releases on GitHub
$ doze add aws$ doze add ferret$ doze add kafka$ doze add kvrocks$ doze add mariadb$ doze add postgres$ doze add temporal$ doze add valkeydoze modules upgrade; a doze.lock already pinned keeps working until you do. 0.1.1 also has no doze add and uses the old syntax (postgres "orders" {}).Before doze 0.2 launched, every release in the index ran on 0.1.1; the [date] builds are the first stamped with an oldest doze.
From 0.2, doze reads each release's oldest doze itself: it skips releases it can't run and picks the newest one that fits. Only when none fits does it stop, with one of these. Shown for a future release that needs 0.3.0, on doze 0.2.0; doze 0.1.1 can't print them. (The lines wrap here; doze prints each on one line.)
postgres 17 needs doze 0.3.0 or newer; this doze is 0.2.0. Update doze (in the app: Settings › About), then run the command again
module doze/postgres 0.3.1 (pinned in doze.lock) needs doze 0.3.0 or newer; this doze is 0.2.0. Update doze (in the app: Settings › About); the lock was written by a newer doze
The release tool stamps each release with the oldest doze it needs, from the module SDK, always as three numbers: doze: "0.2.0". A release without the field runs on every doze. Today the field sits outside the signed part of the index; the design moves it inside.
| Module | Release | Uploaded | Oldest doze | On doze |
|---|---|---|---|---|
| ferret | 0.2.3 | 2 Nov 2026 | any (no field) | RunsNeeds newer doze |
| ferret 0.2.2 · 0.2.1 | 3 Jul · 2 Jul 2026 | any (no field) | RunsNeeds newer doze | |
| postgres | 0.2.4 | 2 Nov 2026 | any (no field) | RunsNeeds newer doze |
| postgres 0.2.3 · 0.2.2 · 0.2.1 | 3 Jul · 2 Jul 2026 | any (no field) | RunsNeeds newer doze | |
| temporal | 0.2.2 | 4 Jul 2026 | any (no field) | RunsNeeds newer doze |
| temporal 0.2.1 | 2 Jul 2026 | any (no field) | RunsNeeds newer doze | |
| kvrocks | 0.2.1 | 2 Jul 2026 | any (no field) | RunsNeeds newer doze |
| mariadb | 0.2.1 | 2 Jul 2026 | any (no field) | RunsNeeds newer doze |
| valkey | 0.2.1 | 2 Jul 2026 | any (no field) | RunsNeeds newer doze |
| aws | 0.2.0 | [date] | 0.2.0 | RunsNeeds newer doze |
| aws 0.1.1 · 0.1.0 | 18 Jul 2026 | any (no field) | RunsNeeds newer doze | |
| kafka | 0.1.2 | [date] | any (no field) | RunsNeeds newer doze |
| kafka 0.1.1 · 0.1.0 | 18 Jul · 17 Jul 2026 | any (no field) | RunsNeeds newer doze |