# Jitsu: a self-hostable, MIT-licensed event pipeline that replaces Segment

> Jitsu collects events from browsers, apps and servers and delivers them to ClickHouse, BigQuery, Snowflake, Redshift, Postgres or S3 with JavaScript functions running on every event. This review covers the architecture, the install path, and where the design gets in your way.

**jitsucom/jitsu** — Jitsu is an open-source Segment alternative. Fully-scriptable data ingestion engine for modern data teams. Set-up a real-time data pipeline in minutes, not days

- Repository: https://github.com/jitsucom/jitsu
- Website: https://jitsu.com
- Stars: 5,099 · Forks: 404
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/jitsucom-jitsu

## The problem Jitsu solves: event collection that you can host and script

Most teams that outgrow a single analytics SDK end up needing the same three things: one collection endpoint that accepts events from browsers, mobile apps and backend services; a routing layer that fans those events out to a warehouse and to SaaS tools; and a place to transform events in flight before they land. Segment is the default answer, and it is a hosted service with usage-based billing.

Jitsu targets that same problem but makes the pipeline something you run. The README describes it as an "Open-source event data platform. An alternative to Segment." The repository is MIT-licensed, the default branch is newjitsu, and the primary language is TypeScript. The stated audience is modern data teams who want the collection and delivery layer under their own control, or on Jitsu Cloud, which the README describes as the same software, hosted.

The practical difference the README draws is delivery latency and billing shape. It claims Segment loads warehouses once or twice a day, hourly at best, while Jitsu delivers per destination in batches as frequent as a minute, or row-by-row where the destination prefers it. On billing, the README says Jitsu Cloud charges by event volume rather than Monthly Tracked Users, and that self-hosting has no usage billing at all. Treat those as the vendor's framing of its own positioning, not as an independent measurement.

## How the pipeline is put together: collection, functions, destinations

The data flow has four stages, and the repository layout reflects them. Events enter through an SDK, an HTTP API, or a Segment proxy endpoint that accepts Segment-shaped calls so client code does not have to change. The README lists @jitsu/js as isomorphic, working in both the browser and Node.js, and @jitsu/jitsu-react for React and Next.js. There is also an HTML snippet for sites with no build step.

Once an event is accepted, JavaScript functions run on it. The README describes them as running "on every event to filter, transform, and enrich it before delivery." Functions can be authored in the browser or built and deployed from your own repository through the Jitsu CLI, which is where the TypeScript tooling matters: jitsu-cli init scaffolds a project with tests, and jitsu-cli deploy ships it to a workspace. That means your transformation logic can live in normal CI with npm dependencies and your own test suite, rather than in a hosted editor only.

Delivery is the third stage. Destinations include ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3, GCS and a catalog of SaaS tools. The README says events are streamed or micro-batched "depending on what the destination prefers," which is a design choice worth noting: the batching behaviour is a property of the destination connector, not a single global setting you tune once.

The fourth piece is the observability surface. Live Events shows every event, function log and destination write as it happens, and the README frames this as the difference between debugging a pipeline in seconds rather than days. There is also a user identity graph and profile builder built from the event stream, plus connector syncs that pull data into the warehouse from third-party sources using Airbyte-compatible connectors. Note the direction: syncs move data inward, the rest of the system moves events outward.

## Installing Jitsu and sending your first event

The README does not give a single canonical install command for the whole platform. It points to jitsu.com/docs/self-hosting for running it yourself, and to use.jitsu.com for the hosted version, which has a free tier of 200k events per month with no credit card required. If you are evaluating rather than deploying, the hosted path is the shorter route, and the README says a free ClickHouse instance is included so you do not need to provision a warehouse first.

For local development from the repository, the .env.example file documents the expected shape of the environment. It references a Docker Compose dev environment and names the connection variables for Postgres, Redis and Kafka:

```bash
# Run `docker-compose -f devenv/docker-compose.yml up --force-recreate -d`
# Open:
#   1. http://localhost:3011/ for Redis UI
#   2. http://localhost:3032/ for Kafka UI
```

Those commented variables in .env.example are DATABASE_URL, REDIS_URL and KAFKA_BOOTSTRAP_SERVERS, along with LOG_LEVEL and optional GitHub or OIDC auth settings. They are commented out by default, which tells you the dev environment supplies defaults rather than requiring you to set them.

The repository is a pnpm workspace pinned to pnpm@10.22.0. The root package.json exposes the development entry points. To bring the console up in development mode:

