Configuration¶

This guide covers the full configuration reference for the Superset operator. For installation instructions, see Installation. For lifecycle (migrations, upgrades), see Lifecycle.

Environment Mode¶

The environment field controls validation strictness (enforced by CEL rules in the CRD schema):

Production (default) — inline secretKey, metastore.uri, metastore.password, and valkey.password are rejected by CRD validation. Use secretKeyFrom, metastore.uriFrom, metastore.passwordFrom, or valkey.passwordFrom to reference Kubernetes Secrets.
Staging — same secret restrictions as Production, but allows lifecycle.clone for database cloning from an external source.
Development — allows plain-text secretKey, metastore.uri, metastore.password, and valkey.password directly in the CR for quick local development. Also permits lifecycle.clone, lifecycle.init.adminUser, and lifecycle.init.loadExamples.

Dev Mode Example¶

spec:
  environment: Development
  secretKey: thisIsNotSecure_changeInProduction!
  metastore:
    uri: postgresql+psycopg2://superset:superset@postgres:5432/superset
  config: |
    FEATURE_FLAGS = {"ENABLE_TEMPLATE_PROCESSING": True}
  webServer: {}
  lifecycle:
    init:
      adminUser: {}
      loadExamples: true

Prod Mode Example¶

Use secretKeyFrom and metastore.uriFrom to reference Kubernetes Secrets. The operator injects the corresponding env vars with valueFrom.secretKeyRef:

spec:
  image:
    tag: "6.0.1"
  secretKeyFrom:
    name: superset-secret
    key: secret-key
  metastore:
    uriFrom:
      name: db-credentials
      key: connection-string
  config: |
    FEATURE_FLAGS = {"DASHBOARD_RBAC": True, "ALERT_REPORTS": True}
    ROW_LIMIT = 10000
  webServer: {}

Metastore¶

The metastore field provides database connection configuration. There are two modes:

Passthrough URI — provide the full SQLAlchemy connection string. In dev mode, use uri inline. In prod mode, use uriFrom to reference a Kubernetes Secret:

# Dev mode: inline URI
spec:
  environment: Development
  metastore:
    uri: postgresql+psycopg2://superset:superset@postgres:5432/superset

# Prod mode: URI from Secret
spec:
  metastore:
    uriFrom:
      name: db-credentials
      key: connection-string

uri and uriFrom are mutually exclusive with each other and with the structured fields below.

Structured fields — the operator sets individual env vars (SUPERSET_OPERATOR__DB_HOST, SUPERSET_OPERATOR__DB_PORT, SUPERSET_OPERATOR__DB_NAME, SUPERSET_OPERATOR__DB_USER, SUPERSET_OPERATOR__DB_PASS) that the generated config assembles into a connection URI. In prod mode, use passwordFrom to reference a Secret for the password:

# Dev mode: inline password
spec:
  environment: Development
  metastore:
    type: PostgreSQL
    host: db.example.com
    port: 5432
    database: superset
    username: superset
    password: secret

# Prod mode: password from Secret
spec:
  metastore:
    type: PostgreSQL
    host: db.example.com
    port: 5432
    database: superset
    username: superset
    passwordFrom:
      name: db-credentials
      key: password

password and passwordFrom are mutually exclusive.

Valkey¶

The valkey field configures Valkey (or Redis) as the cache backend, Celery message broker, and SQL Lab results backend. Setting valkey.host auto-generates all cache, Celery, and results backend configuration with sensible defaults:

# Minimal: one field configures everything
spec:
  valkey:
    host: valkey.default.svc

This generates a complete superset_config.py with CACHE_CONFIG, DATA_CACHE_CONFIG, FILTER_STATE_CACHE_CONFIG, EXPLORE_FORM_DATA_CACHE_CONFIG, THUMBNAIL_CACHE_CONFIG, CeleryConfig, and RESULTS_BACKEND — each cache section backed by a separate Valkey database for isolation (Celery broker and result backend share database 0 by default).

