Skip to main content
Secret management in Noxus is designed to separate platform-level infrastructure credentials from workspace-specific runtime secrets.

​
What Belongs In Secrets

  • Infrastructure: Database and Redis credentials, storage access keys.
  • Identity: Auth provider (OIDC/SAML) client secrets and signing keys.
  • AI Providers: Global API keys for model providers (OpenAI, Anthropic, etc.).
  • Integrations: Credentials for third-party tools used across the platform.

​
Secret Reference

​
Database

SecretDescription
POSTGRESQL_URLPrimary PostgreSQL connection string (user:password@host:5432)
VECTOR_POSTGRESQL_URLVector database (pgvector) connection string

​
Redis

SecretDescription
REDIS_URLRedis host (without port)
REDIS_PASSWORDRedis authentication password
REDIS_USERRedis username (optional, for ACL-based auth)

​
Object Storage

SecretDescription
S3_ACCESS_KEY_IDS3-compatible storage access key
S3_SECRET_ACCESS_KEYS3-compatible storage secret key

​
Observability

SecretDescription
PROM_REMOTE_WRITE_USERNAMEPrometheus remote write basic auth username
PROM_REMOTE_WRITE_PASSWORDPrometheus remote write basic auth password

​
Integrations

SecretDescription
PLUGIN_SERVER_API_KEYPlugin server authentication key
PLUGIN_SERVER_PLATFORM_KEYPlugin server platform-level key

​
Common Secret Backends

Noxus supports several backends for storing and injecting secrets depending on your deployment model.
Native Secrets & External Secret Operators - Store values in Kubernetes Secrets within the relevant namespaces. - Inject via envFrom for all services or explicit secretKeyRef for specific containers. - Support for External Secrets Operator to sync from AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault.

​
Secret Injection Strategies

Noxus allows for granular control over where secrets are exposed within the platform architecture.

​
Global Platform Secrets

These are injected into all services (Frontend, Backend, Workers).
  • Use Case: Database connection strings, Redis URLs, and core authentication secrets.
  • Implementation: Defined in the primary Helm values or the main /env.vm file.

​
Worker-Only Secrets

Inject secrets exclusively into the Noxus Workers.
  • Use Case: Proprietary API keys for custom nodes, database strings for specific ETL flows, or credentials for internal tools.
  • Benefit: Limits the “blast radius” by ensuring the web-facing frontend and backend never have access to these sensitive runtime credentials.

​
Pool-Specific Secrets (Kubernetes)

For advanced isolation, secrets can be injected into specific worker pools using envSecretRef.
  • Use Case: A tenant-dedicated worker pool that needs its own LLM API keys, while the shared pool uses the platform defaults.
  • Implementation: Set worker.pools[<name>].envSecretRef in Helm values to the name of an additional K8s Secret. It is mounted after the shared secret, so its values override any overlapping keys.
See the Workers configuration guide for detailed examples.
Secrets injected into the worker environment are accessible from within the platform itself. Any workflow node, agent tool, or custom plugin running on a worker can read environment variables using the {{secret.MY_SECRET_NAME}} syntax in node configuration fields. This means you can add custom secrets (e.g., a third-party API key) to a worker’s environment and reference them directly from flows and agents without hardcoding credentials in the UI. When using pool-specific secrets via envSecretRef, only workers in that pool will have access to those values — other pools and services will not see them.

​
Rotation & Security Guidelines

  • Regular Rotation: Rotate high-risk credentials (like API keys) on a 30-90 day schedule.
  • Least Privilege: Only inject secrets into the specific services or worker pools that require them.
  • Automated Reloads: In Kubernetes, use tools like reloader to automatically restart pods when their underlying secrets are updated.

Kubernetes Guide

Learn how to configure pool-specific secrets in K8s.

Security Architecture

Understand the broader security context of the platform.