Which Apache Superset deployment method fits your team
If you run regulated production workloads and have Kubernetes skills in-house, the official Apache Superset Kubernetes Operator is the documented best practice for production, and the Superset installation methods page notes it carries the steepest skill requirement. Docker Compose is the documented way to try Superset and to develop it, bringing up the application, a Postgres metadata database, Redis, and Celery worker and beat, but the same page says even a fully optimized Compose setup is not as robust as Kubernetes at large scale. A PyPI install suits teams that want no container knowledge at all and are prepared to wire the metadata database, cache, and Celery services themselves. Note that the in-tree Helm chart is deprecated and not recommended for new deployments, so do not base a new build on it.
The Kubernetes path matters when you need to scale with usage and roll out updates with zero downtime, which the installation methods page attributes to Kubernetes. It only pays off if your platform team already runs clusters you can trust, since the cluster itself (control plane, etcd backups, and authentication) becomes part of the system you certify. Confirm with your platform team who owns cluster upgrades and etcd backups before you commit. Compose fits a single-host pilot, a sandbox for analysts, or a developer environment where a restart is acceptable. It is not the answer for a production service with availability targets, because the documentation positions it below Kubernetes for that role.
The PyPI path fits when your organization has a strong Python operations practice and no container platform, but it carries the most hands-on work. You own the metadata database, the cache, the Celery workers for alerts and reports, and the upgrade sequence. The Superset docs also say the documentation for this method is updated infrequently, so plan to read release notes and UPDATING.md yourself. Whichever method you pick, the default lean images lack database drivers and the headless browser needed for Alerts and Reports, so build your own image that extends lean, and back up the metadata database before every upgrade.
Kubernetes operator, Docker Compose and PyPI compared
This table compares the three documented ways to deploy Apache Superset on skill, production fit, scaling, updates, metadata database support, Celery and cache components, image handling and what your team owns. Read each row against the documented statement it cites, and treat anything marked as a point to confirm as an open question for your own environment and vendor documentation.
| Area | Kubernetes with the Superset Kubernetes Operator | Docker Compose on one host | PyPI install |
|---|---|---|---|
| Skill required | Steepest skill requirement; the docs call Kubernetes the best-practice production route | Lower; the docs position Compose as the best way to try and develop Superset | No container knowledge needed, but the most hands-on work of the three |
| Production fit | Documented as the best-practice way to deploy a production instance | Documented as not as robust as Kubernetes for large-scale production, even fully optimized | Documented metadata database defaults (SQLite) are not recommended for production; you assemble production pieces yourself |
| Scaling | Docs state a Kubernetes deployment can scale with usage | Single host; scaling beyond it is not described in the docs | Scaling depends on the components you wire together; confirm with your own sizing tests |
| Zero-downtime updates | Docs state Kubernetes can roll out updates with zero downtime | Not stated in the docs; confirm before relying on it | Not stated in the docs; upgrades follow the general upgrade steps |
| Metadata database | Operator setup is yours to configure; Superset is tested with PostgreSQL 10 to 17 or MySQL 5.7 and 8.x | Compose brings up a Postgres container, which the architecture docs do not recommend for production | You supply the database; SQLite is the default and not recommended for production |
| Celery and cache | Alerts, reports, async queries and thumbnails need the cache and worker components; confirm how the operator deploys them | Compose brings up Redis and Celery worker and beat | You provide Redis or RabbitMQ and Celery for Alerts and Reports |
| Image handling | Build your own image extending the lean image, which lacks metadata database drivers, warehouse drivers and the headless browser for Alerts and Reports | Same lean image guidance applies; -dev images run as root and are not recommended for production | You install drivers and browser components into your own environment |
| Documentation currency | Operator documentation is the current guidance; the in-tree Helm chart is deprecated for new deployments | Covered in the installation methods page | The docs say the PyPI documentation is updated infrequently; check release notes in UPDATING.md |
| What your team owns | Cluster, ingress, secrets, backups of the metadata database, image builds and upgrades, plus Kubernetes version upgrades | Host, Docker runtime, container images, metadata database backups and upgrades | Web servers, workers, Redis, Celery, database, drivers, backups and upgrades, all configured by hand |
What each method's architecture leaves to you
Each deployment method runs a different slice of the Superset stack for you. The cards below separate what the method provides from what your team must operate, back up, secure and keep available, so you can estimate the ongoing work before choosing.
Metadata database ownership
Every method needs a metadata database, and the Superset docs say to back it up regardless of method. Production should use PostgreSQL or MySQL: the configuration docs list PostgreSQL 10 to 17 and MySQL 5.7 and 8.x as supported. The SQLite default of Quickstart and PyPI installs is not recommended for production, and the Docker Compose PostgreSQL container is not recommended for production either. Your team owns backups, restores, patching and sizing of this database in every method. Confirm who runs it before you pick a method.
Redis and Celery workers
Alerts and Reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat processes. A PyPI install leaves you to choose and run Redis or RabbitMQ and Celery yourself. Docker Compose brings up Redis, Celery worker and beat for you, but you still monitor them and size them. On Kubernetes, you decide how these components are deployed and scaled through the operator's configuration. Ask who restarts failed workers and who watches the queue.
Headless browser and custom images
The default lean images lack drivers for your metadata database and data warehouse, and they lack the headless browser that Alerts and Reports need. The docs advise building your own image that extends lean. The -dev images run as root, which the docs do not recommend for production. Under every method, your team owns the image build, the driver versions and the rebuild on each Superset release. Plan a pipeline that produces and scans this image before go-live.
Kubernetes cluster and control plane
With the Kubernetes method, the Superset operator sits on a cluster you must run. Kubernetes documentation recommends at least three control plane nodes behind a TCP load balancer on port 6443 for high availability, and an etcd cluster with an odd number of members, five in production. You must plan etcd backups with etcdctl snapshot save and restores with etcdutl. Kubernetes stores Secrets unencrypted in etcd by default, so configure encryption at rest. Confirm whether your platform team already runs this layer.
Upgrades and version skew
Each method still needs the same Superset upgrade routine: back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes. On Kubernetes, the cluster adds its own lifecycle: kube-apiserver must move one minor version at a time, ahead of controller-manager, scheduler and kubelets, and kubelets may lag by up to three minor versions. Kubernetes gives each release about one year of patch support, so plan cluster upgrades alongside Superset upgrades.
Authentication and secret keys
Superset requires you to set a SECRET_KEY before it starts, and it supports rotation with PREVIOUS_SECRET_KEY. Under any method, you wire identity yourself: OAuth2 providers such as Google or Azure, LDAP, and AUTH_ROLES_MAPPING for group-to-role mapping. On Kubernetes, you also decide how credentials reach pods, because Secrets are stored unencrypted in etcd by default and should use encryption at rest, least-privilege RBAC or an external store through the Secrets Store CSI Driver. Keep the key out of images and version control.
Why the Superset docs call Kubernetes best practice for production
The Superset installation methods page calls Kubernetes the best-practice way to deploy a production instance, and it also notes that Kubernetes has the steepest skill requirement of the three methods. The documentation gives two reasons that matter for a production decision: a Kubernetes deployment can scale with usage, and it can roll out updates with zero downtime. Docker Compose, even when fully optimized, is described as not as robust as Kubernetes for large-scale production. If your dashboards serve many concurrent users or must stay up through upgrades, those two claims are the ones to test in your own environment before you commit.
Use the official Apache Superset Kubernetes Operator for new clusters. The current development docs mark the in-tree Helm chart as deprecated and not recommended for new deployments, so a Helm-based plan starts with a component that is already on the way out. Confirm the operator's current maturity and supported features with the Superset project before you rely on them, because the Superset team's own docs have treated it as the target rather than a finished path for every configuration.
The operator does not remove the cluster work. Your team owns a highly available control plane, which the kubeadm guide describes as at least three control plane nodes behind a TCP load balancer on port 6443, plus an etcd cluster with an odd number of members, five in production, and a tested etcdctl snapshot save backup routine. Your team also owns version skew planning, since kube-apiserver must move one minor version at a time before the other control plane components and kubelets. Ask whether your platform group already runs these controls. If it does not, the Kubernetes option carries effort that sits outside Superset entirely.
Why you need a custom image in every method
The Superset docs say the default lean images do not include every driver a production instance needs. They lack a driver for your metadata database, a driver for your data warehouse, and the headless browser that Alerts and Reports use to render dashboards. None of these gaps is visible on first boot, which is why teams often find them only when a first scheduled report fails or a warehouse connection is refused. The fix the docs point to is to build your own image that extends lean and adds the drivers and browser you actually use.
- Metadata database driver: Required when your metadata database is PostgreSQL or MySQL, the two databases Superset is tested against for this role.
- Warehouse driver: Each SQL database you connect needs its own Python driver, so the list grows with your data sources.
- Headless browser: Alerts and Reports depend on it, so a missing browser fails scheduled delivery rather than the web UI.
- Pinned versions: Your image should pin driver and browser versions so a rebuild does not silently change connection behavior.
- Single source of truth: Keep all added packages in one Dockerfile so the image is reproducible.
Before you build, confirm the exact driver packages and browser setup against the current installation documentation for your Superset version.
The -dev images bundle development tooling and, according to the Superset docs, run as root. The docs state that this is not recommended for production. Running a internet-facing analytics service as root widens the impact of any application compromise, because a process that escapes or is exploited inherits root privileges inside the container. Dev images are useful for contributors and local testing, but they are the wrong base for a production image, whatever the deployment method.
- Root by default: The container process runs with root privileges, which the docs advise against for production.
- Extra tooling: Development packages add attack surface and image size that a runtime image does not need.
- Policy conflicts: Clusters with Pod Security Standards enforcement may reject a root container outright.
- Audit findings: Assessors reviewing container configuration will flag root processes as a control gap.
- Correct base: Extend lean, add only what you need, and set a non-root user in your own Dockerfile.
Ask your platform or security team which base image and user policy they enforce before the first build, and confirm the non-root configuration in your own environment.
On Kubernetes, the custom image is referenced by the workload definition, so the operator or chart pulls whatever tag you specify. The official Superset Kubernetes Operator is the path the docs recommend for new production deployments, and the deprecated Helm chart should not be the basis for new work. In either case, the cluster does not build the image. Your team builds it, pushes it to a registry the cluster can reach, and updates the image reference during each upgrade. Using immutable tags tied to a build identifier keeps rollbacks predictable.
- Image reference: The operator configuration names the registry path and tag for the Superset image.
- Registry access: Clusters need pull credentials and network access to the registry, including in restricted networks.
- Rebuild ownership: The platform or application team owns the Dockerfile, the security patching cycle and the rebuild after each Superset release.
- Rollout: Kubernetes can roll out a new image without downtime, but only if the new image is tested in staging first.
- Image scanning: Scan each built image before it reaches the registry the cluster pulls from.
Confirm with the operator documentation which fields your version exposes for image and pull settings.
Docker Compose on one host builds or pulls the image named in the Compose file, so the custom Dockerfile sits next to the Compose configuration and is rebuilt on the host or in a pipeline. A PyPI install does not use a container image at all, because you install the apache-superset package into your own Python environment. Your drivers and browser still have to be installed in that environment, so the same gaps exist, just expressed as operating system and Python packages rather than as an image. In both cases, one person or team owns the build steps, and that ownership is often informal.
- Compose build: A build context in the Compose file points at your Dockerfile, which extends lean.
- PyPI environment: Drivers are installed with pip into the same environment as the Superset package, and the browser is installed on the host.
- Ownership gap: With one host, the build is often run by whoever set it up, which makes the rebuild cycle easy to forget.
- Upgrade rebuilds: Each Superset upgrade means rebuilding or reinstalling, then running the database upgrade steps in the upgrade documentation.
- Config drift: Hand-installed packages on a PyPI host are harder to reproduce than a versioned Dockerfile.
Before committing to either path, confirm who will run the rebuild after each release and where the Dockerfile or package list is version controlled.
Upgrades, backups and skills for each method
This table compares what each documented Superset install method asks of your team for upgrades, metadata database backups, process monitoring and day-to-day skills. Read it as a list of what you own after go-live, since the docs assign most of that work to the operator in every case. The main takeaway is that all three methods require the same backup and staging discipline, and they differ mainly in how many components you must monitor and how much container or Kubernetes knowledge you need.
| Area | Kubernetes with the Superset Kubernetes Operator | Docker Compose on one host | PyPI install with wired components |
|---|---|---|---|
| Upgrade steps | Back up the metadata database, run superset db upgrade and superset init, test in staging first, and check UPDATING.md for breaking changes, per the upgrade docs. Confirm with the operator documentation how it sequences these steps. | Same upgrade sequence from the upgrade docs applies, but you rebuild or re-pull images and handle the stack yourself. Confirm the exact Compose steps for your chosen version. | Same upgrade sequence from the upgrade docs applies, and you also upgrade the Python environment, Redis or RabbitMQ and Celery workers together. Test the full set in staging. |
| Metadata database backups | The docs say every method requires backing up the metadata database. On Kubernetes, confirm whether your Postgres or MySQL is operator-managed or external and who owns its backup schedule and restore tests. | The docs say the Docker Compose PostgreSQL container is not recommended for production, so you must bring your own backed-up database or volume strategy. Verify restores, not only backup jobs. | You provide the metadata database entirely, since the docs list it as your own component. SQLite from the PyPI default is not recommended for production, so the backup plan starts with replacing it. |
| Zero-downtime rollouts | The installation methods page says Kubernetes can roll out updates with zero downtime. Confirm how this works with your database migrations and your chosen operator version. | No zero-downtime claim is made in the docs for this method, so plan for a maintenance window and confirm this with your own tests. | No zero-downtime claim is made in the docs for this method, and each restart of the web process, workers and beat is handled by your own scripts or service manager. |
| Components to monitor | Web, Celery worker and beat pods, plus the metadata database and cache. The architecture docs say alerts, reports, async queries and thumbnails depend on the caching layer and workers. | Web, Celery worker and beat containers, the Postgres container, and the Redis cache. Confirm container restart and health alerting is in place for each. | Web process, Celery worker and beat processes, Redis or RabbitMQ, and your metadata database. Each runs under a process manager you select and monitor. |
| Operating skills required | Kubernetes administration, Helm or operator concepts, and secrets handling. The docs call Kubernetes the method with the steepest skill requirement, and Kubernetes secrets are unencrypted in etcd by default unless you configure encryption. | Container image building and Compose administration, plus Postgres and Redis basics. The docs call Compose the way to try out Superset, not the most robust path for large-scale production. | Python packaging, web server and process management, and database and queue administration. The docs say this method needs no container knowledge but requires the most hands-on work. |
| Image and driver maintenance | Build a custom image extending the lean image so it includes your metadata database driver, warehouse driver and headless browser for Alerts and Reports. Do not run -dev images in production, since they run as root. | Same image rules apply: extend the lean image, add drivers and the headless browser, and avoid -dev images in production. | You install every driver and the headless browser into your own environment, and you track security updates to those packages yourself. |
| Documentation currency | Follow the operator documentation, and confirm the current status of the Kubernetes Operator with the Apache project before committing, since the Helm chart is deprecated for new deployments. | Follow the Docker Compose guidance in the installation methods page and confirm it matches the release you plan to run. | The docs say PyPI documentation is updated infrequently, so verify each step against the release notes and UPDATING.md before upgrading. |
| Open questions to confirm | Ask who holds backup and restore ownership for the metadata database, how secrets such as SECRET_KEY are stored, and which Kubernetes version your platform team supports. | Ask how the team will restore Postgres and Redis after a host failure, and who patches the host and container runtime. | Ask who owns the Python environment, the Celery broker, and the security patching cadence for every wired component. |
How to upgrade Superset safely under any method
The documented upgrade sequence protects your metadata database and catches breaking changes before production sees them. It ends with a production instance on the target version and a record of what changed.
Confirm the target version and change window
The platform owner picks the target Superset release and records it in the change request before anyone touches a server. Apache Superset 6.1.0 was released on May 13, 2026, and 7.0.0 release candidates appeared in October 2026, so confirm whether your current instance is on a 6.x line and whether 7.0.0 is a release candidate you should avoid in production. Confirm the final version with your own change process and your vendor or DeployOpen engagement scope. The step is done when the target version, owner and rollback contact are written in the change record.
Back up the metadata database
The database administrator takes a full backup of the Superset metadata database before any upgrade step. Superset's installation methods documentation says every method still requires this backup, whether you run Kubernetes, Docker Compose or a PyPI install. Store the backup outside the host or cluster being upgraded and test that it restores into a scratch database. The step is done when the restore test succeeds and the backup identifier is in the change record.
Read UPDATING.md for breaking changes
The engineer responsible for the upgrade reads UPDATING.md in the Superset repository for every release between the current and target versions. Look for changed configuration keys, removed features, dependency changes and database migrations that need manual action. Check your own configuration, including SECRET_KEY handling and any custom images or drivers you built. The step is done when each breaking change is mapped to a task, a config change or a note that it does not apply to your deployment.
Rebuild images and deploy to staging
The platform team builds the new image or package for the target version, including your own image that extends the lean base with database drivers and the headless browser for Alerts and Reports. Deploy it to a staging copy of the production stack, with a copy of the metadata database if your data policy allows it. Check that dashboards load, queries run, Alerts and Reports send, and login works through your identity provider. The step is done when staging passes the test list agreed for the change.
Run database upgrade and init in staging
Run superset db upgrade followed by superset init against the staging metadata database, using the same commands you will use in production. Watch the migration output for errors and confirm the application starts cleanly afterward. Record the duration of this step, since it gives you a planning input for production, even though the documentation does not publish a standard duration. The step is done when migrations complete without errors and the staging application passes the smoke tests.
Apply the upgrade in production
Schedule the production change in the agreed window and take a fresh metadata database backup immediately before the change. Deploy the same image or package used in staging, then run superset db upgrade and superset init. On Kubernetes, the rollout method depends on your operator or chart configuration, so confirm how it handles the migration job before you start. The step is done when the application reports healthy, the migration output is saved, and the old version remains available for rollback.
Verify production and close the change
Run the same smoke tests used in staging against production, including a sample dashboard, a SQL Lab query, a scheduled report and a login through your identity provider. Watch logs and worker queues for errors over the period your change process requires. Confirm with your own change process when the rollback path expires. The step is done when the verification checklist is signed and the change record lists the final version, backup identifier and any follow-up tasks.
Secrets and sign-in settings you carry into any deployment
Whichever method you choose, Superset will not start without a user-specified SECRET_KEY, a requirement added in version 2.1.0. Generate it once, store it outside the image and the repository, and keep the same value across every web and worker process that shares the metadata database. Superset also supports rotating the key with PREVIOUS_SECRET_KEY, so plan the rotation before go-live rather than after a key leaks. Confirm with your security team how the key will be stored and who can read it, because the same secret store will hold database credentials and identity provider settings. The Superset configuration documentation lists the relevant keys.
Sign-in is configured the same way in every method. Superset is built on Flask-AppBuilder and supports OAuth2 providers such as Google and Azure, custom OAuth2 servers that use the code flow, and LDAP. For group-based access, AUTH_ROLES_MAPPING maps LDAP or OAuth groups to Superset roles. Before you write that mapping, ask your identity provider team which group claims or attributes they can supply, whether groups are nested, and how often they change, since a stale mapping quietly grants or removes access. Test with a non-admin account in staging, and confirm how local accounts will be handled for break-glass access if the identity provider is unavailable.
On Kubernetes, the secrets problem gets larger. Kubernetes stores Secrets unencrypted in etcd by default, so the database password, SECRET_KEY and OAuth client secret are readable by anyone with broad access to the etcd data or its backups. Before deploying, confirm that the cluster has encryption at rest enabled for Secrets, that RBAC limits list and watch access to the Superset namespace, and whether your platform team prefers an external store through the Secrets Store CSI Driver. Note that etcd backups carry the same exposure as the live cluster. Document who holds each credential so rotation does not depend on one person.
Questions teams ask before choosing a Superset deployment method
What drives the effort and cost of each Superset deployment method?
The biggest driver is how much of the platform your team must assemble and keep running. The Superset installation methods page describes Kubernetes as the best-practice route for production with the steepest skill requirement, Docker Compose as the fastest way to try Superset, and a PyPI install as the method that needs no container knowledge but the most hands-on work. Costs fall into three buckets: the initial build, the recurring operation (upgrades, backups, monitoring, patching), and the cloud or hardware underneath. Ask any quote to separate these, because a cheap build on Compose can carry higher operating effort later.
How long does a Superset deployment project take?
No duration is published for these methods, so treat any timeline as something to confirm in writing. Length depends on the number of environments, whether you need Celery workers for Alerts and Reports, the metadata database you choose, how many data sources need drivers in a custom image, and how much of your identity integration is in scope. Most engagements are fixed-scope, so the agreed scope, deliverables and timeline should be written down before work starts. Ask for the schedule to list the milestones that depend on your team, such as access approvals and staging sign-off.
Does a Kubernetes deployment need our team to already know Kubernetes?
Yes, a production Kubernetes deployment assumes working knowledge of the platform. The installation methods page labels Kubernetes as the method with the steepest skill requirement, so your team should be able to operate a cluster, manage namespaces, secrets, persistent storage and ingress, and read logs. Kubernetes itself also carries its own operating load: control plane high availability, etcd backups, version upgrades within the skew policy, and Secrets encryption at rest, which Kubernetes does not enable by default. Ask who in your team owns each of these before you pick the method.
Can our own team run a PyPI or Docker Compose install?
A small team can run a Docker Compose install for evaluation or development, since the Superset docs say Compose is the best way to try Superset and to develop it. The same docs say the Compose PostgreSQL container is not recommended for production, and a PyPI install uses SQLite by default, which is also not recommended for production. Running either method in production means your team owns the metadata database, Redis or RabbitMQ, Celery workers and beat, backups, and upgrades. Be honest about whether that work fits your existing on-call and change process.
Is the Superset Helm chart still an option for new deployments?
Not for new deployments. The Superset docs describe the in-tree Helm chart as deprecated and not recommended for new deployments, and point new installs to the official Apache Superset Kubernetes Operator. The 6.1.0 documentation still describes Kubernetes installs with the Helm chart, so existing Helm-based installs may be running a supported version for now. If you already run Helm, plan a migration path to the operator and confirm with your provider what that migration covers.
What should a quote for a Superset deployment include?
A useful quote lists the chosen method, the environments in scope (development, staging, production), and the components to be built: the custom image extending the lean image with the drivers your warehouse needs, the metadata database (PostgreSQL or MySQL in a supported version), the cache and Celery services if Alerts and Reports or async queries are in scope, and the identity integration such as OAuth2, LDAP or group-to-role mapping. It should also state backup and restore testing for the metadata database, the upgrade procedure, documentation, handover and what ongoing support or retainer covers. Ask for every exclusion to be written down.
Which Superset secret and configuration items need attention before go-live?
Start with the SECRET_KEY, which Superset requires you to set before it starts, a rule added in version 2.1.0. Plan how you will rotate it using PREVIOUS_SECRET_KEY, and store it outside source control. Next, confirm the metadata database version against the supported list, which covers PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Finally, the upgrade documentation asks you to back up the metadata database, run the database upgrade and init commands, test in staging, and check UPDATING.md for breaking changes. Ask your provider which of these steps the quote covers and which stay with your team.
What it costs to move between deployment methods later
Plan the metadata database backup and restore test before you move between methods, because every method still requires backing it up and the metadata database is the one component that can usually stay where it is. Superset keeps dashboards, charts, datasets, users, roles and saved queries there, so a Docker Compose, PyPI or Kubernetes install that points at the same PostgreSQL or MySQL instance can often be replaced without rebuilding content. The practical test is a restore of a recent backup into a staging database, followed by a Superset upgrade run against it using the documented steps for superset db upgrade and superset init. Confirm the metadata database versions your target method supports, since the configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x.
Several things do not move on their own and must be carried across by hand. The SECRET_KEY must be supplied again on the new runtime, and if you rotate it you need PREVIOUS_SECRET_KEY during the change so existing sessions and encrypted values remain readable. Identity settings such as the OAuth2 provider configuration, LDAP settings and AUTH_ROLES_MAPPING belong in the new configuration. Your custom image, which should extend the lean image with your warehouse driver and the headless browser for Alerts and Reports, is reusable across Docker Compose and Kubernetes because it is a container build, but a PyPI install has no image, so its driver and browser setup must be rebuilt by hand. Cache and Celery settings also need to match the new topology.
Before committing to the Kubernetes operator, confirm its maturity and scope with the vendor or the project maintainers, since the official Apache Superset Kubernetes Operator documentation is the source to check against your own requirements. Ask which Superset versions it supports, how it handles upgrades, and which components it manages versus which you still provision. Moving from the deprecated Helm chart requires the same confirmation. Treat each move as a fixed-scope change with its own staging run, rollback plan and written sign-off on the restored data.
How DeployOpen scopes and runs Superset deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Apache Superset, that means choosing the deployment method your team can run in its own environment, then building and handing over the metadata database, caching, workers, backups and upgrade path that method requires.
How we scope
- The written scope names the deployment method, the target environment and the metadata database you intend to run.
- Scope lists which Superset services are included, such as Redis, Celery worker and beat, and the headless browser for Alerts and Reports.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before any work starts.
How we build
- We build a custom image that extends the lean Superset image with the drivers your warehouse and metadata database need.
- Configuration covers SECRET_KEY handling, authentication through OAuth2 or LDAP, and role mapping agreed with your identity team.
- Each deployment is tested in staging, including a metadata database backup and restore before go-live.
How we hand over
- Handover documents the chosen method, the image build, the configuration keys and the operational runbook for your team.
- Upgrade steps follow the Superset upgrade process: backup, database upgrade and initialization, staging test, then review of breaking changes.
- Your team receives the backup schedule, restore procedure and the list of components you operate after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Support covers version upgrades and review of Superset release notes for changes that affect your deployment.
- Ask any provider to confirm in writing which operating tasks sit with them and which stay with your own team.