Default database assignments:

Section	Superset Config Key	Valkey DB	Key Prefix	Timeout
`cache`	`CACHE_CONFIG`	1	`superset_`	300s
`dataCache`	`DATA_CACHE_CONFIG`	2	`superset_data_`	86400s
`filterStateCache`	`FILTER_STATE_CACHE_CONFIG`	3	`superset_filter_`	3600s
`exploreFormDataCache`	`EXPLORE_FORM_DATA_CACHE_CONFIG`	4	`superset_explore_`	3600s
`thumbnailCache`	`THUMBNAIL_CACHE_CONFIG`	5	`superset_thumbnail_`	3600s
`celeryBroker`	`CeleryConfig.broker_url`	0	—	—
`celeryResultBackend`	`CeleryConfig.result_backend`	0	—	—
`resultsBackend`	`RESULTS_BACKEND`	6	`superset_results_`	—

Each section can be individually tuned or disabled:

spec:
  valkey:
    host: valkey.default.svc
    port: 6380
    passwordFrom:
      name: valkey-credentials
      key: password
    cache:
      defaultTimeout: 600
    dataCache:
      database: 10
      defaultTimeout: 43200
    filterStateCache:
      disabled: true    # fall back to Superset's built-in default
    celeryBroker:
      database: 14
    celeryResultBackend:
      database: 15

In dev mode, valkey.password can be set inline. In prod mode (default), use valkey.passwordFrom to reference a Kubernetes Secret — the operator injects the password via valueFrom.secretKeyRef.

SSL/TLS¶

Enable SSL by setting the ssl field. For simple SSL (encrypted connection, no client certificates), set ssl: {}. For mTLS, provide certificate file paths:

spec:
  valkey:
    host: valkey.default.svc
    passwordFrom:
      name: valkey-credentials
      key: password
    ssl:
      certRequired: required   # "required" (default), "optional", or "none"
      keyFile: /mnt/tls/client.key.pem
      certFile: /mnt/tls/client.crt.pem
      caCertFile: /mnt/tls/ca.pem

Mount the certificate files via the top-level podTemplate so they are available to all components:

spec:
  podTemplate:
    volumes:
      - name: valkey-tls
        secret:
          secretName: valkey-tls-certs
    container:
      volumeMounts:
        - name: valkey-tls
          mountPath: /mnt/tls
          readOnly: true
  valkey:
    host: valkey.default.svc
    ssl:
      keyFile: /mnt/tls/tls.key
      certFile: /mnt/tls/tls.crt
      caCertFile: /mnt/tls/ca.crt

Reserved Environment Variables¶

The operator sets certain env vars automatically based on the CR spec. These are organized into tiers:

Env Var	Tier	Set by	Description
`SUPERSET_OPERATOR__SECRET_KEY`	Operator-internal	Operator (from `secretKey` or `secretKeyFrom`)	Superset session signing key
`SUPERSET_OPERATOR__DB_URI`	Operator-internal	Operator (from `metastore.uri` or `metastore.uriFrom`)	Full database connection URI
`SUPERSET_OPERATOR__DB_HOST`, `SUPERSET_OPERATOR__DB_PORT`, `SUPERSET_OPERATOR__DB_NAME`	Operator-internal	Operator (structured metastore)	Database connection fields
`SUPERSET_OPERATOR__DB_USER`, `SUPERSET_OPERATOR__DB_PASS`	Operator-internal	Operator (from metastore structured fields or `passwordFrom`)	Database credentials
`SUPERSET_OPERATOR__VALKEY_HOST`, `SUPERSET_OPERATOR__VALKEY_PORT`	Operator-internal	Operator (from `valkey`)	Valkey connection fields
`SUPERSET_OPERATOR__VALKEY_PASS`	Operator-internal	Operator (from `valkey.password` or `valkey.passwordFrom`)	Valkey password
`SUPERSET_OPERATOR__FORCE_RELOAD`	Operator-internal	Operator (from `spec.forceReload`)	Triggers rolling restart
`PYTHONPATH`	Standard	Operator	Python module search path
`SUPERSET_WEBSERVER_PORT`	Standard	Rendered in config	Web server port (8088)

