Turn off Apache Superset telemetry

Why security teams ask how to turn off Apache Superset telemetry

A security or platform lead who has approved Superset and then finds that it reports through Scarf by default can switch that reporting off with the SCARF_ANALYTICS setting in superset_config.py. The fix is a configuration change, but it is still a decision that needs an owner, a record and a check after it is made. Scarf is a third-party analytics service, and Superset uses it to collect usage signals. Regulated organizations, and especially air-gapped or tightly egress-filtered networks, usually disable it because any outbound request from a system that holds customer or financial data must be described, justified and monitored. Many teams also want no third-party recipient in their data flow map, even when the request carries no business data. The exact fields sent are something to confirm in the configuration documentation and by observing traffic in your own environment, not something to assume from this page.

Verify the change before you rely on it. Set the key in the configuration file your deployment actually loads, then restart the web and worker processes so the setting takes effect. The configuration documentation for Superset describes how configuration is loaded and which value turns the setting off, so confirm that value for your version. Container images, Helm values and environment variables can each pass configuration differently, so trace the path from your chart or compose file to the running process. Then test in staging: record outbound DNS lookups and connections from the Superset containers or hosts before and after the change, using your firewall or flow logs. Keep the before and after captures with the change ticket as evidence for the reviewer.

Telemetry settings and when each fits

This table compares three ways to control Superset's Scarf reporting: leaving the default, setting SCARF_ANALYTICS in configuration, and enforcing the decision at the network layer. Read each row for when the option fits and what it cannot prove by itself, since a configuration setting and an egress block answer different audit questions.

Option	When it fits	What it does not prove on its own	What to confirm for the installed version
Leave the default in a connected sandbox	Throwaway evaluation instances with no customer, regulated or production data, where the team accepts outbound reporting	Nothing about production readiness, since the instance is not hardened or governed	The default reporting behavior in the release you installed and which hosts it contacts
Set SCARF_ANALYTICS in superset_config.py	Production instances where the team wants the application setting to match its written telemetry decision	That the running process actually read the value, or that no other component sends outbound traffic	The accepted values for SCARF_ANALYTICS in the configuration documentation for your exact version
Enforce the setting with egress blocks for Scarf	Regulated, air-gapped or tightly segmented networks where the security team needs a control independent of application settings	Whether the application configuration is correct, so it works best alongside the configuration setting	The Scarf hostnames your version uses and whether any proxy, image pull or package step depends on them
Combine configuration and egress controls	Environments where an auditor will ask for both the design decision and evidence that traffic is blocked	Full coverage unless the team tests the block from inside the Superset containers and workers	Test results from the web and worker tiers showing blocked connections and a retained configuration record
Verify with a configuration check and test traffic	Any environment, before go-live and after each upgrade	Long-term behavior, since upgrades can change defaults and endpoints	Release notes and UPDATING.md for each upgrade step, and the documented setting names in the current docs

Why regulated and air-gapped deployments usually disable it

Regulated organizations usually turn off Superset's Scarf reporting because every outbound connection from a system that touches regulated data has to appear on an approved destination list. Superset's default telemetry sends requests to an external host that the platform team did not choose, operate or contract for. Security and network teams generally want that destination either blocked at the egress point or explicitly approved with a named owner and a documented business reason. Leaving it on by default makes that approval conversation harder to close before go-live.

Air-gapped networks make the question simpler. A deployment with no route to external services cannot reach the telemetry endpoint at all, so the setting only matters for accuracy of configuration and for the record. The same is true of most restricted networks that allow only package mirrors and internal registries. Before go-live, confirm with your network team which destinations are reachable from the Superset web, worker and beat containers, and confirm that the image build and runtime do not depend on an external host to start.

Change control is where the decision has to be written down. Each outbound path should carry a documented reason, an owner and a review date, and any change to SCARF_ANALYTICS should go through the same ticket and configuration review as other superset_config.py changes. Auditors who test access and logging controls look for evidence that the platform was configured on purpose. A setting alone is weaker evidence than a blocked egress rule, a firewall log showing the request was denied, and a retained configuration record showing the value and who approved it.

