Kimai: a self-hosted, AGPL time tracker built on Symfony and Doctrine
Kimai is the #1 open-source time-tracking application. From freelancers to companies and organisations - everyone can manage timesheets, generate reports, create invoices and so much more... Web-based multi-user application, available as On-Premise or SaaS version: https://www.kimai.org
At a glance
- What is it?
- Kimai is a multi-user PHP time-tracking application that covers timesheets, invoicing and reporting, and ships as an on-premise install or a hosted cloud service. The deciding factor is not the feature list but the hosting model, the AGPL licence and the plugin ecosystem around it.
- Who is it for?
- Adopt Kimai if you need a self-hosted, multi-user timesheet system with invoicing and reporting, you can run PHP 8.2 or newer against MariaDB 10.6 or MySQL 8.4 or newer, and you are comfortable with AGPL-3.0 obligations. Do not adopt it if you want a subdirectory install, a library you embed inside an existing application, or a tool that works without a webserver and database.
- 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 PHP, 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 Kimai solves: timesheets that have to become invoices
Most time trackers stop at the timer. Kimai's README describes the scope differently: it manages timesheets, generates reports and creates invoices, and it is built for freelancers as well as for companies with dozens or hundreds of users. That combination is the point. A freelancer who bills hourly needs three things joined up: recorded time, a rate, and a document the client accepts. Kimai puts user, customer and project specific rates into the same system that holds the entries, so the invoice is a rendering of data that already exists rather than a separate spreadsheet exercise.
The multi-user framing matters too. Team permissions and role configuration are listed as features, which means the intended unit of adoption is an organisation, not one person with a stopwatch. If you only need to know how long a task took, Kimai is heavier than the problem. If you need to answer what a client owes at the end of the month, and who on the team worked on it, the scope fits.
What the Symfony and Doctrine stack implies for operators
The credits section names the foundations: PHP, Symfony, Doctrine, Bootstrap and Tabler, with the remaining dependencies listed in composer.json and package.json. For an operator this is not trivia. A Symfony application means a console, a cache directory, environment configuration and migrations rather than a single script you drop into a web root. Doctrine means schema changes arrive through migrations, which is why the project ships a separate UPGRADING.md next to the general update documentation. The two files serve different purposes: one tells you how to get the latest version, the other carries the version-specific steps.
Tabler and Bootstrap explain the responsive design claim in the README. The topics list on the repository includes doctrine, symfony, twig and tabler, which is consistent with the credits. Nothing here suggests a microservice or a separate frontend build; this is a server-rendered PHP application, and the JSON API is an addition to it rather than the primary interface.
Requirements you have to meet before the first request
The stated floor is PHP 8.2, with support for 8.3, 8.4 and 8.5. The database must be MariaDB 10.6 or newer, or MySQL 8.4 or newer, described as the oldest maintained LTS release. Required PHP extensions are listed explicitly: gd, intl, json, mbstring, pdo, tokenizer, xml, xsl and zip. Missing any one of these is a hard stop, and the list is worth reading before you provision a host rather than after.
The constraint that catches people is the next line: a webserver and a subdomain, with subdirectory explicitly not supported. Kimai expects to own a hostname. If your organisation hands out application paths like /tools/kimai on a shared domain, that deployment shape is outside what the documentation supports. Plan for a dedicated subdomain or a dedicated host.
Installation routes: Docker, Git with Composer, and the hosting guides
The README lists several documented paths. There are Docker images on Docker Hub under kimai/kimai2, published both as FPM only and including Apache. There is an SSH setup route using Git and Composer. There are step-by-step guides for Caddy with Docker Compose on Hetzner and DigitalOcean, and a Synology guide for users who want to host the Docker version. Developer setups are documented separately for people building integrations.
What the material does not give is a copy-paste command sequence for the Git and Composer path. The README points at the installation documentation page rather than inlining the commands, so treat the repository README as a map and the documentation site as the instructions. The same applies to configuration keys: the requirements and extension list are quoted here, but environment variable names and application config keys are not present in the supplied material, so I cannot state them without guessing. If you are evaluating Kimai for a specific host, open the installation page for that host type first, because the Docker, Synology and bare-metal routes differ in what they ask of you.
Authentication, translations and the parts that decide enterprise fit
The README lists authentication via SAML, LDAP or database, two-factor authentication with TOTP, and customizable role and team permissions. For an organisation with an existing identity provider, the SAML and LDAP options are the difference between a tool people log into separately and one that fits the directory you already run. Database authentication remains available for smaller installs that do not want that integration.
Multi-language support is claimed at over 30 translations, hosted on Weblate, and the README actively asks for translation contributors. Multi-timezone support is listed alongside it. Both are the kind of feature that looks like a checkbox until you have staff in two countries filing timesheets against the same project, at which point timezone handling stops being cosmetic. The honest caveat is that translation quality varies by language, and the project's own call for contributors suggests some locales are thinner than others.
The plugin marketplace is where the cost model actually lives
Kimai links to a plugin store described as a marketplace for paid and free plugins, with separate developer documentation for writing your own. This is the most consequential detail for anyone budgeting. The core application is AGPL-3.0, but the features you need beyond the core may sit behind a paid plugin, and that cost is not visible from the repository alone. Before you compare Kimai against a commercial SaaS on price, walk the store and check which of your required capabilities are core and which are add-ons.
The plugin architecture also has a maintenance consequence. Each plugin is code that runs against a moving core. The project states that releases are created every couple of weeks, and that every change, feature or bugfix, lands on the main branch. A fast release cadence with third-party plugins means upgrade testing is not optional, and a plugin that lags behind the core is a reason to delay an upgrade rather than to skip it.
Where Kimai is the wrong tool
Three cases stand out. First, subdirectory hosting is not supported, so anyone constrained to a path under an existing domain should stop here. Second, Kimai is an application, not a library. If you want to record durations inside your own product, embedding a Symfony application with its own database and webserver is the wrong shape; a time-tracking library or a small schema of your own is the smaller answer. Third, the stack is opinionated: PHP 8.2 or newer plus MariaDB or MySQL. A team standardised on PostgreSQL or on a non-PHP runtime cannot adopt Kimai without adding an entire service to their operational surface, which is a real cost even when the software itself is free.
There is also a version ceiling worth noting. The README states support for PHP up to 8.5, which means a future PHP major will require either a Kimai upgrade or a pinned runtime. That is normal for an actively developed PHP application, but it does mean the PHP version is a moving dependency, not a fixed platform.
How this differs from a general-purpose project tracker
The obvious alternative for many teams is a general project management tool with a time-tracking field bolted on, or a self-hosted tracker whose primary object is the task rather than the timesheet. The difference in approach is what sits at the centre of the data model. In a task-centric tool, time is an attribute of a ticket, and reporting is a by-product. In Kimai, the timesheet entry is the record, with customers, projects, activities and rates attached to it, and invoicing is a first-class output. That is why the feature list leads with invoicing and data exports rather than with boards or sprints.
If your billing process already lives in an accounting system and you only need hours per ticket, a task-centric tool will feel lighter. If the hours themselves are the billable artefact, and you want exports and invoices produced from the same store, Kimai's model is the closer fit. The JSON API is the bridge in either direction, and the README lists it first among the features.
Licence and the upgrade treadmill
Kimai is AGPL-3.0. That is a strong copyleft licence with a network clause: if you modify the application and let users interact with it over a network, the licence's source-availability obligation is the thing to understand before you fork or patch the core inside a commercial service. I am not giving legal advice here; if you plan to modify and redistribute or host a modified version for third parties, have someone qualified read the licence text rather than this paragraph.
The maintenance picture from the material is a steady cadence: releases every couple of weeks, version 2.66.0 in early September 2026, 2.65.0 and 2.64.0 in August, and all changes landing on main. That is good for fixes and bad for anyone who wants a frozen target. Budget for reading UPGRADING.md at each version jump, for testing paid and free plugins against the new core, and for the PHP and database floors moving as upstream support windows close. The project offers no LTS branch in the material provided, so the honest planning assumption is continuous minor upgrades rather than periodic major ones.
Editorial conclusion
Adopt Kimai if you need a self-hosted, multi-user timesheet system with invoicing and reporting, you can run PHP 8.2 or newer against MariaDB 10.6 or MySQL 8.4 or newer, and you are comfortable with AGPL-3.0 obligations. Do not adopt it if you want a subdirectory install, a library you embed inside an existing application, or a tool that works without a webserver and database. Before committing, verify your PHP extensions against the required list (gd, intl, json, mbstring, pdo, tokenizer, xml, xsl, zip), confirm your database version, and read UPGRADING.md for the version-specific steps that apply to your current release.
Community notes