```bash
pnpm install
pnpm console:db-prepare
pnpm console:dev
```

console:db-prepare maps to the console package's db:update-schema script, so it is the schema step, not an optional convenience. There is also a rotor:dev script for the event-processing service and a ci:all script that runs format checks, lint, build and tests in sequence.

Once a workspace exists, the README's three-step flow is: create a site (a stream) and take its write key, add a destination, then start sending events. For a Node service, the isomorphic client is the documented option:

```bash
npm install @jitsu/js
```

The README does not print the initialization snippet for @jitsu/js, so check jitsu.com/docs/sending-data/npm for the exact constructor arguments and the write key field name before wiring it into a service. The same applies to the HTTP API and the Segment proxy: the README links to jitsu.com/docs/sending-data/http and jitsu.com/docs/sending-data/segment-proxy but does not reproduce their payload shapes.

## The beta release line is the real constraint

The most concrete limitation is visible in the release list. The three most recent releases are jitsu-services 2.15.0-beta.62, 2.15.0-beta.61 and 2.15.0-beta.60, published on 2026-09-16 and 2026-09-15. The project is publishing beta-tagged builds of the services component, not a 2.15.0 stable. If your organisation requires a stable, semver-tagged release before it will run software in production, that requirement is not met by what the repository currently publishes, and you should plan for either pinning a specific beta build or waiting.

The second constraint is the version file layout. The repository root carries .cli.version.json, .jsclient.version.json and .services.version.json as separate files. The CLI, the JavaScript client and the services are versioned independently. Upgrading one does not imply the others move, and a function written against one CLI version is not automatically validated against a different services version. That is normal for a monorepo with multiple shipped artifacts, but it means your upgrade checklist has three entries, not one.

Third, the documented surface is split across the README and the docs site. The README is a good map and a poor reference: it names the sending methods, the destination catalog, functions and the MCP server, but for payload shapes, function signatures and connector configuration it defers to jitsu.com/docs. Budget time for the docs site rather than expecting the repository to answer integration questions.

Finally, the MCP server is a genuine capability but not a replacement for understanding the pipeline. An agent connected to https://use.jitsu.com/mcp can set up a destination, wire a connection, send a test event, read Live Events, notice a function threw, fix it and re-run. That loop is useful for iteration. It does not tell you whether the destination's batching behaviour suits your query patterns.

## Jitsu against Segment, and against building it yourself

The comparison the project invites is with Segment, and the difference is not feature parity, it is where the pipeline runs and how the bill is computed. Segment is a hosted service; Jitsu is MIT-licensed and self-hostable, with Jitsu Cloud as the hosted option running the same software. The README's two stated deltas are delivery frequency (batches as frequent as a minute, or row-by-row, versus once or twice a day with hourly at best for Segment) and billing basis (event volume rather than Monthly Tracked Users). If your cost is dominated by audience size rather than event count, that billing difference is the argument. If your cost is dominated by event volume, it is not.

The migration path is the part worth calling out. Jitsu ships a Segment proxy endpoint, documented at jitsu.com/docs/sending-data/segment-proxy, which accepts Segment-shaped calls. That means you can repoint existing client code without rewriting instrumentation, then move to native SDKs later or never. This is a more concrete migration story than "rewrite your tracking plan," and it is the feature most likely to decide an evaluation.

The alternative to both is assembling the pipeline yourself: an ingestion endpoint, a queue, a transformation step and per-warehouse loaders. That gives you full control and no vendor surface, at the cost of owning batching semantics, retry behaviour and schema evolution for every destination. Jitsu's value proposition is that this assembly already exists and is configurable; its cost is that you inherit its abstractions, its beta release cadence and its documentation gaps. For a team of one or two engineers without a data platform function, the assembly is usually the wrong use of time. For a team that has already built loaders it trusts, Jitsu is a second system to reconcile.

## Licence, maintenance and what an upgrade actually costs

Jitsu is MIT-licensed, and the root package.json carries "license": "MIT". For self-hosting, that is permissive: you can run it, modify it and ship it internally without a commercial agreement. The repository also carries a THIRD-PARTY-LICENSES.md file, which is the place to look for the obligations that come from dependencies rather than from Jitsu itself. This is a description of what the repository states, not legal advice; if your organisation has a licence review process, the MIT text plus that third-party file are the inputs to it.

