Layer 5 · self-hosting reality check
What it actually takes to self-host Apache Superset
The docs say Not stated by the vendor. The only figure in its docs is the FAQ's community report that 8 GB RAM and 2 vCPU run a moderately-sized instance. In practice you want 8 GB with 2 vCPU, the community figure the Superset FAQ cites. The FAQ says needs grow with concurrent users and their activity, not with data size. Here is the honest version — real requirements, real monthly cost, what you will be maintaining, and the one thing that catches people out.
Usually reached from Tableau alternatives, where Apache Superset is one of the picks.
Wondering whether you need to at all? Is Tableau free? — what the free tier actually allows, and where the wall is.
| RAM — documented minimum | Not stated by the vendor. The only figure in its docs is the FAQ's community report that 8 GB RAM and 2 vCPU run a moderately-sized instance |
|---|---|
| RAM — what it really needs | 8 GB with 2 vCPU, the community figure the Superset FAQ cites. The FAQ says needs grow with concurrent users and their activity, not with data size |
| CPU | 2 vCPU, per the FAQ's community report |
| Disk | Small for Superset itself. The metadata database holds charts, dashboards, users and logs, cached results go to Redis, and your data stays in the warehouse Superset queries. |
| Monthly cost | $24–48/mo on an 8 GB VPS for a compose install with PostgreSQL and Redis on the same box. The docs call that setup not production-ready; production means Kubernetes and a managed, backed-up metadata database, which costs more |
| Setup time | An hour to try with docker compose; days to a production setup, because the supported route is Kubernetes |
| How you install it | docker compose with docker-compose-image-tag.yml to try it (Superset, workers, PostgreSQL, Redis). For production the docs recommend Kubernetes through the Superset Kubernetes Operator; the old Helm chart is deprecated |
| Ongoing maintenance | Every upgrade needs a metadata-database backup, `superset db upgrade`, `superset init` and a read of UPDATING.md for breaking changes. The docs recommend trying each upgrade in staging first. |
| Where it stops scaling | Docker compose stays on one host with no high availability. Past that it is Kubernetes: several web and Celery worker pods on a managed metadata database and Redis. |
The thing that catches people out
Superset encrypts the database passwords it stores with SECRET_KEY. Lose or change that key and every saved connection fails with 'Invalid decryption key'. The usual causes are a regenerated env file, a second instance with a different key, or a variable that did not survive a restart. GitHub issues show it happening after a plain restart and across two instances sharing one metadata database. Generate the key once with openssl rand -base64 42 and keep it with your backups. Rotate it only by setting PREVIOUS_SECRET_KEY and running superset re-encrypt-secrets.
When not to self-host Apache Superset
You want a single-box install that your team can run without Kubernetes. The project itself says its docker compose setup is not production-ready. Metabase runs as one container on a small VPS with a PostgreSQL application database.
Every guide here carries this section. A site that only ever tells you to self-host is selling something — the useful answer is sometimes no.
Other Layer 5 self-hosting guides
- Self-hosting LibreOffice2 GB with a large spreadsheet open
- Self-hosting ONLYOFFICE6 GB for the Document Server with a handful of concurrent editors
- Self-hosting Collabora Online4 GB, and roughly 1 GB per 20 concurrent documents
- Self-hosting CryptPad2 GB for a small instance
- Self-hosting Mattermost4 GB for a team of 50 with PostgreSQL on the same box
- Self-hosting Rocket.Chat6 GB with MongoDB on the same machine
Common questions
- How much RAM does Apache Superset actually need?
- 8 GB with 2 vCPU, the community figure the Superset FAQ cites. The FAQ says needs grow with concurrent users and their activity, not with data size in practice. The documented minimum is Not stated by the vendor. The only figure in its docs is the FAQ's community report that 8 GB RAM and 2 vCPU run a moderately-sized instance, which is the figure at which the process starts rather than the figure at which it works under real use. 2 vCPU, per the FAQ's community report alongside it.
- What does self-hosting Apache Superset cost per month?
- $24–48/mo on an 8 GB VPS for a compose install with PostgreSQL and Redis on the same box. The docs call that setup not production-ready; production means Kubernetes and a managed, backed-up metadata database, which costs more This is commodity VPS pricing and excludes your time, which is the larger cost for most people — budget for every upgrade needs a metadata-database backup, `superset db upgrade`, `superset init` and a read of UPDATING.md for breaking changes. The docs recommend trying each upgrade in staging first.
- How long does it take to set up Apache Superset?
- An hour to try with docker compose; days to a production setup, because the supported route is Kubernetes, via docker compose with docker-compose-image-tag.yml to try it (Superset, workers, PostgreSQL, Redis). For production the docs recommend Kubernetes through the Superset Kubernetes Operator; the old Helm chart is deprecated.
- When should I NOT self-host Apache Superset?
- You want a single-box install that your team can run without Kubernetes. The project itself says its docker compose setup is not production-ready. Metabase runs as one container on a small VPS with a PostgreSQL application database.
- What is the most common mistake when self-hosting Apache Superset?
- Superset encrypts the database passwords it stores with SECRET_KEY. Lose or change that key and every saved connection fails with 'Invalid decryption key'. The usual causes are a regenerated env file, a second instance with a different key, or a variable that did not survive a restart. GitHub issues show it happening after a plain restart and across two instances sharing one metadata database. Generate the key once with openssl rand -base64 42 and keep it with your backups. Rotate it only by setting PREVIOUS_SECRET_KEY and running superset re-encrypt-secrets.