RudderStack

Last reviewed Sep 13, 2026 · 848 words

The self-hosted RudderStack you can download is the data plane: the Go server that receives events from your SDKs, batches them, and delivers them to a warehouse or to a destination like Mixpanel or a webhook. The control plane, meaning the web UI where you define sources, destinations and transformations, is RudderStack's hosted product. The open-source server either pulls its configuration from your free RudderStack Cloud workspace or reads it from a JSON file you maintain by hand. Nobody says this clearly enough. If "self-hosted" means "no account with the vendor" to you, this is not that, and you should know it before you allocate the 2 GB of RAM.

Where it fits, and who is actually running it

RudderStack is an alternative to Segment, which means it is for teams that instrument a product with events (identify, track, page) from web, mobile and backend SDKs and want those events to land in a warehouse they own (PostgreSQL, ClickHouse, BigQuery, Snowflake, S3) and fan out to tools such as ad platforms, email and product analytics. "Warehouse-first" is the design: the raw event stream is the source of truth and everything else is a destination. The people running it are product and data engineering teams at companies of 10 to a few hundred people who looked at Segment's bill. Homelabbers have very little use for it, and if what you want is website visitor counts, Plausible does that in about 200 MB with no pipeline at all.

The open-source edition is AGPL-3.0 and lacks some features of the paid tiers, notably parts of the warehouse and transformation tooling and the newer connectors. Check the feature comparison on their site before assuming a destination is available to you.

What the stack looks like on your box

Three services minimum:

services:
  rudder-server:
    image: rudderlabs/rudder-server:latest
    ports: ["8080:8080"]
    environment:
      - JOBS_DB_HOST=db
      - JOBS_DB_USER=rudder
      - JOBS_DB_PASSWORD=change-me
      - JOBS_DB_DB_NAME=jobsdb
      - DEST_TRANSFORM_URL=http://transformer:9090
      - WORKSPACE_TOKEN=from-your-rudderstack-cloud-workspace
    depends_on: [db, transformer]
  transformer:
    image: rudderstack/rudder-transformer:latest
  db:
    image: postgres:16

The server keeps its queue in PostgreSQL (the "jobsdb"), so the database is not optional and it does real work: under sustained load it sees more writes than your warehouse does. The transformer is a Node service that runs destination mappings and your custom JavaScript or Python transformations. The repository ships a rudder-docker.yml that wires this up, and Kubernetes users get a Helm chart. 2 GB is the honest floor for an idle stack; a few hundred events per second wants 4 GB and a database on fast disks.

To run without the cloud control plane, set RSERVER_BACKEND_CONFIG_CONFIG_FROM_FILE=true and mount a workspaceConfig.json. You lose the UI and you maintain destination configuration as JSON, which is how a small number of air-gapped installations run it. It is supported. It is not pleasant. Either way, upgrades are the usual image bump; the jobs database schema migrates itself on start, and the one operational habit worth building is watching the jobsdb table sizes, because a destination that has been failing for a day shows up as a queue that will not drain rather than as an alert.

PostHog answers the single-tool question

The first thing to decide is whether the warehouse is worth it. If your product analytics questions are answered by a single tool, PostHog captures events, stores them, and gives you funnels, session replay and feature flags in one self-hosted install, with roughly 5 times the community. RudderStack earns its place when several downstream tools all need the same clean event stream, or when the warehouse is the point because analysts write SQL against it. For startup-sized event volume, a PostgreSQL destination is simpler than standing up ClickHouse and is where I would start.

The control plane dependency is the real trade

The second is whether you can tolerate the hosted control plane. An outage at RudderStack's cloud does not stop your data plane, because the server caches its configuration, but it does stop you changing anything until it returns, and a change to their free tier would land on you with no migration path except the JSON file. For most teams that is acceptable, since the events and the warehouse stay on your side. For a compliance-driven deployment it may not be, and that is worth settling before the first SDK is wired in.

What I'd do

If you are a data or product engineering team replacing Segment: run rudder-server and the transformer in Docker or the Helm chart, with a dedicated PostgreSQL for the jobs queue, a warehouse destination as the first and most important sink, and the free cloud workspace as the control plane, eyes open about the dependency. The Segment switching guide covers the migration. If you are anyone else reading the analytics category, you want PostHog for product analytics or Plausible for the website, and neither needs a pipeline in front of it.