How the setting differs by environment

A development or sandbox instance usually has internet access, so the main risk is drift. A sandbox that reports telemetry while production does not, or settings copied from a sandbox into production later, can make results inconsistent and hard to explain to an auditor.

Set the value in shared configuration: Put SCARF_ANALYTICS in the configuration file your team uses for every developer container, not in a shell variable that each person sets by hand. Confirm the accepted values in the configuration documentation.
Record the decision: Some teams keep reporting on a throwaway sandbox. If you allow it, write that choice down so it is explicit and can be reviewed.
Test both states: Start the instance with the setting unset and then set, and observe outbound requests with a local egress log so you know how your build behaves.
Keep production data out: Do not load production dashboards, connection strings or user records into the sandbox to test telemetry.

Check that the value in the sandbox configuration is the same value you plan to promote to production.

In a regulated production environment, security and compliance teams usually own the decision, and the evidence matters as much as the setting. Egress is normally limited to approved destinations, so blocking the telemetry endpoint at the firewall or proxy gives a second control if configuration drifts or a release changes.

Set it in the rendered release configuration: Set SCARF_ANALYTICS in the configuration your deployment pipeline produces, and treat any change to it as a reviewed change.
Block the destination: Deny outbound requests to the Scarf endpoint at the egress proxy or firewall. Confirm the destination with the Scarf documentation and your network team before writing the rule.
Verify at runtime: After every deployment, check the environment of the running containers and the egress logs, not only the source repository.
Check the deployment layer: Helm values, container overrides or operator custom resource fields can replace the setting. The Helm chart is marked deprecated and the Kubernetes operator is alpha, so review the rendered manifests for every release.

Keep the rendered configuration, the egress rule and the post-deployment test output with the change ticket.

An air-gapped network has no outbound path, so telemetry cannot leave the enclave by design. The setting still matters because the first boot must be predictable, and it must be proven in your own environment. Most of the work is in how software reaches the enclave, since images, packages and dependencies are built outside and carried in.

Set it before the first start: Include SCARF_ANALYTICS in the configuration bundle built on the connected side, so the first boot inside the enclave already has the setting.
Carry software through internal mirrors: Images, Python packages and frontend dependencies arrive through your internal repositories. No route is opened for the telemetry endpoint.
Bake the setting into offline bundles: For packaged or PyPI-based installs, place the setting in the configuration file inside the bundle and record the bundle's checksum in the release record.
Watch first-boot logs: Review logs for DNS and connection errors during startup. A failed outbound attempt should not affect reports, dashboards or login, so test those paths after install.

Keep the bundle manifest, the configuration checksum and a first-boot log that shows no outbound attempts.

How to turn off telemetry in a Superset deployment

This sequence confirms the version you run, sets SCARF_ANALYTICS in the configuration your deployment actually loads, and proves the setting is active in every web and worker process. It ends with a change record so the setting survives rebuilds and upgrades.

