Donetick: a self-hosted task and chore manager for shared households

The chore-assignment problem Donetick targets

Most to-do apps are built around one person and one list. Donetick is built around a group. The README describes creating a group, then sharing or assigning tasks and chores with the people in it. That single design decision drives most of the feature list: assignee rotation, shared labels, a dashboard any user can pick their account from, and realtime sync across connected devices.

The scheduling model is where it diverges from a generic task list. Recurrence can be anchored to the previous due date or to the actual completion date, and the README frames the trade-off directly: due-date recurrence keeps a consistent cadence, completion-date recurrence suits tasks that are often late. There is also adaptive scheduling, which the README says learns from historical completions to suggest due dates.

Who it is for: someone already running a home server or a NAS, who wants the household chore list to live on their own hardware rather than in a vendor account. The App Store and Play Store are not the distribution channel here. Docker is.

How the pieces fit: Go backend, React frontend, SQLite or Postgres

The repository is a Go module named donetick.com/core, with go.mod declaring Go 1.24.0 and a go1.24.3 toolchain. The top level contains main.go, internal/, migrations/, frontend/, config/ and external/, which tells you the split: a Gin-based HTTP server, SQL migrations applied through rubenv/sql-migrate, and a separately built React frontend.

Database access goes through GORM, and go.mod carries both glebarez/sqlite and gorm.io/driver/postgres, so SQLite and Postgres are both supported backends. The Docker quick start sets DT_SQLITE_PATH=/donetick-data/donetick.db, which is the SQLite path. Persistence is a mounted volume, not a managed service.

Background and integration work is visible in the dependency list: telegram-bot-api, pushover, gomail, aws-sdk-go for S3-compatible photo storage, gorilla/websocket for the realtime sync, pquerna/otp for TOTP multi-factor auth, and appleboy/gin-jwt for tokens. The README notes there are two API surfaces, a full REST API and an eAPI intended for long-lived access tokens, and recommends the eAPI for external use. That distinction matters if you plan to script against it.

Installing Donetick with Docker and running it for the first time

The README is explicit that the application will not run without a valid selfhosted.yaml. It points to config/selfhosted.yaml in the repository as the example to copy, and says the file belongs in the /config directory.

Start by pulling the image:

docker pull donetick/donetick

Then run the container. The README's example maps host directories for data and config, publishes port 2021, sets DT_ENV to selfhosted, and points DT_SQLITE_PATH at the database file inside the mounted data volume:

docker run \
  -v /path/to/host/data:/donetick-data \
  -v /path/to/host/config:/config \
  -p 2021:2021 \
  -e DT_ENV=selfhosted \
  -e DT_SQLITE_PATH=/donetick-data/donetick.db \
  -e TZ=Etc/UTC \
  donetick/donetick

The README also gives a Compose template with the same environment variables and a healthcheck that probes /api/v1/health:

services:
  donetick:
    image: donetick/donetick
    container_name: donetick
    restart: unless-stopped
    ports:
      - 2021:2021
    volumes:
      - ./data:/donetick-data
      - ./config:/config
    environment:
      - DT_ENV=selfhosted
      - DT_SQLITE_PATH=/donetick-data/donetick.db
      - TZ=Etc/UTC

After the container is up, browse to port 2021 on the host and create the first account. From there the README's flow is: create a group, add the people who share the chores, then create a task. Natural-language entry is the fastest first use, since the README says phrases like "Change water filter every 6 months" or "Take the trash out every Monday and Tuesday at 6:15 pm" are parsed into dates, times and recurrence patterns.

One caveat on the repository's own docker-compose.yaml: it is a development file. It builds from the local Dockerfile, uses DT_ENV=prod, mounts ./data at /usr/src/app/data, and maps host port 8085 to container port 8000. Do not copy it as a production template. Use the README's Compose example instead.

Where Donetick gets in your way

Offline support is the clearest limitation, and the README states it plainly: you can access Donetick if you lose connection and navigate some areas, but this is very limited functionality at the moment. For a wall-mounted tablet or a phone used around the house, that is survivable. For someone who wants to tick off chores on a commute with no signal, it is not.

The mobile clients are not finished either. The README describes the iOS app as an alpha on TestFlight and the Android app as an APK available in releases. Neither is presented as a stable store release.

Photo attachments have a partially implemented path: the README marks local storage as WIP and lists S3, Cloudflare R2, MinIO and other S3-compatible services as the working option. If you want photos without an object store, the documentation does not promise that today.

There is also an operational cost the README does not paper over. The selfhosted.yaml requirement means the container fails without a config file you supply, so a first run that skips that step produces a container that does not serve anything useful. Configuration is a prerequisite, not a wizard.

Finally, the project is on a 0.1.x version line, with recent releases including beta tags such as v0.1.80-beta.1. Treat schema and API behaviour as moving.

Donetick compared with hosted to-do apps

The obvious alternative is a hosted app like TickTick, and the difference is not features so much as custody. A hosted app gives you sync, mobile clients and uptime without a server. Donetick gives you the database file. Your chores, your points history and your completion analytics stay on your disk, and the trade is that you are the one who upgrades the container and keeps the volume backed up.

Super Productivity sits closer in spirit, being an open-source task tool, but it is a client-side application rather than a server you host for a group. Donetick's group model, assignee rotation and shared labels assume a shared backend that several people reach over the network. If your use case is one person on one machine, a local task app is less machinery.

Against a plain shared calendar or a spreadsheet, Donetick's advantage is the completion model. Completion restrictions, subtask reset on recurring tasks, and the points system all depend on recording who did what and when, which a calendar entry does not capture. The cost is that you now run a service to hold that record.

Maintenance, upgrades and the AGPL-3.0 licence

The repository is not archived, and the last push was on 2026-08-19, so it is being changed. The release cadence visible in the release list is fast, with v0.1.79 and v0.1.80-beta.1 landing a day apart, which cuts both ways: fixes arrive quickly, and so do changes you may not want mid-cycle. Running a beta tag on a household chore list is a choice, not a default.

Upgrading means pulling a new image and restarting the container. The migrations/ directory and the sql-migrate dependency indicate schema migrations run as part of startup, so the practical precaution is a copy of the SQLite file or a database dump before you pull. The README does not document rollback, so there is no documented path back to a previous schema.

The build is reproducible in the ordinary sense: the Dockerfile is a two-stage build with CGO_ENABLED=0, and VERSION and COMMIT are injected through ldflags so /api/v1/resource and the health endpoint report the exact build running. That is useful when you need to confirm which image a container is actually serving.

On licensing, Donetick is AGPL-3.0. For a household running its own instance, that is unremarkable. If you intend to offer a modified Donetick to other people over a network, the AGPL's source-availability terms are the part to read, and that is a question for a lawyer rather than for this article. The repository also carries a Stripe dependency and the search data references a paid tier, so a hosted or commercial offering exists separately from the self-hosted code.

Editorial conclusion

Adopt Donetick if you want a self-hosted chore tracker where recurring tasks, shared labels and assignee rotation matter more than a polished mobile client, and you are comfortable running a container with a mounted config directory. Do not adopt it if you need dependable offline use, since the README describes offline support as very limited, or if you want a managed service you never administer. Before committing, verify that your selfhosted.yaml matches the example in config/selfhosted.yaml, that DT_SQLITE_PATH points at a writable volume, and that /api/v1/health returns healthy after a restart.

Frequently asked questions

Official sources

1. donetick/donetick on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases