Skip to main content
Noxus configuration is split between:
  • runtime env vars (URLs, deployment mode, non-sensitive settings)
  • secrets (credentials and keys)
  • admin-managed platform settings (global configuration in the Noxus admin portal)

Configuration Sources

Environment Variable Layers

Environment Variable Reference

Platform

URLs

Database Configuration

Redis

Object Storage

Observability

Worker Configuration (per deployment)

Agent Sandbox & Plugins

LOCAL_SANDBOX_BACKEND=subprocess runs user code in the Worker’s own process tree — with its filesystem, network, and environment, including database credentials. Do not use it in a multi-tenant deployment.
See Agent Sandbox for the deployment model and platform compatibility.

Deployment-Independent Principles

  • Keep non-sensitive settings in environment config
  • Keep credentials in secrets only
  • Keep environment names simple (local, staging, prod)
  • Do not expose internal-only controls (such as billing internals) in user-facing docs
Noxus supports extensive runtime configuration from the admin portal when the user has global admin permissions. This includes global server settings and auth behavior.

Practical Mapping In Your Stack

  • VM compose: env_file and explicit env mounts
  • Helm: env, extraEnv, secrets, plus service-specific secret variants
  • Terraform stage3: secret/env materialization and namespace-scoped injection

Secrets

Secret handling, provider credentials, and worker secret injection

Workers

Worker pools, task routing, workspace isolation, and autoscaling

Agent Sandbox

Isolated code execution, required for plugins

Storage

Object storage, vector databases, and caching layers

Architecture

PostgreSQL and pgvector requirements, and the runtime topology