Wakapi

Coding statistics, honestly reviewed. Self-hosted, MIT-licensed, and built for the developer who got tired of two-week history windows.

TL;DR

• What it is: A minimalist, self-hosted backend for coding statistics — drop-in compatible with WakaTime’s editor plugins, but the data lives on your server [README].
• Who it’s for: Developers who want long-term coding statistics without paying WakaTime’s monthly subscription, privacy-conscious engineers who don’t want to hand their coding habits to a third party, and anyone who has ever wanted to know exactly how many hours they spent on a project [1][website].
• Cost savings: WakaTime’s free plan caps your history at two weeks. Their paid tier runs roughly $9–10/month to unlock full history. Wakapi self-hosted runs on a $5–10/month VPS with unlimited history, forever [website][1].
• Key strength: Full WakaTime plugin compatibility means zero client-side changes — install, point your existing WakaTime plugin at your own server, done [README].
• Key weakness: Small project — 4,224 GitHub stars, one primary maintainer, thin third-party review coverage. If the maintainer stops, you own the operational risk [README].

---

What is Wakapi

Wakapi is a self-hosted server that speaks WakaTime’s API protocol. The pitch from the GitHub README is unusually blunt: “A minimalist, self-hosted WakaTime-compatible backend for coding statistics.” [README] No marketing stretch. That’s exactly what it is.

The way it works: WakaTime’s editor plugins — available for VS Code, JetBrains, Vim, Emacs, and most other editors — are open source. They send heartbeats (project name, language, file, editor, OS) to a backend API endpoint. Normally that endpoint is WakaTime’s servers. Wakapi reimplements that endpoint. You point the plugin at your own instance with a one-line config change, and everything else works identically [README][1].

The project is written in Go by Ferdinand Mütsch (GitHub: muety), MIT-licensed, and has been running at wakapi.dev as a hosted demo/service. As of this review, the public instance has tracked 567,479 hours of coding from 4,301 registered users, with 133 currently active [website]. Those are not enterprise numbers — this is a developer-centric project used by developers, not a VC-funded SaaS pretending to be open source.

One developer’s account sums up the common path to Wakapi: “I have been using Wakatime since 2017, but I stopped using it in recent years because the free plan, which only provides a two-week range report, is not very helpful. I primarily relied on it for the yearly report to see how much I coded over the past year, just for fun. I realized that I was freely providing my valuable coding statistics to them; as a free service, I became the product.” [1] That’s the Wakapi user in one paragraph.

---

Why people choose it

The reviews for Wakapi are sparse — it’s a niche tool with a small but committed user base, not a product that gets comparison-guide traffic. The primary account [1] and the project’s own data tell the story.

The WakaTime pricing trap. WakaTime’s free tier limits history to two weeks. For someone who wants to see their annual or multi-year coding trends — language drift, project time allocation, habits over time — the free tier is nearly useless. The paid tier unlocks full history, which means you’re paying a recurring subscription for data you generated. Wakapi breaks that model entirely [1][website].

The “you are the product” problem. At $0/month, WakaTime’s incentive structure means your coding behavior — projects you work on, languages, hours — is the asset. For developers at companies with IP-sensitive work, or anyone who thinks about where their behavioral data ends up, this is a real concern. Wakapi stores all of that on your own infrastructure [1].

Plugin compatibility is the real moat. Competing time-tracking tools (ActivityWatch with its WakaTime extension, Hakatime, Codetime) all require some degree of client-side behavior change. Wakapi requires zero. The WakaTime plugin already knows how to talk to a WakaTime-compatible API — you just change one config value. For a developer who’s had WakaTime set up for years across multiple machines, that matters [README].

The data ownership angle. The nguyengineer.dev author’s framing is worth repeating: “since the Wakatime plugin is open-source, we can modify it to send data anywhere we want, and that’s perfectly legal.” [1] Most WakaTime users don’t think about this. Wakapi exists partly to make people aware that they can.

---

Features

Based on the README and website:

Core statistics:

• Time tracking per project, language, editor, host, and operating system [README][website]
• Fancy statistics and plots — visual dashboards showing breakdowns over configurable date ranges [website]
• Public leaderboard (opt-in) on the hosted instance [website]
• Badges you can embed in GitHub READMEs, showing your coding time for a project [README][website]

Reporting and integrations:

• Weekly email reports on your coding activity [README][website]
• REST API for building your own tooling on top of your data [README][website]
• Prometheus metrics export — you can feed coding stats into your Grafana dashboards [README][website]
• Partial WakaTime API compatibility — the project explicitly calls this “partially compatible,” not a full drop-in [README]
• WakaTime integration — can sync or import from an existing WakaTime account [README]

Infrastructure:

