Skip to main content

​
Infrastructure credentials

The default configuration ships with weak, well-known passwords for PostgreSQL, MinIO, and Redis. Replace them with strong, unique values before exposing Tracecat to production traffic. 
# PostgreSQL
TRACECAT__POSTGRES_USER=tracecat
TRACECAT__POSTGRES_PASSWORD=<strong random password>

# Temporal PostgreSQL
TEMPORAL__POSTGRES_USER=temporal
TEMPORAL__POSTGRES_PASSWORD=<strong random password>

# MinIO / S3
MINIO_ROOT_USER=<strong random user>
MINIO_ROOT_PASSWORD=<strong random password>

# Redis — add a password and update the URL
REDIS_URL=redis://:<strong random password>@redis:6379
For Redis, you also need to pass the password to the container. Add a command override in your docker-compose.yml: 
services:
  redis:
    command: ["redis-server", "--requirepass", "<same password as above>"]
In production, consider replacing self-hosted PostgreSQL and Redis with managed services (e.g., Amazon RDS, ElastiCache) that handle encryption at rest, automated backups, and credential rotation.

​
Execution sandboxing

Tracecat executes user-defined Python scripts and actions inside the executor service. The level of isolation depends on your configuration.
By default, Tracecat runs with TRACECAT__DISABLE_NSJAIL=true and uses the direct executor backend. In this mode, scripts run as regular subprocesses and can access the executor’s environment variables, filesystem, and network. This is acceptable for development but not recommended for production.

​
PID namespace isolation

The default direct backend provides best-effort PID namespace isolation using Linux unshare. This prevents scripts from inspecting other processes via /proc, but does not restrict filesystem or network access. It works without Docker privileged mode and is the baseline for non-sandboxed deployments. For production, enable nsjail — a process isolation tool from Google that enforces:
  • Filesystem isolation — scripts can only access their job directory and explicitly mounted paths. The host filesystem is not visible.
  • Resource limits — CPU time, memory, file size, and process count are capped per execution. A runaway script cannot starve the host.
  • User namespace separation — scripts run as unprivileged users even when the container runs as root.
  • Network access — network is allowed (scripts need to reach databases, APIs, and S3) but constrained to the container’s network namespace.
To enable nsjail, set the following in your .env: 
TRACECAT__DISABLE_NSJAIL=false
TRACECAT__EXECUTOR_BACKEND=pool  # or 'ephemeral' for multi-tenant full isolation
nsjail requires:
  • Linux with kernel 4.6+
  • Docker privileged mode or CAP_SYS_ADMIN capability on the executor container
  • The nsjail binary and sandbox rootfs (included in Tracecat images)
nsjail is not supported on macOS or Windows. These platforms can only use the direct backend with PID namespace isolation.

​
Choosing a backend

BackendIsolationLatencyUse case
directPID namespace only~50msDevelopment, trusted environments
poolnsjail sandbox (warm workers)~100-200msSingle-tenant production
ephemeralnsjail sandbox (cold per action)~4000msMulti-tenant, maximum isolation

​
Authentication

Docker Compose deployments default to basic email/password authentication. For production, configure OIDC or SAML SSO.

​
TLS

Never run production traffic over plain HTTP. See How do I configure SSL for production? for Caddy-based automatic TLS setup.