Confirm the installed Superset version
The platform team records the exact version before changing anything. For PyPI installs, run pip show apache-superset in the environment that serves Superset. For containers, read the image tag from your deployment manifest. Compare the result with the release list on GitHub and the package history on PyPI, and note that 7.0.0rc2 is listed as a pre-release. Done when the version and its source are written in the change ticket.
Locate the configuration file for your method
Identify the file each deployment type loads at startup. For containers, find the configuration file mounted into the image or passed by environment variable. For PyPI installs, find the config module your environment imports, commonly superset_config.py. For Kubernetes, find the configuration block in your Helm values or operator resource. Confirm the file path with your deployment owner. Done when you can name the single file that every web and worker process reads.
Set SCARF_ANALYTICS in configuration
Add the SCARF_ANALYTICS key to that file, using the value that the configuration documentation lists for disabling reporting. Confirm the accepted values in that document for the version you run. Keep the setting in one place so that it does not conflict with other overrides. Done when a diff of the file shows one SCARF_ANALYTICS entry with the documented disabling value.
Restart web and worker processes
Restart every process that loads the configuration, including the web server and, where you run them, Celery workers and beat. Each process reads configuration at startup, so a running process keeps its old value until it restarts. For containers, restart the services or redeploy the image. For Kubernetes, wait for the rollout to finish on each deployment. Done when every web and worker process shows a start time after the configuration change.
Verify the effective setting in running processes
Read the value from inside each running process rather than trusting the file. Open a shell in a web container or pod and run superset shell, then print the SCARF_ANALYTICS value from the loaded application configuration. Repeat the check in a worker process. Then review egress logs or firewall records to confirm that outbound requests to the Scarf endpoint have stopped. Done when every process reports the disabling value and the logs show no new telemetry traffic.
Record the change in version control
Commit the configuration change to the repository that holds your deployment code, with the Superset version, the date, the reviewer and the reason for the change. Make sure the setting is part of the template that builds images or manifests so a rebuild keeps it. Rebuild or render the deployment from the repository in a test environment and repeat the check from the previous step. Done when the commit exists and the rebuilt environment reports the same value.
Confirm the setting after each upgrade
Repeat the verification after every Superset upgrade, because an upgrade can replace images, charts or configuration templates. Follow the upgrade guidance to test in staging first and to review UPDATING.md for breaking changes between versions. Confirm that SCARF_ANALYTICS still loads with the documented value in staging and then in production. Done when the post-upgrade check in each environment reports the disabling value on every process.

Security and operational considerations after the change

Turning off telemetry is a configuration decision, and it only holds if the rest of the platform keeps it in place. The cards below cover where the setting is enforced, how it is changed and reviewed, and how the decision is evidenced to auditors and to the teams that rebuild or upgrade Superset.

Enforce the decision at egress

A configuration flag only binds Superset if nothing else can override it, so network controls are the backstop. Allow list outbound traffic from the Superset web and worker hosts, and deny everything else that is not a documented dependency such as your database, identity provider and SMTP relay. Test the rule from inside the running container, not only from the host, because containers often route through a different network namespace. Record which destinations you permit and why.

Keep configuration under change control

The setting usually lives in superset_config.py or in environment variables that your deployment injects. Store it in version control with the rest of the configuration, require review for changes, and block direct edits on running hosts. A quiet change to the file during a hotfix is the most common way a disabled setting returns to its default without anyone noticing.

Carry the setting into every image

If your pipeline builds Superset images, the opt-out must be part of the build or the runtime configuration baked into each image, not only on the current hosts. Check every image tag your environments deploy, including the ones used for staging, one-off jobs and Celery workers. Workers and the web tier should read the same effective value, so confirm it on each container type rather than assuming one source covers all of them.

Check that upgrades do not reset it

Upgrades replace images and sometimes the configuration templates you started from. Before and after each upgrade, confirm the effective setting in the new release's runtime, and read the upgrade notes for changes to configuration handling. The Superset upgrade guide asks teams to test in staging first, which is the right place to check this. Add the check to your upgrade runbook so it is repeated every time, not remembered once.

Document the decision for auditors

Auditors and security reviewers will ask why an outbound behavior was changed and how you know it stayed changed. Keep a short record that names the setting, the Superset release it was verified on, the egress rule that backs it, the approver and the date. Attach the configuration change and the test result. This record supports your own assessment; it does not replace an independent audit, which only the auditor can issue.

Include it in periodic configuration reviews

Add the setting to the recurring review of your Superset configuration, alongside secret key handling, authentication and export controls. At each review, compare the running effective value with the approved record, and check that the egress rule still matches the documented dependencies. Reviews catch drift from manual changes, restored backups and rebuilt environments that were not built from the approved source.

How to prove telemetry stays off

Turning telemetry off only helps if you can show it stayed off, so treat the setting as a claim to test. Start by reading the effective configuration from running processes, not the file in your repository. Exec into the web and worker containers (or inspect the pods, or the processes on a virtual machine) and confirm that SCARF_ANALYTICS resolves to the disabled value the configuration documentation specifies. Check every tier that loads superset_config.py, including Celery workers and beat, because a setting that only the web tier reads leaves the other tiers reporting. Record the image tag and the configuration file checksum with the output.