Tier descriptions:

Operator-internal transport vars (SUPERSET_OPERATOR__ prefix) are used by the operator to pass values into the rendered superset_config.py. They are not recognized by Superset directly — the operator renders them as Python assignments (e.g., SECRET_KEY = os.environ['SUPERSET_OPERATOR__SECRET_KEY']).
Standard env vars have no special prefix.

Which env vars are set per metastore mode:

Env Var	`metastore.uri`	`metastore.uriFrom`	Structured (`host`, ...)
`SUPERSET_OPERATOR__DB_URI`	Set (plain text)	Set (`valueFrom`)	—
`SUPERSET_OPERATOR__DB_HOST`	—	—	Set
`SUPERSET_OPERATOR__DB_PORT`	—	—	Set
`SUPERSET_OPERATOR__DB_NAME`	—	—	Set (if `database` provided)
`SUPERSET_OPERATOR__DB_USER`	—	—	Set (if `username` provided)
`SUPERSET_OPERATOR__DB_PASS`	—	—	Set (plain text or `valueFrom`)

In both passthrough and structured modes, the operator renders SQLALCHEMY_DATABASE_URI in superset_config.py from the operator-internal env vars. Passthrough mode reads from SUPERSET_OPERATOR__DB_URI, while structured mode assembles an f-string URI from the SUPERSET_OPERATOR__DB_* env vars.

Which env vars are set when valkey is configured:

Env Var	Set when
`SUPERSET_OPERATOR__VALKEY_HOST`	Always (from `valkey.host`)
`SUPERSET_OPERATOR__VALKEY_PORT`	Always (from `valkey.port`, default 6379)
`SUPERSET_OPERATOR__VALKEY_PASS`	`valkey.password` (dev, plain text) or `valkey.passwordFrom` (prod, `valueFrom`)

Custom Python Config¶

The config field accepts raw Python that is appended after the operator-generated config. It is available at the top level (base config, shared by all Python components) and per component (component config):

spec:
  # Base config: appended to ALL Python components
  config: |
    FEATURE_FLAGS = {"ENABLE_TEMPLATE_PROCESSING": True}
    ROW_LIMIT = 10000

  # Component config: appended after base config for this component only
  celeryWorker:
    config: |
      CELERY_ANNOTATIONS = {"tasks.add": {"rate_limit": "10/s"}}

Both fields are concatenated, not mutually exclusive. In this example, the celery worker's superset_config.py contains the operator-generated configs (SECRET_KEY, structured DB URI if applicable), then the base config (FEATURE_FLAGS, ROW_LIMIT), then the component config (CELERY_ANNOTATIONS). The web server receives only the operator-generated configs and the base config, since it has no component-specific config field set.

See Config Rendering Pipeline for the full rendering order and an example of the generated output.

Celery Configuration¶

Enable Celery workers for background tasks (caching, scheduled reports, long-running queries) by setting celeryWorker and celeryBeat. When spec.valkey is configured, the Celery broker and result backend are auto-generated. Otherwise, provide Celery config manually via config:

# With valkey (recommended): Celery config auto-generated
spec:
  valkey:
    host: valkey.default.svc
  celeryWorker: {}
  celeryBeat: {}

# Without valkey: manual Celery config
spec:
  config: |
    class CeleryConfig:
        broker_url = "redis://valkey:6379/0"
        result_backend = "redis://valkey:6379/1"
    CELERY_CONFIG = CeleryConfig
  celeryWorker: {}
  celeryBeat: {}

Gunicorn Configuration¶