• SQLite by default (zero external dependencies for personal use) [README]
• MySQL and PostgreSQL supported for production setups [README]
• Docker, Docker Compose, Helm/Kubernetes deployment options [README]
• SystemD service support for bare-metal installs [README]
• SSO listed as a supported feature [merged profile]
• Docker Secrets support for sensitive environment variables [README]
• GDPR-compliant by design — all data stays local [website]

What it doesn’t do:

• No offline mode — it needs a running server to receive heartbeats
• No mobile tracking (you’re tracking editor time, not phone time)
• No project management, invoicing, or billing integration
• “Partially compatible” with WakaTime means some WakaTime features won’t map cleanly

---

Pricing: SaaS vs self-hosted math

Wakapi Cloud (wakapi.dev hosted service):

• Free tier: basic account, full feature set, but data retention limited to 12 months [website]
• Subscription: 5€/month for unlimited data retention beyond 12 months [website]

Wakapi self-hosted (Community Edition):

• Software license: $0 (MIT) [README]
• VPS to run it on: $5–10/month (Hetzner, Contabo, DigitalOcean)
• SQLite for personal use: no additional infrastructure cost
• PostgreSQL or MySQL if you want production-grade storage: can share an existing DB instance

WakaTime for comparison:

• Free: 2-week history limit — functionally useless for trend analysis [1]
• Pro: approximately $9–10/month for unlimited history (exact pricing varies; check WakaTime’s site directly — data not pulled at review time)
• Teams and org plans: higher

Concrete savings math:

A solo developer using WakaTime Pro at ~$10/month spends $120/year to store their own coding statistics. Wakapi self-hosted on a $6 Hetzner VPS is $72/year — and that VPS likely runs other things too (a personal site, a side project), so the marginal cost of Wakapi specifically is close to zero. If you’re already running a home server or VPS, Wakapi is a Docker container.

Over three years: WakaTime Pro ≈ $360. Wakapi self-hosted ≈ marginal. The math isn’t dramatic like the Zapier-vs-Activepieces comparison, but the compounding point is different: your data accumulates over years, and with WakaTime, you’re renting access to your own history.

Alternatively, Wakapi’s own hosted service at 5€/month is cheaper than WakaTime Pro and still gives you a SaaS experience. The hosted option makes sense if you want the data retention without operating infrastructure.

---

Deployment reality check

Wakapi’s deployment story is one of its strongest points. The README offers four installation paths: a one-liner curl install, Docker, Docker Compose, and compiling from source [README]. For a developer audience, none of these is unusual.

Docker (simplest path):

docker volume create wakapi-data
docker run -d -p 3000:3000 \
  -e "WAKAPI_PASSWORD_SALT=$SALT" \
  -v wakapi-data:/data \
  ghcr.io/muety/wakapi:latest

That’s the complete install for a personal instance with SQLite. No external database, no additional services [README].

Docker Compose is the recommended path for anything beyond personal use — it handles environment variables cleanly and supports Docker Secrets for passwords [README].

Kubernetes: There’s a community Helm chart (wakapi-helm-chart by ricristian) for anyone running k8s infrastructure [README].

Client setup is where new users sometimes pause: you need to install WakaTime’s editor plugin (if you haven’t already), then change one line in your WakaTime config to point at your Wakapi instance URL with your API key. The README’s client setup section walks through this. One early user noted some performance issues when the project was younger [1] — the Go rewrite and active maintenance have addressed most of these over time.

What can go sideways:

• If you’re migrating an existing WakaTime history, the import process requires some patience — bulk historical data transfer is possible but not one-click.
• SQLite is fine for a single developer. If you want multi-user (a team sharing an instance), PostgreSQL is the more robust choice.
• The “partially compatible” WakaTime note in the README is real — some WakaTime client features or third-party integrations that depend on WakaTime-specific API behavior may not work [README]. Test your specific editor plugin setup before committing.
• This is a one-maintainer project. Ferdinand Mütsch is responsive and the contributor from [1] described collaboration as pleasant, but bus factor is 1.

Realistic setup time for a technical user: 15–30 minutes to a running personal instance. Client setup across multiple editors: another 15 minutes.

---

Pros and cons

Pros

• Zero client-side migration cost. If you already use WakaTime, pointing it at Wakapi requires one config line change. No new habits, no new plugins [README].
• MIT license. Run it, modify it, embed it — no restrictions [README].
• Genuinely self-hosted. Your coding data doesn’t leave your network. No WakaTime account required once migrated [1][README].
• Unlimited history. No two-week cap, no subscription to access your own statistics [1][website].
• Multiple deployment paths. Docker one-liner to Helm chart — the complexity scales with your infrastructure [README].
• Prometheus export. Coding stats in Grafana is a legitimate use case for developers who already operate observability stacks [README][website].
• GDPR-compliant by default. All data stays local — useful for EU-based developers or those handling IP-sensitive project work [website].
• Active maintenance. The project has ongoing pull requests and the maintainer is described as responsive and collaborative [1].

