# Tracks is a Rails implementation of the GTD workflow that predates most task apps > Tracks is a self-hosted GTD web application built on Ruby on Rails, with a project hierarchy, contexts, lists and a review cycle, and it is GPL-2.0 licensed with a Docker deployment path. It fits a team that wants its own server and the GTD vocabulary rather than a modern kanban board, and it does not fit a user who wants a native mobile app or a fast-moving modern interface. **TracksApp/tracks** — Tracks is a GTD™ web application, built with Ruby on Rails - Repository: https://github.com/TracksApp/tracks - Website: https://www.getontracks.org/ - Stars: 1,239 · Forks: 530 - Language: Ruby - License: GPL-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/tracksapp-tracks ## GTD is the specification, and the vocabulary is the product Tracks describes itself as a GTD compatible web application built with Ruby on Rails, and the repository description repeats that framing, though the project is presented as a personal productivity system with a team flavour. The compatibility with the Getting Things Done methodology is the point. David Allen's system has a specific vocabulary: inboxes, projects, next actions, contexts, and a weekly review that closes one cycle and opens the next. An application that implements those categories faithfully does something a generic to-do list cannot, because the categories are where the discipline lives. A next action with a context and a project is a different object from a task with a due date. The structure of the data model is what makes the app useful rather than merely compliant. A project has a list of next actions, and those actions carry a context that says where they happen, and they belong to a list that says what kind of work they are. The weekly review is where the system either holds together or does not, and having the application model the review explicitly is what keeps the inboxes from silently accumulating. The project is GPL-2.0, the primary language is Ruby, and the last push was on 2026-08-03. The homepage is getontracks.org, with a manual at the same site, and there is a hosted Tracks service listed in the wiki for people who do not want to run their own. ## The deployment is a Dockerfile with a MariaDB service beside it The repository carries a Dockerfile and a docker-compose.yml, and between them they describe a fairly conventional Rails deployment. The compose file has two services. The db service runs mariadb:lts with MARIADB_ALLOW_EMPTY_ROOT_PASSWORD set to 1 and the database name taken from a TRACKS_DB variable defaulting to tracks, with a named volume db-data mounted at /var/lib/mysql. The web service builds from the local context with the target set to production, and it depends on the db service. The environment passed to the web container is RAILS_ENV, DATABASE_NAME, DATABASE_USERNAME and DATABASE_PASSWORD_EMPTY, with a comment explaining that these are set in script/ci-build so they need to be passed through. Two configuration files are mounted over the container's own, config/database.docker.yml as database.yml and config/site.docker.yml as site.yml, and the whole working directory is mounted at /app with the Z volume flag for SELinux. Port 3000 is published. The Dockerfile is a multi-stage build on ruby:3.3, with a base stage that installs npm, netcat-openbsd and yarn, installs bundler, and copies the application in a deliberate order: configuration and scripts first, then lib, app and db, then the Gemfile, with the .gi[t] glob trick to copy the .git directory if it exists, since the code is sometimes a release archive rather than a clone. The final command is ./bin/rails server -b 0.0.0.0 with /app/docker-entrypoint.sh as the entrypoint. The stage structure is the sensible Rails pattern. A precompile stage runs bundle install with deployment configuration and rake assets:precompile, and the production stage copies the compiled assets from it while installing without the assets group and with a frozen bundle. There is a test stage and a development stage alongside. The practical consequence is that a Tracks deployment is a Rails app, a MariaDB and a reverse proxy, and the compose file is a starting point rather than a finished setup. ## The project is old, and the maintenance is in a small set of hands The credits section tells you who to thank and, more usefully, who to talk to. The original developer is bsag. The principal maintainer is Jyri-Petteri Paloposki, also known as ZeiP, sponsored by Ardcoras oy and also available for paid consulting, and the README suggests subscribing to the hosted version to support the maintainer's work. There is a contributors wiki page, a mailing list on Google Groups, and a wiki for hosted services. The release history shows the pace. The versions are v2.7.1 from 2024-07-25, v2.7.0 from 2024-06-17 and v2.6.1 from 2022-08-14, with the last push on 2026-08-03. That gap between the last release and the last push is a pattern rather than a one-off. The repository is not archived and the badges show a live CI, a Code Climate score, a Weblate translation status and the CII Best Practices badge, so the project is not dead. But the release cadence is a couple of times a year at best, and a Rails application of this age accumulates dependencies that need attention. The badges are also a signal about the project's own standards. CII Best Practices, Code Climate and continuous integration are all tracked, and the repository carries a.rubocop.yml for Ruby style, a.ruby-version pinning the interpreter, a SECURITY.md and a.codeclimate.yml. There is a Dockerfile, a docker-entrypoint.sh and a docker-compose.yml, and a doc/ directory that the Dockerfile copies into the test stage specifically for testing the API client. ## The repository layout is a classic Rails application with some extras The top-level listing is the standard Rails skeleton, which tells you what to expect and where the interesting parts are. There is app/ for the application code, config/ for the configuration, db/ for the migrations and seeds, lib/ for libraries, test/ for the test suite, and the usual bin/, config.ru, log/, public/, script/ and vendor/ directories. The Gemfile and Gemfile.lock sit at the root with a Rakefile, and mkdocs.yml with a doc/ directory indicates the documentation is built with MkDocs. Three additions are worth noting. The .ruby-version file pins the Ruby version, which is the single most useful file for anyone trying to run this on a current system, since a Rails application of this vintage often needs a specific interpreter. The docker-compose.yml and Dockerfile provide the container path. And the test-envs/ directory suggests the project tests against more than one environment configuration, which is what you would expect from an application whose install instructions cover both fresh installs and upgrades from older ones. The .dockerignore and .gitignore are both present, and the .github/ directory holds the workflows behind the continuous integration badge. ## Upgrades are the part of the documentation that gets the most space One line in the README carries more operational weight than the rest of the About section, and it is worth reading twice. Full instructions for both new installations and upgrades from older installations of Tracks can be found in the wiki, at the Installation page. And then: as always, make sure that you take sensible precautions and back up all your data frequently, taking particular care when you are upgrading. That is an admission about the shape of the project. A self-hosted Rails application with years of schema migrations, with a data model built around projects, contexts and lists, has an upgrade path that is not fully automatable. The maintainer knows it and says so plainly. The wiki also lists hosted services for people who want the application without running it, and the manual lives at /manual/ on the project homepage, alongside the wiki installation instructions. There is also a dedicated SECURITY.md in the repository, so vulnerability reports have a stated channel, and the GitHub issues page is listed for both bug reports and feature requests. The contribution path is documented too. If you want to contribute towards the development of Tracks, read CONTRIBUTING.md for general information, with more on development, testing and contributing in the wiki. ## Where Tracks is the wrong tool The first wrong-tool case is a user who wants a modern interface. The application is a Rails app with a server-rendered frontend, and the design vocabulary is the GTD one, with a review cycle and inbox lists rather than a board, a calendar or a chat. A team moving to Tracks from a modern task tool is choosing a different way of working, not just a different skin. The second is mobile. The README describes a web application, and there is no native client mentioned anywhere. If your requirement is an app on a phone with push notifications and offline capture, this is the wrong project, and the hosted service is a web app too. The third is an organisation that needs a supported product. The maintenance is concentrated in one principal maintainer, sponsored by a company, with consulting available and a hosted service on a subscription. The release cadence of a couple per year and a GPL-2.0 codebase mean that owning the deployment, the dependencies and the upgrades is part of the cost. The fourth is a team that wants to use an existing identity and permission system. The data model is personal productivity, with projects, contexts and lists, and the team aspect is the shared deployment rather than per-user access control baked into the domain model. An organisation that needs projects, portfolios and access rules as first-class objects is looking at a different category of tool. The last push was on 2026-08-03, so the code is being worked on, and the licence being GPL-2.0 means a hosted or distributed deployment carries copyleft obligations that a permissively licensed alternative would not. ## Conclusion Tracks fits a team or individual who wants to self-host a GTD system with a defined project, context and list vocabulary, and who is comfortable running a Rails application and its database. It does not fit a user who wants a native mobile client or a modern realtime interface. Before deploying, read the wiki installation instructions for both new installs and upgrades, and plan for the fact that this is a mature Rails codebase with a dated frontend, so the modernisation effort sits with you rather than with the project. ## FAQ ### What is Tracks? Tracks is a GTD compatible web application built with Ruby on Rails, organised around the Getting Things Done vocabulary of projects, contexts, lists and next actions. The project homepage is getontracks.org, with a manual and wiki, and the source is on GitHub. ### How is Tracks deployed with Docker? The compose file runs a mariadb:lts service with a named volume for the data, and a web service built from the local Dockerfile with the production target, mounting config/database.docker.yml and config/site.docker.yml over the container's configuration and publishing port 3000. The Dockerfile is a multi-stage build on ruby:3.3 that precompiles assets and starts the server on 0.0.0.0. ### What licence is Tracks released under and who maintains it? Tracks is GPL-2.0 licensed, with the licence text in the COPYING file. The original developer is bsag and the principal maintainer is Jyri-Petteri Paloposki, sponsored by Ardcoras oy, and a hosted version is available on subscription to support the work. ### How do I upgrade an existing Tracks installation? The README points to the wiki installation page for both new installations and upgrades from older installations, and advises taking sensible precautions and backing up all data frequently, with particular care when upgrading. The project is a mature Rails application and the upgrade path is documented separately from the code. ## Sources - [License: GPL-2.0](https://github.com/TracksApp/tracks/blob/master/LICENSE) - [Project website](https://www.getontracks.org/) - [README](https://github.com/TracksApp/tracks/blob/master/README.md) - [Releases](https://github.com/TracksApp/tracks/releases) - [TracksApp/tracks on GitHub](https://github.com/TracksApp/tracks) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tracksapp-tracks