On-premise CDP: the event pipeline runs inside your network
An on-premise CDP collects events from your website, apps and backend and loads them into your warehouse without the data passing through a vendor's cloud. Jitsu runs that way in two forms: On Prem on your own infrastructure, and Private Cloud in a dedicated cloud account.
Banks, payment companies and insurers ask for this before they ask about any feature, because their policy keeps customer data in infrastructure they control. The page below answers what their platform and security teams ask next: what gets installed, which warehouse it loads, how people sign in, and what the Enterprise plan covers.
Two ways to run Jitsu inside your boundary
| On Prem | Private Cloud | |
|---|---|---|
| Where it runs | Your infrastructure, on any cloud provider or your own servers | A dedicated GCP or AWS sub-account, yours or Jitsu's |
| Tenancy | Yours alone | Single-tenant, servers not shared with other customers |
| Managed by | Scoped with your platform team for each deployment | Jitsu |
| Sign-in | SSO via OIDC | SSO via OIDC |
| Support | Priority support and an uptime SLA | Priority support and an uptime SLA |
Both come with the Enterprise plan, which also includes a security and compliance review, onboarding and migration assistance, and invoice billing with custom terms.
What gets installed
A production install runs on Kubernetes. These are the services, from the production deployment guide:
| Service | What it does |
|---|---|
| Console | The management UI, the Management API and the MCP server |
| Ingest | Receives events over HTTP and writes them to Kafka |
| Rotor | Reads events from Kafka, runs the pipeline and sends events to destinations |
| Function servers | Run your functions, the JavaScript that filters, reshapes and enriches each event |
| Operator | A Kubernetes controller that provisions and scales the function servers |
| Bulker | Batches events and loads them into the warehouse |
| Syncctl | Runs connector syncs as Kubernetes CronJobs. Needed only with connectors |
And the dependencies they need:
| Dependency | Used for | Needed |
|---|---|---|
| PostgreSQL | Configuration and metadata | Always |
| Kafka or Redpanda | Transport between the services | Always |
| ClickHouse | Jitsu's own events log and metrics | Always |
| MongoDB | The function key-value store and identity stitching | For those features |
| Redis | An alternative function state store | Optional |
Every service ships as a Docker image built from the public repository and is configured with environment variables. Jitsu Cloud runs the same services on Kubernetes.
Where your events go
Events go only to the destinations you configure. For most on-premise installs that is a warehouse already inside the network.
Jitsu loads ClickHouse, Snowflake, BigQuery, Redshift, PostgreSQL and MySQL. A team that already runs one of these points Jitsu at it with a host and credentials. Jitsu creates the tables and adds columns as new event properties appear.
Your website and apps send events to the install at your own domain. Jitsu is compatible with Segment's API, so existing analytics.track calls stay as they are (Segment compatibility).
What a security review covers
| Question | Answer |
|---|---|
| How do people sign in? | SSO via OIDC against your identity provider, on the Enterprise plan |
| Who can change the pipeline? | Workspace roles: owner, editor and a read-only analyst role (access control) |
| Is every change recorded? | The audit log records configuration changes with a field-level diff and secrets masked, membership changes and logins, and whether each came from the UI, the API, the CLI or an agent |
| Can sensitive fields be removed before storage? | A function drops, hashes or truncates fields before an event reaches any destination (PII masking recipe) |
| Can the code be inspected? | Yes. Jitsu is MIT licensed and the source is public, so a review reads the code it is approving |
| What can the vendor show? | Jitsu's SOC 2 report is available on request (security), and the Enterprise plan includes a security and compliance review |
Which one fits
Take On Prem when policy says data stays on infrastructure you own, and you want it backed by priority support and an uptime SLA.
Take Private Cloud when a dedicated single-tenant environment satisfies the policy and you want Jitsu to manage the deployment.
Teams often start on Jitsu Cloud with test events to see the pipeline working, then move. The SDK calls, functions and destination settings are the same on every deployment, so the work done during a trial carries over.
Questions people ask
Is on-premise Jitsu the same software as Jitsu Cloud? Yes. Jitsu Cloud runs the same services on Kubernetes that an on-premise install runs, built from the same public repository.
What does on-premise Jitsu run on? Kubernetes, on any cloud provider or your own servers. The Jitsu operator provisions and scales the function servers, and connector syncs run as Kubernetes CronJobs.
Can Jitsu load a warehouse the company already runs? Yes. Jitsu loads ClickHouse, Snowflake, BigQuery, Redshift, PostgreSQL and MySQL, and connects to an existing one with a host and credentials.
What is the difference between On Prem and Private Cloud? On Prem is a deployment on your infrastructure, on any cloud provider or your own servers. Private Cloud is a single-tenant deployment that Jitsu manages on a dedicated GCP or AWS sub-account, yours or Jitsu's.
Does Jitsu have a SOC 2 report? Yes. The report is available on request, and the security page says how to ask for it.
Get started with Jitsu
On Prem and Private Cloud start with a call that scopes the deployment, the volume and the security review. To see the pipeline before that, send test events to a free Jitsu Cloud workspace.
Further reading: questions to settle before running a CDP on-premise, by Soham Mehta.