Putting Apache Superset into production takes far more than running docker compose up. This article lists the 25 critical points to validate before opening access to your users: security, performance, backups, monitoring, compliance. The checklist we apply systematically at TVL Managed Superset, distilled from over 200 deployments.
1. Why a detailed checklist?
Superset is a rich open source tool, but its default configuration is built for development, not production. Taking a POC out of demo mode requires hardening a dozen parameters, adding monitoring, securing backups, and documenting incident procedures. Without this discipline, you'll discover the gaps the day your sales pilot dashboard is opened by the executive committee.
If you want to avoid this friction, TVL Managed Superset applies this checklist by default on every deployed instance.
2. Security (8 points)
1. Strong, secret SECRET_KEY
Generate a 42+ character key with openssl rand -base64 42 and store it in a Kubernetes secret or a vault (Vault, AWS Secrets Manager). Never commit to Git.
2. HTTPS mandatory with HSTS
All access must be HTTPS. Configure ingress to force HTTP→HTTPS and add HSTS:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload3. Admin password changed
The default admin/admin account must be deleted or its password immediately changed. Ideally, authentication uses SSO (OIDC, SAML) and no local accounts remain active.
4. SSO configured
In enterprise, integrate Google Workspace, Microsoft Entra ID, or Keycloak via OIDC. Avoids orphan accounts and centralizes deprovisioning.
5. Secure cookies
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_SAMESITE = "Lax"
WTF_CSRF_ENABLED = True
WTF_CSRF_TIME_LIMIT = None6. CSP (Content Security Policy)
Restrict JavaScript and CSS sources loaded by Superset to limit XSS. Use TALISMAN_ENABLED = True and configure CONTENT_SECURITY_POLICY_WARNING.
7. Row Level Security enabled
For each multi-tenant dataset, configure RLS rules that automatically filter rows by user role. Otherwise, a Gamma user can potentially see another tenant's data.
8. Role permissions audited
Default roles (Admin, Alpha, Gamma, Public) are permissive. Audit and adjust: remove SQL Lab access for non-technical users, restrict visible datasets, disable Public role if unused.
3. Performance (5 points)
9. Redis cache configured
Without cache, every chart render re-runs the SQL query. With Redis, results are cached 5 to 60 minutes per dataset. Typical gain: 10x to 100x on multi-chart dashboards.
10. Celery workers sized
For async exports, alerts, scheduled reports. Plan 1 worker per 50 concurrent users. SUPERSET_WEBSERVER_TIMEOUT at 300s for long queries.
11. Metadata Postgres sized
The metadata DB (storing dashboards, slices, datasets) stays small (~1-5 GB) but absorbs many small queries. PostgreSQL 14+ with 2 vCPU and 4 GB suffices for 200 users.
12. Connection pooling enabled
To external analytical databases, configure SQLAlchemy pool: SQLALCHEMY_ENGINE_OPTIONS = {"pool_size": 10, "pool_recycle": 3600}.
13. Async queries enabled
The feature flag GLOBAL_ASYNC_QUERIES = True lets long queries run without blocking the UI. Essential beyond 50 users.
4. Backups and continuity (4 points)
14. Automated Postgres backups
Daily full backup + WAL streaming for PITR. 30-day retention minimum. Test a restore at least once per quarter.
15. Off-site backups
Backups on the same infra are useless if the datacenter burns. Store a copy on a third-party (Backblaze, Wasabi, cross-region S3).
16. Disaster recovery plan
Document the procedure: which backup to use, how to recreate the cluster, which secrets to regenerate, who to contact. Target RTO: 4h.
17. Regular export of critical dashboards
Beyond DB backups, export critical dashboards in YAML (superset export-dashboards) and version in Git.
5. Monitoring (4 points)
18. Centralized logs
Stream Superset logs (web + workers + Postgres) to Loki, ELK, or Datadog. No kubectl logs in production.
19. Prometheus metrics
Expose application metrics (STATS_LOGGER) and infrastructure (CPU, memory, latency). Grafana dashboard with p95 response, error rate, Celery queue.
20. Alerts configured
At 99% CPU for 5 min, at 5% HTTP 5xx error, at backup failure, alert to Slack/PagerDuty.
21. Synthetic monitoring
An external check (UptimeRobot, Better Stack) calling /health every 60s from 3 geographic points.
6. Compliance and operations (4 points)
22. Audit trail enabled
Enable FAB_ROLES_MAPPING_ENABLED to log connections/disconnections. For fine traceability, enable SQLLAB_QUERY_COST_ESTIMATE_ENABLED and log queries to an external system.
23. GDPR compliant
If processing personal data: signed DPA with your host, processing register, EU hosting, tested erasure procedure. See our dedicated GDPR article.
24. Incident runbook
Document: "how to restart Superset", "how to clear cache", "how to add an emergency user if SSO is down". Host the runbook outside the system itself (Notion, Confluence).
25. Update procedure
Define: how often to update (quarterly), how to test (staging instance), who validates (1 technical reviewer), how to rollback. Without this, you'll stay on Superset 3.x indefinitely and CVEs will pile up.
7. How to quickly check your level?
- 0-10 points: you're in POC, definitely don't go to production;
- 11-18 points: acceptable for internal use, but major risks remain;
- 19-23 points: solid production, comparable to entry-level managed service;
- 24-25 points: exemplary production, equivalent to Enterprise standards.
8. Alternative to implementation time?
This checklist represents at minimum 5 to 10 engineer-days to implement, plus significant recurring load. This configuration is automatically managed by TVL Managed Superset, which applies these 25 points by default on every delivered instance.
For the full economic calculation, see our article managed vs self-hosted: calculated ROI.
9. Typical mistakes this checklist eliminates
- admin/admin password left in place for 6 months;
- Daily backup never tested in restore;
- Redis cache not configured → users complaining of slowness;
- Major upgrade skipped → instance stuck on Superset 2.x with unpatched CVEs;
- No monitoring → discover incident through user tweet;
- RLS forgotten → a Gamma user sees another tenant's data.
10. FAQ
How long to apply the 25 points?
For an experienced DevOps team: 5-10 days of work over 4-6 weeks. For a team new to Superset: double that.
Most critical points if short on time?
If you can only do five: strong SECRET_KEY, HTTPS forced with HSTS, admin password changed, automated and tested Postgres backups, external uptime monitoring. Covers 80% of main risks.
Is this checklist GDPR-compatible?
Yes, it's a solid base. For full GDPR compliance, add a DPA with your host, processing register, and tested erasure procedure.
Redo the checklist on every major upgrade?
Not entirely, but an annual review is recommended. Most volatile points: TLS configuration, Python CVEs, role permissions.
Equivalent checklist for Metabase or Tableau?
Yes, each tool has specifics. However, general principles (HTTPS, SSO, backups, monitoring, audit log) transpose.
11. Conclusion
Putting Apache Superset in production isn't harder than other Python applications but requires rigor. The 25 points listed cover minimum acceptable practices for 2026. Beyond come scale optimization, advanced security (pen-tests, WAF, SAST/DAST), and sector-specific regulatory compliance (HDS for healthcare, PCI DSS for payments). Operational rigor is built over time: an investment, not a one-off project.
Want the benefits of Apache Superset without the friction of installation and maintenance? Deploy your instance in 3 clicks with TVL Managed Superset, hosted in Europe (OVHcloud, Roubaix, France).