Self-Hosted or Cloud Time Tracking: What Seven Years Taught Us
We self-hosted our own build server for seven and a half years, and we were right to. Then we were wrong to, and it took a colleague going on leave to notice.
Most articles comparing self-hosted and cloud software are written by someone selling one of them. This one is too: Sandtime.io is hosted, and we would like you to use it. So rather than argue from principle, here is what happened when we ran our own infrastructure, what it actually cost, and the cases where self-hosting a time tracker is still the right answer.
Self-hosting is a staffing decision, not a technical one. The setup is the easy part. The question is who owns it in year three, and whether that person can go on holiday.
- What self-hosting really buys: data residency you control and no dependence on a vendor staying in business.
- What it really costs: not hosting fees. Attention, and a bus factor of one.
- What made us retire ours: the person who knew the system took leave, and nobody else knew where anything lived.
- When self-hosting still wins: a hard data-residency rule, an air-gapped network, or an existing platform team. All three are real.
- The middle option: hosted, but in the jurisdiction you need, with an export you can run at any time.
Sandtime.io runs on OVHcloud infrastructure in the European Union and is free for unlimited users. We sell the hosted option, so the case against us is stated plainly below.
What we ran, and for how long
Our Jenkins server ran from 3 January 2019 until 10 August 2026, when we moved continuous integration to a hosted service. It worked for the entire time. The decision to retire it was never about whether it worked.
We published these figures when we retired it, and you can read the original post. In 2019 that was a good decision, and worth saying clearly: GitHub Actions did not exist, hosted CI was thin, and running your own was how serious teams shipped. A decision that was correct when it was made can stop being correct without anyone doing anything wrong.
The bill was never the problem
The hosting cost was noise. What the server actually consumed was attention: upgrades, plugin breakage, certificates, disk, and the slow accumulation of configuration that lived nowhere except on that machine.
The trigger was mundane. The person who knew the system went on leave, and it turned out nobody else knew the accesses, the VPN, or where the configuration lived. Nothing broke. It just became clear that a single illness or resignation stood between us and a build pipeline we could not repair.
Self-hosting is a bet that you will still have the person. Every self-hosted service has an owner, whether or not anyone has said so out loud. The question worth asking before you deploy is not "can we run this?" but "who runs this when the person who set it up is on holiday, and do they know it yet?"
What running a time tracker yourself involves
If you are weighing a self-hosted time tracker such as Kimai or Solidtime, the install is genuinely straightforward. The list below is what comes after it, and it is the part that decides whether you are still happy in year two.
Reachable from outside
People track time from a phone on the train and a laptop at a client site. That means either exposing the server to the internet and owning what follows, or running a VPN and asking everyone to connect before they log an hour.
Backups you have tested
An untested backup is a belief, not a backup. Timesheets feed payroll and invoices, so the restore path has to work on the worst day of the quarter, not the calmest.
Upgrades nobody wants to do
Security patches arrive on their own schedule. The longer an upgrade is deferred, the larger it becomes, and the more it looks like a project rather than an afternoon.
A second person who knows
The cheapest insurance available, and the one most often skipped. If the runbook only exists in one head, the service has a bus factor of one no matter how good the software is.
When self-hosting is the right answer
There are cases where it plainly is, and a comparison that pretends otherwise is not worth reading.
A binding data-residency rule
Some contracts and public-sector rules name where records may physically sit. If a hosted provider cannot satisfy the clause, the discussion is over and self-hosting is the answer.
An air-gapped network
If the work happens on a network with no route to the internet, hosted software is not an option at any price.
You already run a platform team
If someone is on call for internal services this quarter and next, one more service is a marginal cost rather than a new commitment. That is a genuinely different situation from a team of six with no ops rota.
If none of those describe you, the honest reading is that self-hosting a time tracker is a preference rather than a requirement. That is allowed. It is just worth knowing which one it is before you commit a colleague to maintaining it.
Where hosted data actually lives
The usual objection to hosted software is that you no longer know where your records are or whether you can get them back. Both are answerable, and worth answering specifically rather than with reassurance.
Sandtime.io runs on OVHcloud infrastructure in the European Union, backs up every eight hours, and exports every report to Excel or CSV whenever you ask it to. The trust centre lists the providers and the backup schedule. Your organization stays the controller of its own records. There are no screenshots, no keystroke logging, and no activity monitoring anywhere in the product, on any platform.
That last point matters more than the hosting question for most teams. A tracker nobody trusts produces hours nobody believes, wherever the server happens to be.
How to decide in an afternoon
If you cannot name the owner, you have your answer. If none of the hard requirements apply, the rest is preference, and a migration path you have never run is a plan rather than a path.
Questions people actually ask
Can I self-host Sandtime.io?
Not on the free product, which runs on OVHcloud infrastructure in the European Union. Self-hosting is available as a custom Enterprise deployment, so if a binding rule requires records on your own hardware, contact sales and say what the rule asks for. Read the rest of this either way: running a tracker yourself is a real commitment, and the costs below are the ones that caught us out.
What happens to my data if I leave?
Every report exports to Excel or CSV at any time, including the currency data. Nothing has to be requested from support and there is no waiting period. Run the export once early so you know the shape of what you would get.
Is my time data used to train anything?
No. Your organization remains the controller of its records, and the product takes no screenshots, logs no keystrokes, and monitors no activity on any device.
Does hosted mean I lose control of who sees what?
No. Access is governed by three roles: Administrator, Project Administrator, and User. People see the projects they are assigned to and nothing else, which is usually tighter than a self-hosted instance where everyone shares one login.
Is it really free?
Yes, for unlimited users, with no seat charge and no features held back for a paid tier. See pricing for the detail, and why it is free for the reasoning. Registered nonprofits are eligible for a custom offer.
The short version
Self-hosting a time tracker is a reasonable thing to want and a real commitment to make. We ran our own infrastructure for seven and a half years, it served us well, and we retired it the moment it became clear that its continued operation depended on one person being available.
If you are weighing this against writing your own tracker rather than choosing between hosts, the build versus buy numbers are the closer comparison. If you have the rule that requires it or the team that can carry it, self-host, and this article has hopefully made the second-year costs concrete. If you do not, hosted software in a jurisdiction you are comfortable with and an export you have actually tested will get you further with less of somebody's attention.
About the contributors
Przemysław Zalewski
Sandtime.io engineer and Sanddev team member who reviews product accuracy, technical details, sources, and editorial quality.
LinkedInEmailSanddev profile