Single-Binary Self-Hosted Analytics
HitKeep is a self-hosted analytics path for teams that want one process, one data directory, and no required PostgreSQL, ClickHouse, Redis, Kafka, separate queue, or hosted analytics service to secure, monitor, patch, and back up.
Best fit
Section titled “Best fit”Choose this path when you want:
- one Linux binary for the application, queue, and database path
- embedded DuckDB for analytics storage
- embedded NSQ for internal queueing
- no required PostgreSQL, ClickHouse, Redis, Kafka, or hosted analytics service
- low idle resource usage on a small VPS or internal VM
- direct control over backups, retention, and network policy
- optional Search Console import, AI visibility, AI chatbot analytics, and MCP access without adding another analytics service
How the runtime works
Section titled “How the runtime works”Visitor page -> hk.js -> HitKeep HTTP server -> embedded NSQ -> DuckDBThe control plane stores users, sessions, teams, sites, and settings. Tenant analytics data lives in the main data directory, and non-default teams use tenant-local DuckDB files under tenants/*/hitkeep.db.
Search Console facts, AI fetch records, chatbot events, ecommerce events, goals, funnels, and normal pageviews all use that same tenant-aware storage model. MCP, when enabled, is a read-only route on the same binary rather than a separate service.
Start commands
Section titled “Start commands”Use the binary guide for the full setup, but the deployment shape stays small:
./hitkeep \ -public-url "https://analytics.example.com" \ -jwt-secret "replace-with-a-long-secret"Then add the tracker:
<script async src="https://analytics.example.com/hk.js"></script>When cloud is the better first step
Section titled “When cloud is the better first step”Use HitKeep Cloud first when the main goal is evaluating reporting coverage quickly. You can still use self-hosted HitKeep later when infrastructure ownership becomes the deciding factor.