Vikunja: a self-hosted task manager under AGPL-3.0
The task manager you actually own.
At a glance
- What is it?
- Vikunja is a Go and Vue task manager you host yourself, with an OpenAPI-documented backend and a Docker image. It fits teams that need to own the data and can run a server; it is the wrong pick if you want zero operational work or a permissively licensed codebase.
- Who is it for?
- Adopt Vikunja if you are willing to run a Go service plus a database and you want the task data on your own hardware. Do not adopt it if your organisation cannot accept AGPL-3.0-or-later terms, or if you need admin panels, audit logs or time tracking, which the README places behind Vikunja Pro.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Vikunja targets: task data you do not control
Hosted task tools hold your projects, due dates and comments on someone else's infrastructure. The repository's own tagline is "The task manager you actually own", and the topics list confirms the positioning: self-hosted, api, todo. The intended user is a person or team that already runs a server and treats task lists as data worth keeping in-house, not a marketing team that wants a SaaS seat per person. The project is written in Go with a Vue frontend, which matters for the audience: a single compiled backend binary plus static assets is a different operational shape from a Rails or Node app with a build pipeline at runtime. Vikunja also publishes an official Docker image, so the common deployment is a container plus a database rather than a hand-built binary. The README does not enumerate features itself; it points to the features page on vikunja.io and to a live demo at try.vikunja.io. That is a deliberate split. The repository stays thin and the documentation site carries the detail. If you are evaluating Vikunja, the README alone will not tell you whether it supports the specific view or sharing model your team uses.
Architecture as visible from the repository layout
Three things are visible without running anything. First, a Go backend that exposes a documented HTTP API: the README links an OpenAPI description at try.vikunja.io/api/v2/docs, and the badge labels it swagger-docs. Second, a Vue-based web frontend, indicated by the vuejs topic. Third, a separate desktop client: the licence section states that the contents of desktop/ are licensed under GPL-3.0-or-later, distinct from the rest of the repository. That directory split is the clearest architectural signal in the material. The server and the desktop app are separate deliverables with separate licences, and the API is the contract between them. For an integrator this is the useful part: anything the desktop client does, a script can do against the same API, provided the OpenAPI description covers that endpoint. The README does not describe the data model, the database engine, or how background jobs are scheduled. Those details live in the linked docs, and I cannot confirm them from the supplied material. What can be confirmed is that the project treats its API as a first-class artefact rather than an internal detail.
Installing: what the README actually gives you
The README is short on commands and long on pointers. It links an Installing page, a Build from source page, a Development setup page, a Magefile page and a Testing page, all under vikunja.io/docs. The download badge points at the v2.6.0 release, and the Docker badge points at the vikunja/vikunja image on Docker Hub. So the two supported paths visible here are the published container and a source build. The source path uses Mage, since a Magefile page exists in the docs index; the exact targets are not reproduced in the README and I will not invent them. Configuration keys are likewise not listed in the README. The one concrete operational fact the README supplies is the version: v2.6.0, released 2026-08-31, following v2.5.0 on 2026-08-04 and v2.4.0 on 2026-07-19. That cadence matters when you plan upgrades. Three minor releases in roughly six weeks means the install docs and the API description can drift from the tag you pinned. Read the Installing page for your target version rather than the current one.
Where Vikunja is the wrong tool
The README draws a commercial boundary that is easy to miss. Vikunja Pro is described as the option for teams that need an admin panel, audit logs or time tracking. Those are not in this repository. If your compliance process requires an audit trail of who changed which task and when, this codebase does not provide it, and no amount of self-hosting changes that. The second boundary is operational. Vikunja is a server application with a database behind it. There is no statement in the README about a single-file or embedded mode, so treat it as a service you must run, back up and upgrade. A solo user who wants a local task file is over-served here. The third issue is the note near the top of the README: LLM-assisted coding tools are used in various parts of the codebase, and most contributions from the @tink-bot account are built that way. That is disclosed openly, which is to the project's credit, but it is a real consideration if your review process requires provenance for every commit. The README does not quantify which parts of the codebase are affected.
Alternatives and how the approach differs
The obvious comparison is a hosted task service. The difference is not features, it is where the data lives and who holds the upgrade key. With a hosted tool you get an admin panel and audit history as part of the product, which is exactly what the README puts behind Vikunja Pro. With Vikunja you get the schema and the database, and you accept that you are the operator. A second comparison is a plain file-based task list synced through a repository or a shared folder. That approach has no server, no database and no API, and it costs nothing to run. It also has no concurrent editing model and no per-user permissions. Vikunja's API and Vue frontend exist precisely to solve those two problems, and that is the trade you are making: a service to operate in exchange for multi-user access and a stable integration surface. A third comparison is any self-hosted project tracker that bundles time tracking. Vikunja's README sends that requirement to the paid tier, so if bundled time tracking is a hard requirement, Vikunja is not the fit regardless of licence.
Licence and what AGPL-3.0-or-later implies for integrators
Most of the repository is AGPL-3.0-or-later, and desktop/ is GPL-3.0-or-later. The AGPL matters most if you modify the server and let users reach it over a network. Under that licence family, network use is the trigger that the GPL does not have. If you embed Vikunja's API behind your own product, or fork the backend and expose it to users, the copyleft obligations attach to the modified work. That is a design constraint, not a footnote, and it is the single most common reason a company rules Vikunja out. The desktop split is worth noting for a different reason: a GPL-3.0-or-later client talking to an AGPL-3.0-or-later server is a deliberate separation, so you cannot assume a single uniform licence across everything you ship. The README also notes that background images from Unsplash are distributed under the Unsplash License, which requires crediting the photographer and Unsplash. If you strip or replace those assets, read the terms. None of this is legal advice; get your own counsel before shipping a modified Vikunja.
Maintenance cost and upgrade cadence
Three minor releases between 2026-07-19 and 2026-08-31 is a fast cadence for a self-hosted service. The practical consequence is that pinning a version is not optional. If you deploy the vikunja/vikunja image without a tag, you are tracking mainline and inheriting every migration the project ships. The README does not describe the database migration process or whether downgrades are supported, so I cannot tell you what a rollback looks like. That is a gap worth closing before you put real project data in. The repository's last push is 2026-09-10, shortly after the v2.6.0 release, so the project is active. Activity is not the same as stability, and the release notes are the place to check for breaking changes between v2.4.0, v2.5.0 and v2.6.0. The README also links a roadmap hosted on Vikunja itself, at my.vikunja.cloud, which is a neat demonstration that the maintainers run their own product. It also means the roadmap lives outside the repository and can change without a commit.
Editorial conclusion
Adopt Vikunja if you are willing to run a Go service plus a database and you want the task data on your own hardware. Do not adopt it if your organisation cannot accept AGPL-3.0-or-later terms, or if you need admin panels, audit logs or time tracking, which the README places behind Vikunja Pro. Before committing, verify three things: that the v2.6.0 Docker image starts against your chosen database, that the OpenAPI description at try.vikunja.io/api/v2/docs matches the version you deploy, and that the desktop client's GPL-3.0-or-later licence is acceptable alongside the AGPL-3.0-or-later server.
Community notes