Configuration shows intent, but a blocked connection shows behavior. From the Superset host, attempt an outbound HTTPS request to the Scarf domain, using the hostname from the current vendor documentation, and repeat it from each worker host or pod because network policies often differ by workload. The test passes only when the connection fails at the firewall, proxy or DNS layer and the failure appears in your egress logs. Run the test from the production network segment, not from an administrative host with wider access. In an air-gapped network, the expected result is the same, and the lack of any route is itself the evidence. Keep the command, timestamp and full output.

Repeat both checks after every upgrade, image rebuild, Helm or operator change and base image update, since a new image or chart can reset defaults or add configuration files. The upgrade guide asks you to test in staging first, so run the telemetry checks in staging and again in production before sign-off. Store the outputs with the change record and link them to the ticket, so an auditor can see what was tested, when, and against which image. A DeployOpen assessment can prepare this evidence and the controls around it, but it does not issue an audit opinion. Independent auditors or certification bodies make that determination.

Questions teams ask before turning off Superset telemetry

How long does turning off Superset telemetry take?

The setting change itself is small: you set SCARF_ANALYTICS to disabled in the configuration your deployment loads. Most of the elapsed time goes elsewhere. Teams spend it locating every place configuration is supplied, such as a superset_config.py file, container environment variables or Helm values, confirming that no environment override sets the value back, and getting the change through review. The duration depends on how many places configuration lives and how fast your approvals move. Ask for an estimate based on your own environment layout, and check the exact variable behavior for your release in the Superset configuration documentation before you change anything.

Can our own team turn off Superset telemetry without a partner?

Yes, for a single deployment with one clear configuration source. A team that already runs Superset can make the change, verify it in a test environment and document it. A partner becomes useful when several environments, containers or Kubernetes clusters need the same setting, when auditors ask for repeatable evidence, or when the team has no spare capacity for testing and upgrades. Before deciding, confirm three things: that someone on the team can read and change the configuration in every environment, that a restart of the web and worker processes is acceptable in your change window, and that the team has tested Superset configuration changes before.

What do we need from our team before the change?

Your team provides four things:

Read access to the configuration source and the deployment pipeline for each environment.
Permission to change that configuration in development, test, staging and production.
Documented egress rules for the Superset hosts, so you know which outbound paths exist and which proxy or firewall rules apply.
A named change approver and a rollback path that the operations team has tested.

Confirm the egress details with your network team. Blocking outbound traffic at the firewall is a separate control from the Superset setting, and you should record both so the configuration and network evidence match.

Does turning off telemetry affect Superset features?

Disabling telemetry should not change dashboards, charts, datasets, query results or user access, because it only controls usage reporting. Confirm this in your own environment rather than relying on a general statement. Check the features your organization uses that depend on outbound connections, such as email or chat delivery for alerts and reports, and confirm their egress rules separately. Per the Superset architecture documentation, alerts and reports, async queries and dashboard thumbnails depend on the caching layer and worker components, not on this setting. Test those features in staging after the change so any problem is found before production users notice it.

How do environment count and egress controls change the cost?

Cost follows the amount of work in three areas. First, the number of environments (development, test, staging, production and any disaster recovery copy), since each needs the change, verification and records. Second, how configuration is delivered, which can be a single file, container variables, or a Kubernetes deployment managed through pipelines. Third, the egress design, from an air-gapped network with nothing to allow to a proxy with a documented allowlist that must be reviewed. One-time work covers the initial change, verification and evidence. Recurring work covers re-checking the setting after upgrades and when new environments are added. Ask any quote to list each environment, the delivery method, the egress design and the evidence format.

What happens to the telemetry setting at the next Superset upgrade?

The setting lives in configuration, so it can be lost if a new image tag, chart value or configuration template replaces the file that held it. The Superset upgrade documentation asks you to back up the metadata database, run superset db upgrade and superset init, test in staging and check UPDATING.md for breaking changes. Add a check to that plan that confirms the effective setting in the upgraded processes. If you deploy on Kubernetes, note that the current development documentation marks the Helm chart as deprecated and points new deployments to the Superset Kubernetes Operator, which is in alpha, so confirm which method your upgrade path uses before you plan the change.

