traggo/server: self-hosted time tracking where tags replace tasks

The problem: your work is not a list of tickets

Most time trackers assume a hierarchy. You have clients, clients have projects, projects have tasks, and you pick one before the clock starts. That model breaks down for people whose day is a sequence of overlapping activities rather than a queue of items. The README states the design position plainly: in Traggo there are no tasks, only tagged time spans. A span is a stretch of recorded time. A tag is a key and value you attach to it. If you work across several projects, the README suggests a project tag. If you want to see where your hours go by activity, it suggests a type tag with values like email, programming, or meeting. Nothing forces that vocabulary on you. You can define it however you like, and the same span can carry several tags at once, which is the part a task list cannot do without duplicating entries. The audience is narrow and specific: someone who is willing to run a server, who cares that no third party can read the data, and who would rather shape their own reporting dimensions than accept a vendor's project model. The README frames self-hosting as the point, not an option: if you want to use Traggo, you need to host it yourself.

Tags and timespans instead of tasks and projects

The data model is the whole product. A recorded entry is a time span with a start and an end, and it carries tags. Because tags are free-form key and value pairs rather than a fixed schema, the same underlying records can be sliced in ways the author of the tool never anticipated. A span tagged project=acme and type=meeting can appear in a project breakdown and in an activity breakdown without being entered twice. That is the mechanism that makes the dashboard feature meaningful: the diagrams are built from whatever tag dimensions you have created, so the quality of your reporting depends on the consistency of your tagging, not on features the server adds for you. This is the trade-off to understand before you install anything. A task-based tracker enforces structure and therefore produces comparable data across users. Traggo enforces nothing. Two people on the same instance can use incompatible tag vocabularies, and the server will not warn either of them. The README's phrase about being as customizable as possible is accurate, and it is also the source of the main operational risk: the tool gives you a blank schema and no opinion about what belongs in it.

What the web UI actually gives you

The README lists a list view of tracked time, a calendar view, and customizable dashboards with diagrams. Screenshots for all three are linked from the repository under .github/traggo_list.png, .github/traggo_calendar.png, and .github/traggo_dashboard.png. The list view is the raw record: spans and their tags. The calendar view places those spans on a day or week grid, which is the view most people use to spot gaps and overlaps after the fact. Dashboards are where tags pay off, since a diagram is only as useful as the tag dimension you point it at. There is also a theme system, described as multiple themes, and simple user management, which the README lists without further detail. That last point is worth flagging: the word simple is doing real work. There is no description in the supplied material of roles, permissions, or how users are separated, so if you need per-user access boundaries you should confirm that on the configuration page rather than assume it. The same applies to the API surface. Traggo has a web UI and it has a server, but the README does not document an HTTP API, so do not plan an integration around one until you have checked the documentation.

Getting it running: install, config, and the dev path

The README does not embed install commands. It points to three pages on the project site: traggo.net/install/ for installation, traggo.net/config/ for configuration, and traggo.net/dev/setup/ for a development environment. A Docker image exists and is referenced by the README's badge, which links to the hub.docker.com/r/traggo/server repository, so a container is one supported path. Beyond that, the supplied material does not name a database, a port, a config file path, or an environment variable, and I am not going to invent them. Treat the config page as required reading before you plan a deployment, because the choices there determine what you are backing up. The development setup page matters even if you never write Go: it is the only place in the linked documentation that describes how the server is assembled and run from source, and reading it is the fastest way to understand which components you are actually operating. Versioning follows SemVer, per the README, and releases are tagged on the repository. The newest listed release is v0.8.3 from March 2026, with v0.8.2 and v0.8.1 before it in January 2026.

Where it stops being the right tool

Traggo does not do billing. Nothing in the README mentions rates, invoices, clients with budgets, or exports. If your time data has to become a document someone pays against, you will be reconstructing that outside the tool, and the free-form tag model makes it harder rather than easier, because there is no guaranteed rate field to multiply against. The second limitation is structural. Because there are no tasks, there is no notion of an assigned item, a status, or a completion state, so you cannot use Traggo to answer what is left to do. It answers where the time went, and only after you have decided what dimensions to record. The third is the blank schema problem in its practical form: if you start recording before you settle on a tag vocabulary, you get a dataset that is expensive to clean up later, and the tool offers no migration path for retagging at scale that the supplied material describes. Finally, this is a self-hosted server with a single maintainer-scale release cadence, three releases in the first quarter of 2026 and a master branch that was pushed more recently than the newest tag. You are taking on the upgrade and backup work yourself.

How it differs from task-based trackers

The obvious comparison is to a task-oriented tracker such as Kimai, which is also self-hosted, also open source, and also aimed at people who want their time data on their own hardware. The difference is the starting unit. Kimai's model is built around customers, projects, and activities, which means the reporting you get is the reporting the schema anticipated: hours per customer, per project, per activity, with rates attached. Traggo's starting unit is an untagged span, and every dimension you report on is one you invented. That inverts the setup cost. With a task-based tracker you spend time entering customers and projects before you can record anything useful. With Traggo you can start recording in seconds and spend the effort later, or never, deciding how to slice the data. The cost of that freedom shows up the first time you want a number the tag vocabulary does not produce, because there is no rate table to fall back on and no fixed hierarchy to aggregate. If your reporting needs are known and stable, the task model is less work. If they are not, Traggo's approach is the one that survives contact with a changing job.

Licence, maintenance, and what you are signing up for

Traggo is licensed under GPL-3.0. If you run it for yourself or inside your own organisation, the practical effect is that you receive the source and can modify it. If you intend to distribute a modified version, or to offer it to others as a service, the copyleft terms attach to what you distribute, and that is a question for your own legal review rather than something to settle from a README. On maintenance: the repository is not archived, the default branch is master, and the last push recorded is 2026-07-31, which is later than the newest release tag, v0.8.3 from 2026-03-01. That gap is normal for active development but it means master and the released artifact are not the same thing, so pin to a tag rather than tracking the branch if you want reproducible upgrades. Upgrading means reading the release notes for the versions between yours and the target, and since the tool stores your entire time history, the backup step matters more than the upgrade step. The README does not describe a backup procedure or a schema migration policy, so that is a gap you have to close yourself by reading the configuration page and understanding where the data lives.

Editorial conclusion

Adopt traggo/server if you want your time data on your own hardware and you are comfortable deciding your own tag vocabulary before you start recording. Do not adopt it if you need billing, invoicing, or per-client reporting generated by the tool itself; the README lists time tracking, dashboards, list and calendar views, themes, and simple user management, and nothing about money. Before committing, read the install and configuration pages at traggo.net, confirm which database backend your deployment will use, and check the release notes for the gap between the v0.8.3 tag and current master, since the last push to master is later than the newest release.

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. traggo/server on GitHub