Jitsu

Last reviewed Sep 13, 2026 · 799 words

The compose file for Jitsu starts around 11 containers: Kafka and its coordinator, PostgreSQL, Redis, ClickHouse, MongoDB, and then the Jitsu services themselves (console, ingest, rotor, bulker, syncctl). That single fact sorts readers into two groups. If you have a data warehouse and a marketing or product team that is paying Segment four figures a month to fill it, Jitsu is the credible self-hosted replacement and the operational weight is a rounding error against the bill. If you are a solo developer who wants to know how many people visited your site, this is 10 containers too many, and Plausible or Umami will make you happier by lunchtime.

Jitsu is a pipe, not a dashboard

The mental model that prevents disappointment: Jitsu captures events (page views, track() calls, server-side HTTP posts) and delivers them, in near real time, to somewhere else. That somewhere is a warehouse such as ClickHouse, BigQuery, Snowflake, Postgres or Redshift, or a downstream tool via a "function" (a JavaScript transform you write in the console). Jitsu itself does not draw funnels or retention curves; you query the warehouse with your own BI tool. People who arrive expecting a Mixpanel-style UI leave confused. People who already live in SQL find that the schema Jitsu writes is flat, sensible and stable.

If you want events and the analytics UI in one install, PostHog is the bigger sibling in this category and ships both. It is heavier still, but it answers questions out of the box.

Real-time delivery is the feature, and Kafka is the price

Events land in the warehouse within seconds rather than the hourly batches some pipelines use, and that is why Kafka sits in the middle: it buffers spikes and lets the bulker retry a destination that is down without dropping data. On a quiet site this feels like overkill. During a product launch when traffic goes 20x for an hour and your warehouse throttles inserts, it is exactly the thing that saves the day's data.

The RAM figure in our catalogue, 1 GB, is the floor for Jitsu's own services. With Kafka, ClickHouse and Mongo alongside, I would not run the reference compose on less than 4 GB, and 8 GB if you value not thinking about it. This is a small server's worth of work, not a container bolted onto your homelab.

The JavaScript SDK and the ad-blocker question

The browser side is a small script (@jitsu/js on npm, or a tag from your ingest host) with identify, track, page and group calls that mirror Segment's API closely enough that migrating a Segment-instrumented site is mostly a search-and-replace on the import. Because you host the ingest endpoint yourself on your own domain, generic tracker blocklists miss it more often than they miss segment.com, which is the same first-party advantage that self-hosted analytics tools enjoy. Do not treat that as a licence to skip consent; treat it as data you would otherwise lose to a network hiccup.

Server-side events (from your backend, a payment webhook, a CRM) go to the same ingest endpoint over HTTP with a write key, which is the part that makes the warehouse a single source of truth rather than a browser-only view.

Where the operational complexity actually bites

Three places, from my experience. First, the console expects a public URL and TLS from the start; running it on localhost:3000 for a test is fine, but moving it later means re-issuing write keys and updating every SDK snippet. Decide the hostname first. Second, warehouse credentials are held in the console database (Postgres), so that database is now sensitive and needs the same backup and secrets discipline as your password manager. Third, upgrades touch a lot of moving parts at once; read the release notes and upgrade the whole compose set together rather than bumping one image.

Kubernetes is the other supported path and honestly the more natural one for a tool with this many components, if you already run a cluster.

What I'd do

If a team is already paying for Segment or RudderStack Cloud and owns a warehouse, I would stand Jitsu up on a dedicated 4-vCPU, 8 GB VM under a fixed hostname, point it at ClickHouse, port the tracking snippets, and run both pipelines in parallel for 2 weeks before cancelling the subscription. If there is no warehouse and no one to query it, I would not install Jitsu at all: PostHog if you want product analytics with events, Plausible or Umami if you want to know what pages people read. Jitsu is excellent at its job, and its job is narrower than its tagline suggests.