Cons

• “Partially compatible” with WakaTime. The README is honest about this — not every WakaTime feature or integration maps 1:1. If you depend on specific WakaTime API behaviors, test first [README].
• Small project. 4,224 stars and one primary maintainer. If Ferdinand stops maintaining it, you’re on your own. This is self-hosted infrastructure, not a vendor relationship [README].
• Thin third-party review coverage. Finding independent reviews beyond personal blog posts is difficult. The lack of coverage isn’t a red flag on the software, but it means less aggregated feedback on edge cases and failure modes.
• No mobile tracking. WakaTime’s scope is also limited here, but worth noting — if you want time tracking across your whole workflow (not just editor time), you’ll need additional tools.
• Import from WakaTime is not turnkey. Historical data migration is possible but requires effort. Not a deal-breaker, but don’t expect a “migrate from WakaTime” button.
• Multi-user is underserved. The primary use case is personal or small-team. Enterprise features (fine-grained RBAC, audit logs, team management) aren’t the focus [README].

---

Who should use this / who shouldn’t

Use Wakapi if:

• You’re currently paying WakaTime Pro and the primary value is history longer than two weeks.
• You already have a VPS running other services and want to add coding statistics without adding a recurring subscription.
• You care about keeping your coding behavior data out of a third party’s servers — especially if your work involves IP-sensitive projects.
• You’re comfortable with Docker and a one-time 30-minute setup investment.
• You want Prometheus-compatible metrics to push coding stats into an existing Grafana stack.

Skip it (use wakapi.dev hosted instead) if:

• You want the self-hosted data ownership benefits without operating your own server. The hosted option at 5€/month is cheaper than WakaTime Pro and keeps data under the same codebase [website].

Skip it (stay on WakaTime) if:

• You rely on WakaTime integrations that depend on the full WakaTime API — project syncing, team dashboards, or third-party tools built on WakaTime’s API.
• Your company already pays for WakaTime for Teams and you benefit from the shared team view.
• You don’t have the 30 minutes to set it up and don’t want to.

Skip it (consider ActivityWatch) if:

• You want time tracking beyond just editor time — browser activity, application usage, meeting time. ActivityWatch covers the full desktop; Wakapi covers only editor heartbeats.

---

Alternatives worth considering

• WakaTime — the incumbent. Easiest setup (no self-hosting), largest plugin ecosystem, most third-party integrations. Free tier crippled to 2 weeks; Pro subscription required for full history. Closed source.
• ActivityWatch — open-source, self-hosted, tracks time across your entire computer (browser, apps, AFK), not just your editor. Has a WakaTime-compatible extension. More complex, much broader scope.
• Hakatime — another self-hosted WakaTime-compatible backend (Haskell). Fewer stars, less active. Wakapi is the more mature option in this specific category.
• Codetime (Software.com) — VS Code extension with its own backend. Simpler but less portable and not self-hosted.
• toggl / Clockify — manual or semi-automated time tracking for billing purposes. Different audience — these are for tracking client project time, not passive coding habit analysis.

For a developer who wants exactly what WakaTime does but self-hosted and without the subscription, the realistic shortlist is Wakapi vs ActivityWatch. Pick Wakapi if you want a direct WakaTime replacement with zero client changes. Pick ActivityWatch if you want whole-desktop tracking and don’t mind a more complex setup.

---

Bottom line

Wakapi solves a specific and real problem: WakaTime’s free tier is almost useless, the paid tier charges you recurring money for access to data you generated, and most developers accept this because switching feels hard. Wakapi makes switching easy — it’s a WakaTime API endpoint you run yourself, and your existing plugins work without changes.

The trade-offs are equally specific. This is a one-maintainer Go project with 4,224 stars and limited third-party review coverage. It’s not an enterprise product, not trying to be, and the README doesn’t pretend otherwise. For a solo developer or small team who wants their coding statistics without a recurring bill and without handing their project list to a third party, the setup investment is 30 minutes and the ongoing cost is marginal.

If the setup is the blocker, Wakapi’s own hosted service at 5€/month is still cheaper than WakaTime Pro and runs the same codebase — a reasonable middle ground if you want the data portability without the ops overhead.

---

Sources

1. Nguyen Engineer — “Wakapi: my first contribution to the open source”. https://nguyengineer.dev/wakapi-my-first-contribution-to-the-open-source

Primary sources:

• GitHub repository and README: https://github.com/muety/wakapi (4,224 stars, MIT license)
• Official website and hosted service: https://wakapi.dev