1. Pilae
2. Apps
3. Kimai

Running Kimai in production: what it takes

1. Deploy with the data directories on volumes

   A Kimai image we have run, on its own MariaDB, with the application secret set by us rather than generated inside the container, and the three data directories on volumes from the first day.

2. SAML sign-on, roles from groups

   SAML sign-on through Keycloak or your existing IdP. Directory groups map to Kimai's team lead and admin roles and are applied again at every sign-in, so a role removed in the directory does not linger in Kimai.

3. Set rates, teams and a lockdown period

   Rates by customer, project and person, teams deciding who sees which projects, and a lockdown period so hours cannot be changed after the month has been invoiced.

4. Restore onto the same Kimai version

   A daily, encrypted copy of the database and the data directories goes offsite. The monthly drill puts it back into a scratch instance on the same Kimai version and opens an invoice from it.

5. Upgrade in your window, plugins included

   The container migrates the database when it starts, so the way back is the copy taken just before. We check each plugin against the release and the upstream upgrade notes, then the Pilae Agent rehearses the upgrade on a copy and, once you approve, applies it in your window.

What Kimai is, and who runs it

Kimai system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory

2 vCPU · 4 GBUpstream publishes no minimum. This is our starting size for Kimai and MariaDB on one machine, and we resize it from what monitoring shows during long reports and large exports.

Database

MariaDB 10.6+ or MySQL 8.4+Kimai supports MariaDB and MySQL only. PostgreSQL is not supported and not planned upstream, so Kimai gets its own database with its own backup and restore drill.

Sign-in

SAML 2.0 or LDAPBoth are in the open-source core. SAML covers Keycloak and Microsoft Entra ID. There is no OpenID Connect sign-in; it is an open feature request upstream. The official image already includes the LDAP library that a manual install has to add.

Persistent storage

var/data · var/invoices · var/pluginsGenerated invoices, uploaded invoice templates and plugin code. All three are volumes backed up with the database, because a template kept only inside the container is lost when the container is removed.

DNS and TLS

1 hostnameKimai has to run at the root of its own hostname; a subdirectory is not supported. Behind the Pilae gate on port 443 if people record time from outside the network.

Migrating from Toggl Track to Kimai

Toggl Track's CSV export of time entries imports into Kimai through the free Importer plugin. Clients become customers, projects stay projects, tasks become activities, and each entry keeps its description, tags, billable flag and amount. People are matched by email and created if they do not exist yet, so the default time zone for new users is set before the first file goes in. The currency is not imported, so it is set on each customer first. Toggl has to export with a date format the importer can parse. The Toggl format carries time entries only, so project budgets, estimates, saved reports and integrations do not come across. Most of the work is in the mapping and the rates, which we check until Kimai's totals match Toggl's for the same months.

1. Set up the structure first

   Currency on each customer, the default time zone for new users, and rates by customer, project or person, agreed before any history is imported.

2. Import into a scratch copy

   The Toggl Track CSV export goes through the Importer plugin into a scratch instance first. Totals per project and month are compared with Toggl reports before anything reaches production.

3. Wire sign-on to the imported accounts

   Kimai matches the SAML NameID against a username or an email address, so your identity provider sends the email people used in Toggl and they sign in to the account that holds their history.

4. Cut over at a month end

   History comes across up to the last closed month, and the open month follows as a final import on the night of the switch. Toggl stays readable until the first invoicing run closes on Kimai.

What a Kimai restore needs

What Pilae is responsible for

Where it runs

zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware

Who holds the credentials

You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.

If you leave

The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running Kimai

Pricing is on request: a fixed price for onboarding, then a monthly price for Kimai, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size

The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.

High availability

One machine with tested restores, or a replicated setup that keeps serving when a node fails.

Storage and backups

How much data it holds, how long backups are kept, and point-in-time recovery for its database.

Plan and support

Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.

Region

Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.

Sign-on and integrations

Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Kimai: common questions

Also in business