How do we show auditors that telemetry is off?

Keep the configuration in version control, link each change to an approved ticket, and capture the effective setting from the running processes after each deployment. Pair that with the egress rules that control outbound traffic from the Superset hosts, so the configuration evidence and the network evidence agree. Record the test results from staging and the date of each upgrade check. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Independent auditors decide what evidence satisfies your obligations, so ask them early which artifacts they expect and in what format.

What to confirm in your environment before you rely on the setting

The telemetry setting is only as reliable as the environment it runs in. Each item below is a check you run against your own release, packaging, network and governance process before you record the setting as complete.

Exact behavior in your release

Confirm the telemetry behavior and the setting name in the Superset release you actually run, not in the documentation for a different version. Read the configuration reference for that release and look for the SCARF_ANALYTICS key and its default. Then test on a non-production instance by checking outbound requests from the web container during startup and a few page loads. Record the release number and the result so the check can be repeated after every upgrade.

Packaging method overrides

Find out whether your install method sets the value on its own. A PyPI install, a container image, a custom Dockerfile and a configuration management template can each load superset_config.py in a different order, or set environment variables that take precedence. Confirm which file the running process reads, and check that the variable is not overwritten by a default in the image or the chart values. Do not assume the setting survived a rebuild until you have confirmed it in the built artifact.

Pre-release builds

Pre-release versions such as 7.0.0rc2 can change defaults, configuration keys and telemetry code before a stable release. Do not carry a setting from a stable build into a release candidate without testing it. If your roadmap includes a pre-release, add a step that repeats the outbound request check against that exact build. Track the release notes for any change to the reporting behavior so the setting is reviewed before you upgrade.

Firewall and proxy effects

Blocking the telemetry destination at the firewall or proxy is a separate control from the application setting, and it can affect other services. Confirm that the destination is not required for package installs, container pulls, dependency downloads or certificate checks on your network. Test the block with a full Superset startup, a dashboard load, a query and a scheduled report. Document the rule owner so that a later change to the proxy allowlist does not silently re-enable reporting.

Helm and operator paths

The Helm chart and the Kubernetes Operator may pass environment variables or configuration files differently, and the Operator is in alpha with a v1alpha1 API that can change between releases. Confirm which path your cluster uses and where the setting is declared. Check that the rendered configuration or custom resource contains the value after each deployment. Because the Helm chart is marked deprecated for new deployments, plan how you will verify the setting if you move to the Operator.

Security team evidence format

Agree with your security and compliance team what evidence they accept before you tell them the setting is off. Typical evidence is the configuration file or environment variable as deployed, a dated output from a test in the running container, and the firewall rule with its change record. Ask whether they want the check repeated after each upgrade and who signs it off. DeployOpen can prepare the evidence, but the acceptance decision belongs to your assessors and internal reviewers.

How DeployOpen scopes and delivers a telemetry opt-out

DeployOpen treats the telemetry opt-out as a small, documented change to a Superset deployment that you control. We confirm the current telemetry behavior in your version, set the SCARF_ANALYTICS setting in your own configuration, and verify that no outbound reporting remains in your network path.

How we scope

Confirm which Superset version and install method (container, PyPI or Helm-based) your deployment runs before changing anything.
Record where configuration is set today, including environment variables, config files and image build steps.
Agree in writing whether the scope includes network egress verification and documentation for your change record.

How we build

Set the telemetry opt-out in the configuration source your team already uses, so it survives image rebuilds and redeploys.
Test the change in a staging environment first, then confirm the running instance makes no calls to the Scarf endpoint.
Keep the change in version control with a short note explaining the setting, the version tested and the reason for it.

How we hand over

Deliver a written runbook covering the setting, where it lives, how to verify it and what to recheck after an upgrade.
Walk your platform and security teams through the verification steps and the evidence captured during testing.
Document how the opt-out interacts with your upgrade procedure, so it is reviewed against the release notes each time.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer if you want the setting rechecked with each release.
Scope any future Superset upgrade separately, since new versions can change configuration and telemetry behavior.
Ask us to include the opt-out in your broader hardening and egress review when those workstreams run together.