Which way should your team run Apache Superset on Kubernetes?
For new production work, the choice between the Helm chart and the alpha operator comes down to risk tolerance and migration effort, not to which tool is more complete. The 6.1.0 documentation still describes the official Helm chart for Kubernetes installs, while the current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Your team has to decide how much change it can absorb now, how much it will absorb later, and who carries the risk if the tool it picks changes shape.
The harder part is that the deployment tooling is the easy layer to replace. The state is not. The metadata database holds dashboards, datasets, users, roles and saved queries. The SECRET_KEY encrypts sensitive values stored in that database, and Superset requires you to set it explicitly before it starts. The cache and Celery workers carry alerts, reports, async queries and dashboard thumbnails. Whichever tool renders these components, the database must be backed up and reachable, the SECRET_KEY must be stored and rotated under a controlled process, and the cache and worker settings must match what the application expects. A change in tooling that loses or regenerates any of these causes an outage or data loss that no manifest diff will show.
The operator's API is the main reason to pin versions and stage every change. Its custom resources use the v1alpha1 API, and the project documentation states that these schemas may change between releases. A manifest that deploys cleanly today can fail or change behavior after an operator upgrade, so your team should pin the operator version, keep its custom resource definitions in source control, and test each operator release in a staging environment that mirrors production's database, cache and worker topology before promotion.
Before choosing, confirm three things with the vendor's current documentation and your own environment: whether the Helm chart remains published and supported for the Superset version you intend to run, what the operator's roadmap says about moving from alpha to a stable API, and whether the operator covers every component you need, including workers, beat and the caching layer. Ask each candidate tool how it handles the metadata database migration step (superset db upgrade and superset init) and where it stores the SECRET_KEY. The answers determine whether you commit now, wait for the operator to stabilize, or run the chart with a planned migration path.
Which Superset components the Kubernetes deployment must run
The Superset architecture lists four components: the Flask and React application, a metadata database, an optional caching layer, and optional Celery worker and beat processes. The first two form the minimum working deployment. The last two carry alerts and reports, async queries and dashboard thumbnails, so a deployment that omits them cannot support those features, whichever Kubernetes tooling you choose.
Flask and React application
The Flask and React application serves the web interface, the REST API and SQL Lab. It holds no dashboard definitions of its own, so several replicas can run behind a load balancer. The risks sit in configuration: every replica must share the same SECRET_KEY and metadata database settings, or sessions fail to validate and users are pushed back to sign-in. Confirm with the architecture documentation whether any pod writes local files, and make sure the image version matches the database migration state before each rollout.
Metadata database
The metadata database stores users, roles, dashboards, charts, datasets, saved queries and the records behind alerts and reports. It is the only component you must treat as stateful. The documentation tests PostgreSQL and MySQL, lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, and advises against the SQLite default and the Docker Compose PostgreSQL container for production. A wrong connection string stops the web tier at startup, and an upgrade without a prior backup can leave the schema hard to recover. Ask who owns backups and restore tests.
Caching layer
The caching layer is optional for basic exploration, but the architecture documentation ties it to alerts and reports, async queries and dashboard thumbnails. Most installations use Redis for this role. Cached data can be rebuilt, so losing it slows queries and empties thumbnails without changing dashboard definitions. Check that the cache is reachable from both the web and worker pods, and set its memory limits and eviction behavior on purpose. Without this component, the three dependent features cannot run.
Celery worker and beat processes
Celery workers execute async queries, alert and report jobs and thumbnail generation. The beat process is the scheduler that triggers timed jobs. Workers need the same image version, configuration and broker connection as the web tier. Beat should run as a single scheduler, because duplicate schedulers can send duplicate reports. Confirm how your chart or operator enforces a single beat instance. If workers are omitted, scheduled and asynchronous work does not run, so users may see queries that never finish. Test that failure mode in staging.
Helm chart or Kubernetes operator: which option fits which team
This table compares the official Helm chart, the alpha Superset Kubernetes Operator, and two adjacent paths so you can match each option to your team's skills, risk tolerance and existing deployment. Read each row as the operational cost you accept by choosing that path, and confirm feature support against the exact version you intend to run. The main takeaway is that the chart is marked deprecated for new deployments, so existing chart users should plan a dated migration while new teams should weigh the alpha operator's schema risk against the Go tooling they will need to maintain.
| Decision factor | Official Helm chart | Superset Kubernetes Operator (alpha) |
|---|---|---|
| Best fit for new deployments | Not recommended: the current development documentation marks the chart as deprecated | Preferred target per current documentation, but only if your team accepts alpha-stage change |
| Best fit for existing 6.x chart deployments | Keep running while you plan a migration date set by your team | Plan a migration in a staging environment first, then move production on a dated change window |
| Production readiness | Documented for Kubernetes installs in the 6.1.0 docs, but deprecated for new work | Alpha: confirm which production settings and integrations your version supports before committing |
| API stability | Chart values are the interface; confirm which values changed between your current and target versions | The v1alpha1 custom resource schemas may change between releases, so pin versions and review each release note |
| Feature coverage | Confirm in the chart values reference which features your target Superset version exposes | Confirm in the operator documentation which components and options your release supports |
| Skills needed to own manifests | Helm templating, values files and Kubernetes manifests that your platform team already reviews | Kubernetes custom resources plus enough Go-based operator knowledge to read controller behavior and file issues upstream |
| Chart deprecation risk | Ongoing: new features and fixes may not arrive on the chart path, so track the deprecation notice in the repository | Not applicable to the chart, but the operator itself may change shape before it stabilizes |
| Operator schema change risk | Low for values structure in the short term, but chart-to-operator migration still requires rewriting manifests | High between alpha releases: budget time to rewrite custom resources on upgrade and test each one in staging |
| Rollback approach | Helm release history can revert the chart revision, but database migrations in a newer Superset version may not reverse | Revert the operator and custom resources together and restore the metadata database backup if the schema has migrated |
| Staying on the chart with a planned migration date | Document the owner, the target date and the staging test that gates the switch, and keep the chart pinned until then | Not applicable as an end state; use this path only as a bridge to the operator |
| Fixed-scope partner build that records the choice | Partner documents the chart version, values, the migration plan and the deprecation exit criteria in a written scope | Partner documents the pinned operator version, the upgrade procedure and the rollback runbook in a written scope |
How to build a production Superset on Kubernetes, step by step
This sequence uses the official Helm chart, the path the 6.1.0 documentation describes, and notes where the Kubernetes Operator path differs. Each of the seven steps closes with a check you can run before moving on, ending with a Superset that answers health checks and signs users in through your identity provider.
Provision the external metadata database
Start with the metadata database, which Superset uses for users, dashboards and configuration. Use PostgreSQL 10 to 17 or MySQL 5.7 or 8.x, the versions the configuration documentation lists. Do not use the SQLite default or the Docker Compose PostgreSQL container, which the architecture documentation does not recommend for production. Host it outside the cluster or as a managed service with automated backups enabled. Done when a client or a pod runs SELECT version() and returns a version inside the supported range.
Provision Redis and the Celery broker
Alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery workers. Deploy Redis as a separate service from the metadata database, with persistence and authentication set according to your platform standard. Create the Celery broker and result backend settings in the Superset configuration, pointing at this Redis endpoint. Done when a pod in the Superset namespace can reach Redis and receives a PONG response from a test connection.
Generate and store the SECRET_KEY
Superset refuses to start without a user-specified SECRET_KEY, a requirement added in version 2.1.0. Generate a long random value with a cryptographic generator, store it in your secrets manager, and inject it into the pods as a Kubernetes Secret. Keep it out of values files committed to version control. Record a rotation plan that uses PREVIOUS_SECRET_KEY before go-live. Done when the web pods pass configuration loading without falling back to a default value.
Deploy the stateless web tier
Deploy the web Deployment with the chart values for the metadata database, Redis and the secret reference, and set more than one replica so a single pod failure does not stop access. Keep the Service internal at this point so no users reach an instance before the schema exists. Done when every web pod is running and its health endpoint, as documented for your release, returns a successful response from inside the cluster.
Run database upgrade and init
Back up the metadata database, then run superset db upgrade and superset init as a one-off Job against the same database and configuration as the web pods. Check UPDATING.md for breaking changes if you are changing versions. Initialization creates the default roles and permissions. Confirm the migration Job exits successfully and that an admin user can be read from the database. Done when the schema version recorded in the database matches the release you deployed.
Deploy Celery workers and beat
Deploy the Celery worker Deployment with the same image, secret and configuration as the web tier, scaling workers separately from web replicas. Run beat as a single instance, because more than one scheduler would trigger scheduled reports twice. Done when you run a test async query from SQL Lab, the worker logs show it picked up the task, and the result returns to the browser.
Configure ingress, HTTPS and identity login
Create the ingress with a valid TLS certificate, set the public URL in the configuration, and point the Service to the web pods. Configure your identity provider through OAuth2, LDAP or the method your team uses, then map groups to roles with AUTH_ROLES_MAPPING. Done when a user signs in through the identity provider over HTTPS, lands on the home page with the expected role, and a user outside the mapped groups is denied.
Moving an existing Helm chart release to the operator without losing metadata
The first task in this migration is keeping Superset's state intact, and the choice of tooling comes second. The metadata database holds dashboards, datasets, users and roles, so moving from the Helm chart to the operator is a data-preservation exercise before it is a tooling change. Superset also stores some values in encrypted form, such as database connection credentials, and their protection depends on the SECRET_KEY. If the new deployment starts with a different key, existing sessions can fail and those encrypted values may become unreadable. Treat the database, the key and the upgrade steps as one unit of work, and assign an owner to each before any manifest is applied to the cluster.
Work through the sequence from the upgrade documentation in order. First, take a backup of the metadata database and test that you can restore it into a scratch instance, because an untested backup gives little assurance. Confirm the engine and version against the supported list in the configuration documentation, which covers PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Second, record the SECRET_KEY the chart currently injects and carry the same value into the new deployment. If you plan to rotate it, set the new key and place the old one in PREVIOUS_SECRET_KEY so sessions and encrypted values stay readable during the transition. Third, read UPDATING.md for every breaking change between the running release and the target version.
Rehearse the whole path in staging against a restored copy of production metadata before any cutover. Once the new deployment points at the migrated database, run superset db upgrade to apply schema migrations, then run superset init to set up default roles and permissions. Verify the outcome inside the application: sign in with a representative set of accounts, open a sample of dashboards and datasets, run SQL Lab queries against each source connection, and check that role assignments still match your access model. If you use alerts, reports, async queries or thumbnails, also confirm that the caching layer and Celery workers are reachable from the new deployment, since those features depend on them.
The supplied material does not document a migration path from a Helm chart release to the Apache Superset Kubernetes Operator, so do not assume one exists. Confirm the procedure with the operator documentation and the project before you schedule cutover. Ask specifically how the operator reads an existing metadata database, which SECRET_KEY it expects, and whether it runs the database upgrade itself. The operator is in alpha with a v1alpha1 API whose custom resource schemas may change between releases, so pin the version you test and expect manifest changes. Plan rollback before cutover: keep the chart release and its configuration available, and name the backup that would return data to it. Rolling back means restoring that backup and redeploying the chart with the original key, because reverting the manifests alone will not return the data.
How to handle SECRET_KEY, metadata credentials and role mapping on Kubernetes
Superset on Kubernetes depends on a handful of secrets and identity settings that every web pod, worker and beat process must read consistently. The controls below cover where those values live, how they rotate, and how group membership becomes Superset roles, whichever tool deploys the workloads.
Store SECRET_KEY in the cluster secret store
Superset requires a user-specified SECRET_KEY to start, and it signs session data, so it must be identical across every web pod. Put it in a Kubernetes Secret or an external secret manager that syncs into the cluster, and reference it from the deployment rather than writing it into Helm values files or Git. If the key lives in a values file, anyone with repository access can read it and forge sessions. Confirm that the secret is injected into web pods and workers alike.
Rotate SECRET_KEY with PREVIOUS_SECRET_KEY
Superset supports rotating the key by setting PREVIOUS_SECRET_KEY alongside the new SECRET_KEY, so existing sessions remain readable during the change. Document the sequence: add the new value, roll the web pods, wait for the old sessions to expire, then remove the previous value. Without this procedure, a simple key change logs out every user and can break encrypted fields that depend on the old key. Test the rotation in staging against the chart or operator version you run.
Scope metadata database credentials to Superset
The metadata database holds dashboards, users, roles and connection definitions, so its account should own only the Superset schema. Create a dedicated role for the application, grant it access to that schema, and keep administrator credentials out of the cluster. The database must be PostgreSQL or MySQL in a supported version, and the connection string should come from the same secret mechanism as SECRET_KEY. A shared superuser account turns any application compromise into full database access.
Keep Redis and broker credentials out of plain configuration
Caching, async queries, alerts and reports depend on Redis and a Celery broker, and their connection URLs often contain passwords. Keep those URLs in Secrets and mount them into web pods, workers and beat processes, never in ConfigMaps or inline chart values. A plaintext broker URL in a ConfigMap is readable by any service account with namespace read access. Confirm which components receive each URL, because a missing value on the beat process stops scheduled reports silently.
Map groups to roles with AUTH_ROLES_MAPPING
When Superset authenticates through OAuth2 or LDAP, AUTH_ROLES_MAPPING translates identity provider groups into Superset roles. Decide the group-to-role table before deployment, keep it in version-controlled configuration, and review it against your role model. A mapping that grants Admin to a broad group is a common access failure, and users with no matching group may land with no useful role. Ask your identity team which group claims the provider emits, since they vary by provider.
Reflect identity configuration in the deploying tool
The OAuth or LDAP settings and the role mapping live in Superset's configuration, so the tool that deploys the web pods must carry them, whether that is the Helm chart values or the operator custom resource. If the identity block is set only in a manual change to a running pod, the next upgrade or redeploy removes it and login falls back to defaults. Keep identity settings in the same repository and pipeline as the rest of the deployment, and verify the rendered configuration after each change.
What drives the effort of a Kubernetes Superset rollout
This table lists the factors that move effort and cost in a Superset rollout on Kubernetes and shows how to keep each one contained. Read each row as a lever: the driver explains why it matters, and the right column says what to decide or freeze early. The main takeaway is that the operator's alpha status makes version pinning and a single rehearsed migration the most valuable cost controls.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of environments | Dev, staging and production each need their own deployment, secrets, data connections and upgrade runs, so effort grows with every copy. | Use one set of values files across environments and change only the environment-specific settings such as hostnames and secret references. |
| Metadata database choice | A self-managed PostgreSQL or MySQL instance adds backup, patching and failover work that a managed service would handle. | Confirm the database version against the supported list (PostgreSQL 10 to 17, MySQL 5.7 and 8.x) and decide early whether your platform team will operate it. |
| Cache and Celery workers from day one | Alerts, reports, async queries and thumbnails need the caching layer and worker processes, which add components to deploy, scale and monitor. | Decide which features are in scope for the first release and defer worker-dependent features until the core rollout is stable. |
| Data source connections | Each database or warehouse needs network paths, service credentials, driver images and connection testing, and the count multiplies testing effort. | Start with the sources needed for the first dashboards and add the rest in batches with a repeatable connection checklist. |
| Identity integration complexity | Connecting an OAuth2, OIDC or LDAP provider and mapping groups to roles with AUTH_ROLES_MAPPING requires coordination with identity teams and test accounts. | Pick one identity method for go-live, agree the group names in writing and test role mapping in staging before production. |
| Team Kubernetes and Go tooling experience | The operator is built with the Go Operator SDK and is alpha, so teams unfamiliar with custom resources and controller behavior need more time to learn and debug. | Assess the team's skills before choosing the operator, and budget for training or a partner who has run similar deployments. |
| Alpha tooling changes before go-live | The v1alpha1 API may change between releases, so each operator update can require manifest edits, retesting and rework. | Freeze the operator version for the project, track its release notes and schedule upgrades as planned work rather than ad hoc changes. |
| Compliance evidence requirements | Assessors expect records of configuration, change control, access reviews and backups, and generating that evidence adds work to every release. | Agree the evidence list at the start, capture configuration in version control and reuse one staging rehearsal for the migration to produce the records once. |
How to test that the Kubernetes Superset deployment works and fails safely
Start with a written verification plan that every Superset deployment must pass before users reach it, whether it was built from the Helm chart or the operator. The first checks confirm the foundation. Confirm that the metadata database version falls within the range the configuration documentation supports: PostgreSQL 10 to 17, or MySQL 5.7 and 8.x. Then confirm that the web pods start only when SECRET_KEY is set by you, because Superset requires a user-specified key to start, a requirement added in version 2.1.0. Record the database version output, the environment check for the key (never the key value itself), and the deployed Superset version, so the next engineer can see exactly what was tested.
Next, prove the components that the architecture documentation ties to async queries, alerts and reports, and dashboard thumbnails. Run an SQL Lab query in async mode and confirm the results return through the worker path. Schedule a report to a test recipient and confirm delivery, then trigger a dashboard thumbnail. Check the worker and cache logs during each run for connection or task errors. Record the timestamp, the chart or query name, the outcome and the log excerpt. If a run fails, test the worker and cache wiring on its own before changing the web tier, since that is where these features depend.
Then verify access. Sign in as one test user from each group that AUTH_ROLES_MAPPING maps to a Superset role, using the identity method you configured (OAuth2, LDAP or another supported option). For each user, confirm the role received matches the mapping and that the user can see only the datasets and dashboards that role should reach. Remove a test user from a group in your identity provider, sign in again, and confirm the role changes as expected. Keep the test accounts documented, and record the group names, the roles granted and exported permission lists as evidence.
Now test failure behavior. Restart one worker pod while an async query is running, then record whether the query completes, retries or reports an error to the user. Take the cache offline and observe the degradation described in the architecture documentation, confirming that the web application continues to serve pages. Compare what you see against the behavior you documented before the test, and check the logs for errors that suggest lost task state. Any gap between expected and observed behavior goes into the findings log with an owner, before go-live rather than after an incident.
Finally, prove recovery. Restore the metadata database backup into a scratch environment, start Superset against it, and confirm that the restored instance signs in and shows the expected dashboards and roles. Then rehearse a failed upgrade in staging. Follow the upgrade documentation: take a backup, run superset db upgrade and superset init, and review UPDATING.md for breaking changes. Deliberately treat the upgrade as failed, restore the backup, and confirm the environment returns to the prior version and state. Record the restore steps, the elapsed time you measured, the version before and after, and the login checks you repeated.
What to monitor, back up and upgrade after go-live
Once Superset is live, the Kubernetes layer and the application layer each need their own signals. Watch the pods that serve the web application, the workers that run alerts, reports and async queries, and the two stateful dependencies they rely on. Superset's architecture documentation ties alerts and reports, async queries and dashboard thumbnails to the caching layer and worker components, so a failure there often appears as missing reports or stalled queries while the web pods look healthy.
- Web pod health: Track readiness, restart counts and resource pressure for the web deployment, and confirm that probes exercise the application rather than only confirming that a process exists.
- Worker queue depth: Alert on a growing Celery backlog, since a stalled beat scheduler or worker can fail without an obvious user-facing error.
- Cache availability: Monitor the Redis endpoint for availability and memory pressure, because a cache outage degrades the features that depend on it.
- Metadata database connections and errors: Watch connection counts against the pool limits you configure, along with database error logs, since connection exhaustion can cause intermittent web errors.
Confirm alert routing and thresholds with your platform team, and verify which metrics and probe settings your chosen deployment method exposes before you build dashboards around them.
The metadata database holds dashboards, datasets, users, roles and saved queries, so it is the first item you must be able to rebuild. Set a backup schedule that matches how much change your organization can afford to lose, and prove that backups work by restoring them into a separate environment. A backup that has never been restored is still an untested assumption.
- Metadata database backups: Use the native or managed backup tooling for your PostgreSQL or MySQL service, set retention to your policy, and record where backups are stored and who can access them.
- Tested restores: Restore into a non-production namespace on a regular schedule, then confirm that logins, dashboards and a sample query work after the restore.
- SECRET_KEY storage: Keep the SECRET_KEY in your secrets manager, outside values files and manifests stored in git. Superset requires it to start, and the restored environment needs the same value to read the data the application protects.
- Rotation record: Keep a dated log of each rotation, including the PREVIOUS_SECRET_KEY value used during the transition, and store that log separately from the backups it relates to.
Before go-live, confirm that a restore into an empty cluster brings Superset back with its metadata and secret key intact, and that the rotation record is readable by the people who would perform a recovery.
On Kubernetes, an upgrade touches two moving parts: the Superset application and the tooling that deploys it. The step-by-step database and application upgrade sequence is covered on the upgrades and support page, so this tab focuses on the checks specific to the cluster. Review the tooling change before you change the application version, because a new chart or operator release can alter how the application is configured.
- Pinned tooling versions: Record the Helm chart or operator version you deployed, and read its release notes before you change it.
- Operator alpha releases: The Apache Superset Kubernetes Operator is in alpha with a v1alpha1 API, and its custom resource schemas may change between releases, so expect manifest edits and review them before applying.
- Staging first: Apply each tooling change to a staging namespace built from the same values files, then confirm the result before the production change window.
- Deprecated chart: The current development documentation marks the Helm chart as deprecated, so if you run the chart, plan a move to the operator and test that move in staging first.
Before any production change, confirm that the staging environment matches production in its values, secrets references and ingress settings, so that the tested result reflects what production will run.
Kubernetes deployments drift quickly, because much of their configuration lives in values files, manifests and cluster settings spread across repositories and consoles. A short, current set of records lets an on-call engineer or an auditor see what is running, why it was configured that way and how to recover it. Treat these records as operational deliverables that change with every deployment.
- Values files: Keep the version-controlled values or custom resource files for each environment, with secret values referenced from your secrets manager and never stored in the file.
- Tooling and application versions: Record the chart or operator version, the Superset version and the Kubernetes version in use, along with the date each was last changed.
- Migration record: Log each metadata database migration, the commands run, the person who ran them and the outcome, so the history of schema changes is traceable.
- Runbook: Document restart, scaling, restore, secret rotation and rollback procedures, with a named owner for each and a link to the monitoring views that confirm success.
Review these records after each change and confirm that they match what is actually deployed, because a runbook that describes an earlier configuration can slow recovery during an incident.
Questions buyers and platform teams ask before running Superset on Kubernetes
Does the Helm chart still work for Superset 6.1.0 deployments?
The 6.1.0 documentation describes installing Superset on Kubernetes with the official Helm chart, so a 6.1.0 deployment built on that chart follows the documented path. The current development documentation, however, marks the chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. The chart is therefore on a retirement path even though it is documented for this release. Before you rely on it, confirm with the project which chart version matches your target Superset image, check your values against the 6.1.0 configuration, and read the chart's release notes. Plan the migration path now so a deprecated chart does not force a change during a security update.
Should new production Superset deployments on Kubernetes use the alpha operator?
Only if your team accepts the risk of an alpha component. The Apache Superset Kubernetes Operator is built with the Go Operator SDK, uses a v1alpha1 API, and its custom resource schemas may change between releases. An operator upgrade can therefore require rewriting manifests or running migration steps that the chart did not need. Teams that choose the operator should pin operator and image versions, keep custom resources in version control, read release notes before every upgrade, and test each change in staging. Teams with limited capacity for that work may run the chart for a period, but they should set a date to revisit the decision. Base the choice on how much change your team can absorb.
What does migrating Superset from the Helm chart to the operator involve?
Migration moves existing application state into new deployment objects, so the work centers on data, secrets and configuration. Start with a backup of the metadata database, which holds dashboards, datasets, users and roles. Keep the SECRET_KEY identical, because Superset requires one to start and uses it to protect sensitive values. If you rotate the key, use PREVIOUS_SECRET_KEY during the transition. Carry over configuration overrides, the caching layer, Celery workers and beat, and ingress and TLS settings. Then run the database upgrade and init steps from the upgrade guide, check UPDATING.md for breaking changes between versions, and rehearse the cutover in staging. Keep the chart deployment available until the rollback path has been tested.
What does a fixed-scope Superset on Kubernetes build include, and what drives the cost?
A fixed-scope build is agreed in writing before work starts, and each deliverable is named in that scope. Typical components include topology design, the application deployment, the metadata database connection, the caching layer and Celery workers if you need alerts, reports, async queries or thumbnails, identity integration, secrets handling, TLS, backups, staging tests, documentation and handover. Cost rises with the number of components in scope, the number of environments, the complexity of group-to-role mapping, the number of data sources to connect and test, and how much platform work stays with your infrastructure team. One-time build costs sit alongside recurring costs such as infrastructure, upgrades and support. Ask the quote to separate those lines, list its assumptions, and state which tasks remain yours.
How long does a Superset on Kubernetes implementation take and what changes it?
The written scope sets the timeline for your environment, and no duration applies to every deployment. The main drivers are how ready the cluster and cloud accounts are, approval cycles for access and changes, identity provider setup and group design, database instance provisioning and backup policy, the number of data sources and datasets, and the number of environments. The operator path adds testing time for alpha-specific behavior, and a migration adds time for data validation and cutover rehearsal. Ask for a phased plan with dependencies, an owner for each client-side dependency, and the gates each phase depends on. A timeline that does not name those dependencies is incomplete.
What must our team provide before a Superset on Kubernetes build starts?
Early access and information prevent most schedule slips. Typical inputs include cluster access with the namespaces, RBAC and network policies the deployment needs, and the cloud or data center accounts that host it. Provide a metadata database on PostgreSQL 10 to 17 or MySQL 5.7 or 8.x, with backups, plus cache and worker infrastructure if alerts, reports or async queries are in scope. Supply identity provider details such as OAuth2 client registration or LDAP settings, along with the group names that will map to roles. Also provide DNS, TLS certificates, a secret store, credentials for each data source, and a staging environment that mirrors production. Name an owner for each approval and confirm every item in the quote so the build team is not waiting on inputs.
Can our platform team build and run Superset on Kubernetes without a partner?
Yes, if your team already runs Kubernetes workloads, operates a relational database, and can handle identity integration and upgrades. Superset is licensed under Apache-2.0 and has no paid edition, so the cost sits in the surrounding work: topology, secrets, backups, upgrade testing against UPDATING.md, monitoring and on-call coverage. Assess your team's skills in each of those areas honestly, and estimate the time it can spare if you choose the alpha operator. A partner makes sense when internal capacity or specific skills are short. DeployOpen works as a fixed-scope build, a migration or an ongoing retainer, and the written scope states which tasks stay with your team.
Does DeployOpen issue compliance certifications for a Superset deployment?
No. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies issue those. DeployOpen prepares the system, the controls and the evidence that assessors review, such as documented configuration, the access model, backup and recovery records, change logs and hardening evidence mapped to the control set your assessment uses. Ask the quote to list which evidence is produced, who owns each control, and what the assessor is expected to review. Confirm the assessment scope and requirements with your auditor before work starts, because the auditor decides what counts as sufficient evidence.
How DeployOpen works on this
DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted Apache Superset inside your own cloud accounts, data centers or air-gapped networks. For Kubernetes, we start by confirming which deployment path your team can support, since the Helm chart is deprecated and the Superset Kubernetes Operator is in alpha. The work then follows a written scope, a staged build, a documented handover and optional retainer support.
How we scope
- The written scope names the Superset version, the chosen Kubernetes deployment path, and the target cluster.
- Scope covers the metadata database, cache and workers, data source connections, and the role model.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts; ongoing support is available as a retainer.
How we build
- We compare the Helm chart and the operator for each environment, recording the trade-off and the upgrade path in the design document.
- Build covers Kubernetes manifests or chart values, secrets handling for SECRET_KEY, and externalized configuration for upgrades.
- Each build is tested in staging first, covering login, dashboard rendering, async queries and scheduled reports.
How we hand over
- Handover includes deployment manifests or chart values, runbooks for backups, upgrades and secret rotation, and architecture notes.
- Your team receives documented steps for metadata database backup and restore, plus the superset db upgrade and superset init sequence.
- Knowledge transfer sessions walk through the chosen deployment path, its alpha or deprecation status, and how to plan for change.
How we support
- Support options cover monitoring the application, cache and workers, and reviewing UPDATING.md before each Superset version change.
- Upgrades follow the documented path: back up the metadata database, test in staging, then apply the change to production.
- Retainers can include upgrades, continuous testing and operator version tracking, as agreed in the written support terms.
