Skip to main content

​
Permission denied writing to disc

Some phoenix containers run as nonroot and therefore must be granted explicit write permissions to the mounted disc (see https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). Phoenix 4.1.3 and above run as root by default to avoid this. However there are debug and nonroot variants of the image as well.
Set PHOENIX_ALLOW_EXTERNAL_RESOURCES to false so Phoenix makes no public-internet requests of its own. This turns off Google Fonts, telemetry, PXI’s documentation lookups and web and GitHub access, the WebAssembly sandbox runtime download, and the web interface’s GitHub star count and update check. Without it, blocked requests can delay UI loading by 10-20 seconds. Services you configure yourself, such as LLM providers and hosted sandboxes, aren’t affected. To use the WebAssembly sandbox offline, set PHOENIX_WASM_BINARY_PATH to a local copy of the runtime.Docker Example:
Environment Variable:
The PHOENIX_ALLOW_EXTERNAL_RESOURCES environment variable was added in Phoenix version 11.15.0. It defaults to true and only needs to be set to false in air-gapped deployments where external network access is not available.
Phoenix supports automatic trace retention policies to help manage storage and comply with data retention requirements. You can configure the default retention policy at deployment time using the PHOENIX_DEFAULT_RETENTION_POLICY_DAYS environment variable.Basic Configuration:Set the environment variable to the number of days you want to retain traces:
Docker Example:
Kubernetes/Helm Example:
Key Points:
  • Default value is 0 (infinite retention) - no traces are automatically deleted
  • Applies to all projects by default, but individual projects can override this through the Phoenix UI
  • Cleanup runs weekly according to the configured schedule (Sunday at midnight by default)
  • Only affects the default policy - you can still create custom retention policies for specific projects
  • Changes to this setting will update the default policy but won’t affect existing project-specific policies
For more advanced retention policy configurations and per-project settings, see the data retention documentation.
Be careful when setting retention policies in production. Once traces are deleted, they cannot be recovered. Always test your retention policy configuration in a non-production environment first.