Production Deployment Guide

Components and services

Jitsu consists of several components and services. The main components are:

• 🔄 Console is responsible for management UI. Console is written in Next.js. Resources: jitsucom/console (docker image), source code, configuration reference
• 🕸️ Ingest provides events ingestion API. Ingest is written in Go. Resources: jitsucom/ingest (docker image), source code, configuration reference
• ⚙️ Rotor consumes events from Kafka, runs the event pipeline and dispatches events to destinations. Rotor is written in Node.js. Resources: jitsucom/rotor (docker image), source code, configuration reference
• λ Function Servers run user functions and profile builders. A function server is the jitsucom/functions-server (docker image) started with ROTOR_MODE=functions. Function servers are not deployed manually — they are provisioned per workspace (or shared for the free class) by the Operator.
• 🤖 Operator is a Kubernetes controller that provisions and scales function-server deployments, services, config maps, autoscalers and disruption budgets, and maintains the FunctionsServer routing table in Postgres. Written in Go. Resources: jitsucom/operator (docker image), source code, configuration reference
• 🚚 Bulker is responsible for batching and sending events to the warehouse destinations. Bulker is written in Go. Resources: jitsucom/bulker (docker image), source code, configuration reference
• 🔌 Syncctl is responsible for running Jitsu Connectors on a Kubernetes cluster: it schedules recurring syncs as Kubernetes CronJobs and runs ad-hoc sync tasks as pods. Resources: jitsucom/syncctl (docker image), source code, configuration reference.
  • Syncctl is optional. It is required only if you want to use the Jitsu Connectors sync feature. Syncctl requires a Kubernetes cluster.

In addition to internal services, Jitsu has a number of 3rd-party dependencies:

• PostgreSQL - for configuration and metadata storage
• Kafka (or Redpanda) - the main transport layer for sending events between components
• ClickHouse - stores the events log and metrics
• MongoDB - required for Persistent Storage, Identity Stitching and profile builders
• Redis - optional; supported as an alternative functions state store

Service Diagram

See the diagram below for a better understanding of the architecture:

Functions and the Jitsu Operator

Since Jitsu 2.14, user functions and profile builders do not run inside Rotor. They run on dedicated function servers — Kubernetes deployments managed by the Operator service:

1. The Operator polls the Console export API (OPERATOR_REPOSITORY_BASE_URL → https://$console/api/admin/export) for workspaces, connections and functions.
2. For each workspace (functions class dedicated) or shard of workspaces (class free), it creates a fs-<deploymentId> Deployment + Service on port 3456, config maps with the workspace's functions, an optional HorizontalPodAutoscaler and a PodDisruptionBudget.
3. Once a deployment is rolled out, the Operator records it in the FunctionsServer table in Postgres. The Console export uses this table to tell Ingest and Rotor which function server serves each connection.
4. Ingest, Rotor and Console reach function servers by URL template — the FUNCTIONS_SERVER_URL_TEMPLATE env var, default http://fs-${workspaceId}:3456, which matches the services the Operator creates.

The Operator is required for event delivery: connections without function-server routing information are dropped by Rotor. Deploy the Operator even if you don't use custom functions.

The Operator needs Kubernetes RBAC permissions for: pods, services, configmaps, secrets, apps/deployments, apps/statefulsets, autoscaling/horizontalpodautoscalers and policy/poddisruptionbudgets. See the configuration reference.

Enabling Jitsu Connectors

Jitsu Connectors require a Kubernetes cluster.

🔌 Syncctl is the service responsible for running connector sync jobs. It is enough for syncctl to have a valid kubeconfig of a Kubernetes cluster — the other Jitsu components don't have to run in the same cluster.

Scheduled syncs are materialized as Kubernetes CronJobs (named sync-<syncId>, labeled jitsu.com/managed-by=syncctl): syncctl polls the Console's /api/admin/export/syncs endpoint and reconciles the CronJobs to match the configured schedules. Sync runs execute as autonomous pods.

How to enable

To enable connector sync support, configure the syncctl service — including SYNCCTL_REPOSITORY_BASE_URL / SYNCCTL_REPOSITORY_AUTH_TOKEN, which drive the CronJob scheduling.

For the console service set SYNCS_ENABLED, SYNCCTL_URL and SYNCCTL_AUTH_KEY env variables.

After starting all Jitsu components, you will see the Connectors menu item in the top bar of the Jitsu Console UI.

To fill the connectors catalog, trigger the catalog-refresh console API endpoint in a browser with an authorized Jitsu user:

http://JITSU_PUBLIC_URL/api/admin/catalog-refresh

Running Jitsu on a Kubernetes cluster

Running all Jitsu components in a Kubernetes cluster is the recommended production setup — this is how Jitsu Cloud runs (on Google Kubernetes Engine), and it's the only setup where all features (functions, profile builders, connector syncs) are available.

There is no official production Helm chart yet:

• The Jitsu repository ships a development Helm chart that deploys development builds of all services (including the Operator and function servers) to Minikube. It's the best reference for how the full Kubernetes architecture fits together, but it is not intended for production use.
• A community-driven chart is available at stafftastic/jitsu-chart; note it may not yet cover the Operator/function-server architecture introduced in Jitsu 2.14.

Configuration Reference

See Configuration Reference for the list of all environment variables and their descriptions, and use the development Helm chart as a reference for service wiring.