> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noxus.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Secrets

> Secret management for Noxus services, model providers, and worker execution

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

| Secret                  | Description                                                      |
| ----------------------- | ---------------------------------------------------------------- |
| `POSTGRESQL_URL`        | Primary PostgreSQL connection string (`user:password@host:5432`) |
| `VECTOR_POSTGRESQL_URL` | Vector database (pgvector) connection string                     |

### Redis

| Secret           | Description                                   |
| ---------------- | --------------------------------------------- |
| `REDIS_URL`      | Redis host (without port)                     |
| `REDIS_PASSWORD` | Redis authentication password                 |
| `REDIS_USER`     | Redis username (optional, for ACL-based auth) |

### Object Storage

| Secret                 | Description                      |
| ---------------------- | -------------------------------- |
| `S3_ACCESS_KEY_ID`     | S3-compatible storage access key |
| `S3_SECRET_ACCESS_KEY` | S3-compatible storage secret key |

### Observability

| Secret                       | Description                                 |
| ---------------------------- | ------------------------------------------- |
| `PROM_REMOTE_WRITE_USERNAME` | Prometheus remote write basic auth username |
| `PROM_REMOTE_WRITE_PASSWORD` | Prometheus remote write basic auth password |

### Integrations

| Secret                       | Description                      |
| ---------------------------- | -------------------------------- |
| `PLUGIN_SERVER_API_KEY`      | Plugin server authentication key |
| `PLUGIN_SERVER_PLATFORM_KEY` | Plugin server platform-level key |

***

## Common Secret Backends

Noxus supports several backends for storing and injecting secrets depending on your deployment model.

<Tabs>
  <Tab title="Kubernetes & OpenShift">
    **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.
  </Tab>

  <Tab title="Cloud Native">
    **Managed Secret Managers** - **AWS Secrets Manager / Parameter Store**:
    Inject via IAM roles for service accounts (IRSA). - **GCP Secret Manager**:
    Access via Workload Identity and direct environment binding. - **Azure Key
    Vault**: Integration via Managed Identities and CSI drivers.
  </Tab>

  <Tab title="VM / On-Premises">
    **Encrypted Files & Environment** - Use protected `.env` or `/env.vm` files
    with `0600` filesystem permissions. - Support for **HashiCorp Vault** as a
    centralized sidecar or initialization agent. - Systemd-level environment
    protection for the `noxus` service.
  </Tab>
</Tabs>

***

## 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](/deployment/configuration/workers#per-pool-secrets) for detailed examples.

<Note>
  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.
</Note>

***

## 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.

<CardGroup cols={2}>
  <Card title="Kubernetes Guide" icon="square-stack" href="/deployment/kubernetes/overview">
    Learn how to configure pool-specific secrets in K8s.
  </Card>

  <Card title="Security Architecture" icon="shield-check" href="/core/infrastructure/security">
    Understand the broader security context of the platform.
  </Card>
</CardGroup>