The operator manages Gunicorn worker parameters for the web server by injecting environment variables that Superset's run-server.sh reads. By default, even without an explicit gunicorn field, the operator injects balanced defaults (2 workers, 8 threads, gthread worker class).

Presets control workers, threads, and workerClass. All other fields have static defaults that you can override individually.

Field	conservative	balanced (default)	performance	aggressive
workers	1	2	4	8
threads	4	8	8	16
workerClass	gthread	gthread	gthread	gthread

Set preset: disabled to suppress env var injection entirely — Superset's run-server.sh built-in defaults will apply instead.

spec:
  webServer:
    gunicorn:
      preset: performance      # 4 workers, 8 threads
      timeout: 120             # override static default (60)
      maxRequests: 1000        # enable worker recycling
      maxRequestsJitter: 50

The full set of configurable fields (static defaults in parentheses): timeout (60), keepAlive (2), maxRequests (0 = disabled), maxRequestsJitter (0), limitRequestLine (0 = unlimited), limitRequestFieldSize (0 = unlimited), logLevel (info).

Celery Worker Configuration¶

The operator constructs the celery worker command from structured fields instead of the hardcoded default. Presets control concurrency and pool type:

Field	conservative	balanced (default)	performance	aggressive
concurrency	2	4	8	16
pool	prefork	prefork	prefork	prefork

Set preset: disabled to use the operator's built-in fallback command (--pool=prefork -O fair -c 4).

spec:
  celeryWorker:
    celery:
      preset: performance        # 8 concurrency, prefork
      maxTasksPerChild: 1000     # recycle workers after 1000 tasks
      softTimeLimit: 3600        # 1h soft limit (raises SoftTimeLimitExceeded)
      timeLimit: 7200            # 2h hard kill

Additional fields (static defaults in parentheses): optimization (fair), maxTasksPerChild (0 = unlimited), maxMemoryPerChild (0 = disabled), prefetchMultiplier (4), softTimeLimit (0 = disabled), timeLimit (0 = disabled).

SQLAlchemy Engine Options¶

The operator renders SQLALCHEMY_ENGINE_OPTIONS in each component's superset_config.py, with pool sizing computed from the component's execution model. By default (balanced preset), all components get sensible pool settings without any explicit configuration.

Presets control poolClass, poolSize, and maxOverflow:

Preset	Pool class	pool_size	max_overflow
disabled	(no rendering)	—	—
conservative	NullPool	—	—
balanced (default)	QueuePool	1 (web/celery/flower), 5 (MCP)	-1 (unlimited)
performance	QueuePool	workers (web), concurrency (celery), 1 (flower), 10 (MCP)	-1
aggressive	QueuePool	workers × threads (web), concurrency (celery), 1 (flower), 20 (MCP)	-1

CeleryBeat and lifecycle tasks always use NullPool regardless of preset (singleton/short-lived components with minimal DB interaction). CeleryFlower uses standard pool sizing (defaults to 1 for performance/aggressive since it has no worker configuration).

spec.sqlaEngineOptions sets the baseline for all Python components. Per-component sqlaEngineOptions on webServer, celeryWorker, celeryBeat, mcpServer, or init replaces the top-level entirely (override semantics, not merge).

spec:
  sqlaEngineOptions:
    preset: balanced             # applies to all components
    poolRecycle: 1800            # override static default (3600)
  webServer:
    gunicorn:
      preset: performance        # 4 workers, 8 threads
    sqlaEngineOptions:
      preset: performance        # pool_size=4 (gunicorn workers)
  celeryWorker:
    celery:
      concurrency: 12
    sqlaEngineOptions:
      preset: aggressive         # pool_size=12 (celery concurrency)
  celeryBeat: {}                 # always NullPool

Static defaults (same regardless of preset, overridable per-field): poolRecycle (3600), poolPrePing (false), poolTimeout (omitted — SQLAlchemy default 30s).

Individual field overrides take precedence over the preset computation:

spec:
  sqlaEngineOptions:
    preset: balanced
    poolSize: 10                 # explicit: overrides preset calculation
    poolPrePing: true            # explicit: overrides static default

Websocket Server¶

Enable Superset's async event streaming by setting websocketServer. This deploys a Node.js application (not Python) that pushes real-time updates to dashboards via WebSocket connections.

Requires a dedicated image

The websocket server is a separate Node.js application and does not run from the default Superset image. You must provide an image that contains websocket_server.js. A community-maintained image is available at oneacrefund/superset-websocket (experimental, not officially supported by Apache Superset).

spec:
  websocketServer:
    image:
      repository: oneacrefund/superset-websocket
      tag: "latest"

Because the websocket server is Node.js-based, it does not receive a superset_config.py, and the config / sqlaEngineOptions fields are not available on this component. Configuration is handled via environment variables on the container template:

spec:
  websocketServer:
    image:
      repository: oneacrefund/superset-websocket
      tag: "latest"
    podTemplate:
      container:
        env:
          - name: SUPERSET_WEBSERVER_URL
            value: "http://my-superset-web-server:8088"

The websocket server creates a Service (default port 8080) and supports the same scaling, deployment template, and pod template fields as other scalable components.

MCP Server¶

Enable the Model Context Protocol server by setting mcpServer. This deploys a Python-based FastMCP server that exposes Superset's API via MCP, allowing AI assistants and LLM-based tools to interact with Superset:

spec:
  mcpServer: {}

The MCP server receives a superset_config.py with core config (SECRET_KEY, structured DB URI if applicable) and top-level/per-component config — but not web server port. It runs as a separate Deployment with its own Service (port 8088). The MCP server supports per-component sqlaEngineOptions with higher default pool sizes than other components (5 for balanced, 10 for performance, 20 for aggressive) to accommodate concurrent tool invocations.

Health Probes¶

spec:
  webServer:
    podTemplate:
      container:
        livenessProbe:
          httpGet:
            path: /health
            port: 8088
          initialDelaySeconds: 15
          periodSeconds: 15
        readinessProbe:
          httpGet:
            path: /health
            port: 8088
          initialDelaySeconds: 15
          periodSeconds: 15

Security Context¶

Security context can be set at the top level (shared by all components) or overridden per component:

spec:
  podTemplate:
    podSecurityContext:
      runAsUser: 1000
      runAsNonRoot: true
      fsGroup: 1000
    container:
      securityContext:
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false

Or override per component (replaces the top-level value):

spec:
  webServer:
    podTemplate:
      podSecurityContext:
        runAsUser: 1000
        runAsNonRoot: true

Autoscaling (HPA)¶

spec:
  webServer:
    autoscaling:
      minReplicas: 2
      maxReplicas: 10
      metrics:
        - type: Resource
          resource:
            name: cpu
            target:
              type: Utilization
              averageUtilization: 75

When HPA is configured, the replicas field is ignored (HPA manages scaling).

Pod Disruption Budget¶

spec:
  webServer:
    podDisruptionBudget:
      minAvailable: 1

Component Enable/Disable¶

All components follow the same rule: presence = enabled, absence = disabled. Set a component's spec to enable it (use {} for defaults), omit it or set to null to disable:

spec:
  webServer:
    replicas: 2          # enabled with 2 replicas
  celeryWorker:
    replicas: 3          # enabled with 3 replicas
  celeryBeat: {}         # enabled with defaults
  celeryFlower: {}       # enabled with defaults
  websocketServer: null  # disabled (or omit entirely)
  mcpServer: {}          # enabled with defaults

A Superset CR with no components enabled is valid — the operator will run initialization (if not disabled) but deploy no workloads. The parent status will report Phase: Running with condition reason NoComponentsEnabled.

Child CR and Sub-Resource Names¶

