solidtime: an AGPL time tracker built on Laravel and Vue for freelancers and agencies
Modern open-source time-tracking app
At a glance
- What is it?
- solidtime is a self-hostable time-tracking application written in PHP on Laravel with a Vue front end, aimed at freelancers and agencies. The interesting part is not the timer but the billing model: rates can be attached at four different levels, and the licence plus the contribution rules shape who can realistically run and modify it.
- Who is it for?
- Adopt solidtime if you are a freelancer or a small agency that wants time entries, clients, projects and billable rates in one self-hosted Laravel application and can live with AGPL-3.0. Do not adopt it if you need a hosted SaaS with a support contract, if you cannot operate a PHP stack with a database and queue worker, or if you intend to fork it into a closed product.
- 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 last received commits 2 days ago.
- 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
What solidtime tracks that a stopwatch does not
The README describes solidtime as a time tracking application for freelancers and agencies. That audience matters, because the feature list is organised around billable work rather than around personal productivity. Alongside tracking time, the application manages projects, tasks and clients, and projects can have members assigned to them. The README also lists multiple organizations under one account, and roles and permissions for managing those organizations. For an agency, the organization boundary is the unit that separates one client portfolio from another without creating a second login. For a freelancer, the same model still works with a single organization. If you only need a personal timer that produces a weekly total, most of this structure is overhead you will configure and then ignore.
The billable rate hierarchy is the real design decision
The README states that billable rates can be set for projects, project members, organization members and organizations. Four levels, one number per time entry. That is the part of solidtime worth understanding before you deploy it, because it determines what an invoice looks like. A senior contractor and a junior contractor on the same project can carry different rates without duplicating the project. A default rate at the organization level can cover everything that has not been given a more specific one. The README does not describe the precedence order between these levels, and it does not state what happens when a project member has a rate and the project also has one. That is the first thing to establish from the self-hosting documentation or from a test instance, because the resolution rule is what your exported numbers depend on. Nothing in the supplied material describes an API, a webhook or a native invoicing module, so treat solidtime as the system that records billable time, not the system that issues the invoice.
Laravel, Vue and the shape of a self-hosted deployment
The repository is primarily PHP and the topics list laravel and vue, so the architecture is a Laravel application serving a Vue front end. The README links a separate self-hosting guide at docs.solidtime.io and a companion repository, solidtime-io/self-hosting-examples. Those two links are where the deployment detail lives. The README itself gives no database engine, no queue configuration, no container image name and no environment variable names, so anyone who needs the concrete stack should read the guides rather than infer it from the repository description. The self-hosting-examples repository is the more useful of the two for evaluation, because an example deployment is easier to audit than prose. What the README does establish is that self-hosting is a first-class path rather than an afterthought: there is a hosted cloud offering at solidtime.io, and the self-hosted route is documented separately for people who do not want it.
Getting it running and moving data in
The README does not include installation commands, so the honest starting point is the self-hosting guide linked from it, plus the examples repository. What the README does specify is the import path. Supported sources are Toggl, Clockify and Timeentry CSV. That list is the migration plan for most teams: if your current tracker is one of the first two, the move is a supported operation, and if it is anything else, the CSV route is the fallback. The CSV importer is also the one to scrutinise before you commit, because a generic CSV format rarely carries every field a billing workflow depends on. Check that your export includes client, project, task and rate information in a shape the importer accepts. On the contribution side, the README is explicit about process: open an issue or a discussion and wait for approval before submitting a pull request, with an exception for tiny fixes. Pull requests from authors who are not vouched are closed automatically unless they change 50 lines or fewer, and vouching happens after you explain your intended approach in an issue or discussion. For an operator who just wants to run the software, that policy is irrelevant. For anyone planning to maintain a fork, it is the first constraint to read.
AGPL-3.0 and the cost of running your own instance
solidtime is licensed under the GNU Affero General Public License v3.0, and the README points to the license file for the terms. AGPL-3.0 is a copyleft licence with a network clause: if you modify the software and let users interact with it over a network, the licence's source-availability condition applies to that modified version. For an agency running solidtime internally to track its own hours, this is mostly a non-issue. For a company that wants to build a hosted time-tracking product on top of solidtime, it is the central question, and it is a question for your own legal counsel rather than for a review. The maintenance cost is the other side. Self-hosting means you own the database, the backups and the upgrade path. The release history shows a steady cadence: v0.19.0 and v0.19.1 in August 2026, then v0.20.0 at the end of that month. Version numbers below 1.0 usually mean breaking changes are still possible between minor releases, so pin a version, read the release notes before moving, and take a database backup as part of the upgrade. The README does not describe a migration or rollback procedure.
Where solidtime is the wrong choice
Three cases stand out. The first is a team that wants a vendor to be accountable for uptime: the cloud offering exists, but the open-source repository is the self-hosted product, and nothing in the supplied material describes an SLA or commercial support for the self-hosted edition. The second is a team without anyone comfortable operating a PHP application with a database and, in most Laravel deployments, a queue worker and scheduled jobs. The self-hosting examples reduce that burden but do not remove it. The third is a team whose billing depends on features the README does not mention. There is no reference here to expense tracking, invoicing, budgeting against estimates, or a public API for pulling time entries into another system. If your workflow needs any of those, verify them in the documentation before you migrate, because the feature list in the README is specific and stops at tracking, projects, tasks, clients, rates, organizations, roles and imports.
How it compares with Kimai
Kimai is the obvious comparison: another self-hosted, open-source time tracker written in PHP, aimed at agencies and freelancers. The difference visible in this material is the shape of the rate model. solidtime places billable rates at four levels, including organization members and organizations, which suggests rate resolution is meant to happen automatically from the organizational structure rather than being entered per activity. Kimai's approach centres on activities and projects, and its plugin ecosystem extends the core rather than the core absorbing every requirement. That is a real trade-off rather than a ranking. A plugin architecture lets you add only what you need and keep the core small; a built-in hierarchy means fewer moving parts but less room to adapt when your rate rules do not fit the four levels. If your rate logic is unusual, test solidtime's hierarchy against a real project before migrating, and check whether Kimai's activity model maps more directly to how you already bill.
Editorial conclusion
Adopt solidtime if you are a freelancer or a small agency that wants time entries, clients, projects and billable rates in one self-hosted Laravel application and can live with AGPL-3.0. Do not adopt it if you need a hosted SaaS with a support contract, if you cannot operate a PHP stack with a database and queue worker, or if you intend to fork it into a closed product. Before committing, verify three things in the self-hosting documentation: the supported database and PHP versions, the backup and upgrade procedure for the version you deploy, and whether the importers for Toggl, Clockify or Timeentry CSV cover the fields you actually bill on. The billable rate hierarchy is the feature to test first, because it is the one that decides whether the exported numbers match your contracts.
Community notes