On maintenance, the last push to the repository was on 2026-09-22, and the repository is not archived. Releases are frequent: three beta builds landed between 2026-09-15 and 2026-09-16. Frequent beta releases are a signal of activity, and also a signal that the surface moves. Pin your versions rather than tracking the newest tag.

The upgrade cost has three parts, matching the three version files. The services version governs the console and the event-processing services. The CLI version governs jitsu-cli, which is what builds and deploys functions. The JS client version governs @jitsu/js and the React package. A function deployment is a CLI-to-services interaction, so a services upgrade can invalidate a function that passed under the previous pairing. The root scripts give you the checks to run before and after: pnpm typecheck and pnpm test, or pnpm ci:all for the full sequence of format check, lint, build and tests. Running those against your own function repository, not just the Jitsu repository, is the practical form of an upgrade test.

## MCP server: what an agent can and cannot do here

Jitsu ships a Model Context Protocol server, documented at jitsu.com/docs/mcp. The endpoint is https://use.jitsu.com/mcp, or <your-console-url>/mcp when self-hosting. The README's example for Claude Code is a single command:

```bash
claude mcp add --transport http jitsu https://use.jitsu.com/mcp
```

Authentication differs by environment. Interactive clients use OAuth 2.1 with no API key to manage; the first tool call opens a browser tab for approval, and tokens are scoped, listed and revocable from account settings. Headless environments such as CI, cron or servers use a personal API key. The README's text on generating that key is cut off mid-sentence, so the exact generation flow is not documented in the repository and you will need the docs site for it.

The honest read on this feature: it is an operator interface, not an engineering one. The README's own example is an agent setting up a destination, wiring a connection, sending a test event, reading Live Events, spotting a function error, fixing the function and re-running. All of those are things the Management API can also do, and the README says everything the UI does is available through the Management API and the Jitsu CLI. The MCP server is a convenience layer over that. If you already script against the Management API, adding an agent does not unlock a capability you lack. If you do not, the MCP server is a faster way to get a first pipeline running than writing API calls by hand.

## Conclusion

Adopt Jitsu if you want the ingestion and routing layer inside your own infrastructure, or if you are migrating off Segment and want to keep client code unchanged through the Segment proxy. Do not adopt it if you want a stable, versioned API surface: the current release line is 2.15.0-beta.62 on the newjitsu branch, which is what the repository publishes. Before committing, verify two things for yourself: that your target destination appears in the destination catalog with the delivery mode you need, and that the self-hosting path in jitsu.com/docs/self-hosting matches the deployment tooling your team already runs. Everything else is a configuration decision you can reverse.

## FAQ

### What is Jitsu?

Jitsu is an open-source event data platform that the README describes as an alternative to Segment. It collects event data from websites, apps and servers, runs JavaScript functions on each event, and delivers the result to a warehouse or SaaS destination. It is MIT-licensed and can be self-hosted or run on Jitsu Cloud.

### How do I install Jitsu?

The README points to jitsu.com/docs/self-hosting for running it yourself and to use.jitsu.com for the hosted version, which has a free tier of 200k events per month. The repository is a pnpm workspace, and .env.example references a Docker Compose dev environment with Postgres, Redis and Kafka connection variables.

### Which destinations does Jitsu deliver events to?

The README lists ClickHouse, BigQuery, Snowflake, Redshift, Postgres, S3 and GCS, plus dozens of SaaS tools, with the full list in the destination catalog at jitsu.com/docs/destinations/catalog. Delivery is streamed or micro-batched depending on what the destination prefers.

### Can Jitsu replace Segment without changing client code?

The README lists a Segment proxy among the sending methods, documented at jitsu.com/docs/sending-data/segment-proxy, and describes it as the option for migrating off Segment without touching client code. The README does not reproduce the proxy's payload shape, so the docs site is the reference.

### Is Jitsu production-ready?

The three most recent releases are jitsu-services 2.15.0-beta.62, 2.15.0-beta.61 and 2.15.0-beta.60, so the published services line is beta-tagged. The repository is not archived and the last push was on 2026-09-22, but a stable 2.15.0 tag is not among the listed releases.

## Sources

- [jitsucom/jitsu on GitHub](https://github.com/jitsucom/jitsu)
- [License: MIT](https://github.com/jitsucom/jitsu/blob/newjitsu/LICENSE)
- [Project website](https://jitsu.com)
- [README](https://github.com/jitsucom/jitsu/blob/newjitsu/README.md)
- [Releases](https://github.com/jitsucom/jitsu/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jitsucom-jitsu