Component child CRs share the parent's name (differentiated by Kind). For example, a parent named my-superset creates SupersetWebServer/my-superset, SupersetCeleryWorker/my-superset, etc. Lifecycle task CRs are named {parentName}-migrate and {parentName}-init (e.g. SupersetLifecycleTask/my-superset-migrate, SupersetLifecycleTask/my-superset-init). Sub-resources (Deployments, Services, ConfigMaps) are named {parentName}-{componentType} (e.g. my-superset-web-server).

The parent name must be a valid DNS label: lowercase alphanumeric and hyphens only (^[a-z0-9]([-a-z0-9]*[a-z0-9])?$), at most 63 characters. Since sub-resource names append a component suffix, the parent name is further constrained by the longest enabled component's suffix. The longest suffix is -websocket-server (17 characters), so parent names must be at most 46 characters when websocket-server is enabled. CRD validation enforces the appropriate limit for each enabled component.

Deployment Template¶

The deploymentTemplate and podTemplate fields configure the Kubernetes Deployment and Pod for each component. They mirror the Kubernetes hierarchy as siblings:

deploymentTemplate                  → DeploymentSpec-level
podTemplate                         → PodSpec-level
└── container                       → main container

Three usage patterns¶

1. Omit entirely — use operator defaults (most users start here):

spec:
  image:
    tag: "6.0.1"
  webServer:
    replicas: 2

2. Set top-level defaults — apply to all components:

spec:
  deploymentTemplate:
    revisionHistoryLimit: 3
  podTemplate:
    terminationGracePeriodSeconds: 60
    nodeSelector:
      workload: superset
    container:
      resources:
        limits:
          cpu: "2"
          memory: "4Gi"
      env:
        - name: LOG_LEVEL
          value: INFO

  webServer:
    replicas: 2
  celeryWorker:
    replicas: 4

All components inherit the deployment template, pod template (node selector, termination grace period), and container template (resources, env vars).

3. Per-component customization — field-level merge with top-level:

spec:
  deploymentTemplate:
    revisionHistoryLimit: 3
  podTemplate:
    container:
      resources:
        limits:
          cpu: "2"
          memory: "4Gi"
      env:
        - name: LOG_LEVEL
          value: INFO

  webServer:
    replicas: 2
    deploymentTemplate:
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
    podTemplate:
      container:
        resources:
          limits:
            cpu: "4"             # replaces entire resources struct
            memory: "8Gi"
        command: ["gunicorn"]
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 15"]

  celeryWorker:
    replicas: 8
    podTemplate:
      container:
        env:
          - name: CELERY_CONCURRENCY
            value: "8"           # merged with top-level LOG_LEVEL env var

Merge semantics¶

Per-component deploymentTemplate and podTemplate are each field-level merged independently with the top-level — you only specify what's different.

Behavior	Fields
Component wins if set	`resources` (both pod-level and container-level), `affinity`, `securityContext`, `podSecurityContext`, `priorityClassName`, `strategy`, `revisionHistoryLimit`, probes, `lifecycle`, `dnsPolicy`, `dnsConfig`, `runtimeClassName`, `shareProcessNamespace`, `enableServiceLinks`, `terminationGracePeriodSeconds`, `minReadySeconds`, `progressDeadlineSeconds`
Merge by name	`env`, `volumes`, `volumeMounts`, `sidecars`, `initContainers`
Merge by key	`annotations`, `labels`, `nodeSelector`, `hostAliases` (by IP)
Append	`tolerations`, `topologySpreadConstraints`, `envFrom`
No inheritance	`command`, `args` (component-only, not inherited from top-level)

Note on append fields: tolerations, topologySpreadConstraints, and envFrom are concatenated (top-level first, then component-level) without deduplication. To avoid duplicates in the final pod spec, define each entry at one level only — typically top-level for shared entries and component-level for component-specific ones.

Available fields¶

Deployment level (deploymentTemplate.*):

Field	Description
`revisionHistoryLimit`	Old ReplicaSets to retain for rollback
`minReadySeconds`	Seconds before a pod is considered available
`progressDeadlineSeconds`	Seconds before a rollout is considered failed
`strategy`	Update strategy (RollingUpdate or Recreate)

Pod level (podTemplate.*):

Field	Description
`annotations`	Pod annotations (merged with operator-managed annotations)
`labels`	Pod labels (merged; operator labels cannot be overridden)
`affinity`	Pod/node affinity and anti-affinity
`tolerations`	Node tolerations (appended)
`nodeSelector`	Node label selector (merged by key)
`topologySpreadConstraints`	Topology spread constraints (appended)
`hostAliases`	/etc/hosts entries (merged by IP)
`podSecurityContext`	Pod-level security context
`priorityClassName`	Pod priority class
`volumes`	Volumes (merged by name with operator-injected volumes)
`sidecars`	Sidecar containers (merged by name)
`initContainers`	Init containers (merged by name)
`terminationGracePeriodSeconds`	Grace period for pod shutdown
`dnsPolicy`	DNS resolution policy
`dnsConfig`	Custom DNS configuration
`runtimeClassName`	RuntimeClass (e.g., gVisor, Kata)
`shareProcessNamespace`	Share PID namespace between containers
`enableServiceLinks`	Inject service environment variables
`resources`	Pod-level resource requirements (Kubernetes 1.34+, requires PodLevelResources feature gate)

Container level (podTemplate.container.*):

Field	Description
`resources`	CPU/memory requests and limits
`env`	Environment variables (merged by name)
`envFrom`	ConfigMap/Secret env sources (appended)
`volumeMounts`	Volume mounts (merged by name)
`securityContext`	Container-level security context
`command`	Container entrypoint (no inheritance)
`args`	Container arguments (no inheritance)
`livenessProbe`	Liveness probe
`readinessProbe`	Readiness probe
`startupProbe`	Startup probe
`lifecycle`	preStop/postStart lifecycle hooks

Pod-level resources (Kubernetes 1.34+): When podTemplate.resources is set, it defines the total resource budget for the entire pod, enabling resource sharing among containers (main + sidecars). Container-level podTemplate.container.resources remains available for per-container limits.

spec:
  podTemplate:
    resources:
      requests:
        cpu: "4"
        memory: "8Gi"
      limits:
        cpu: "8"
        memory: "16Gi"
    container:
      resources:
        requests:
          cpu: "2"
          memory: "4Gi"

Force Reload¶

Trigger a rolling restart of all components:

spec:
  forceReload: "2026-03-14T12:00:00Z"

Change the value to any new string to trigger a restart. This is primarily useful for secret rotation: when you update a Kubernetes Secret's data, pods don't automatically restart because the operator references secrets via valueFrom.secretKeyRef (resolved at pod creation time). Changing forceReload forces new pods that pick up the updated secret values.

Suspend Reconciliation¶

Temporarily pause reconciliation without deleting resources:

spec:
  suspend: true

When suspended, the operator stops all reconciliation — no init pods run, no child CRs are created or updated, and no resources are deleted. Set suspend: false (or remove the field) to resume.

Connecting PostgreSQL and Valkey¶

The operator does not manage database or cache infrastructure. Use one of these approaches:

Managed Services¶

Set connection details via secretKeyFrom, metastore.uriFrom, and valkey:

spec:
  secretKeyFrom:
    name: superset-secrets
    key: secret-key
  metastore:
    uriFrom:
      name: superset-db
      key: uri
  valkey:
    host: valkey.default.svc
    passwordFrom:
      name: valkey-credentials
      key: password

CloudNativePG¶

Use CloudNativePG for PostgreSQL:

# CloudNativePG Cluster (separate CR)
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: superset-pg
spec:
  instances: 3
  storage:
    size: 10Gi

Then reference the connection secret via metastore.uriFrom on your Superset CR.

Redis Operator¶

Use the Redis Operator or Bitnami Redis Helm chart for Redis or Valkey, and configure the connection via valkey.