security
Security
How Runix isolates containers, protects secrets, and secures your deployments.
Security Overview#
Runix is designed with security at every layer. Each deployment runs in its own isolated Docker container with strict resource limits, syscall filtering, and network controls.
Container isolation#
Every service you deploy runs in its own Docker container, completely isolated from other users and services. Containers cannot see or communicate with each other unless explicitly configured.
- Each container runs in its own network namespace
- Filesystem is read-only by default (only /tmp and app-specific directories are writable)
- No shared kernel state between containers
- Containers are ephemeral — destroyed and recreated on each deploy
Syscall filtering (seccomp)#
Runix applies a strict seccomp profile to every container, blocking dangerous system calls like ptrace, mount, and module loading. This prevents containers from escaping their sandbox.
The seccomp profile is based on Docker's default profile with additional restrictions. Most applications work without modification.
Resource limits#
Every container is subject to strict resource limits to prevent abuse and ensure fair usage across the platform.
| Resource | Limit |
|---|---|
| CPU | Capped per instance type (shared vCPU) |
| Memory | 512 MB (Hobby/Starter), 2 GB (Pro), 4 GB (Business) |
| PIDs | Maximum 256 processes per container |
| Disk | Ephemeral — no persistent writes outside volumes |
| Network | Outbound allowed, inbound via proxy only |
If your container exceeds its memory limit, it will be killed and restarted automatically. Check your plan's memory allocation if you see OOM (out of memory) errors in logs.
Network isolation#
Containers are not directly accessible from the internet. All inbound traffic goes through Runix's reverse proxy (Caddy), which handles TLS termination, routing, and rate limiting.
- No open ports on containers — traffic is routed through the proxy
- Internal services (background workers, databases) are not exposed to the internet
- Database connections are only accessible from within your workspace's network
- All external traffic is encrypted with TLS 1.2+
Secret management#
Environment variables (secrets, API keys, database credentials) are injected at runtime and never baked into Docker images.
- Secrets are stored encrypted in the database
- Injected as environment variables when the container starts
- Never written to the Docker image layers
- Not visible in build logs
- Accessible only to the deployment owner
Use the dashboard or CLI to manage secrets. Never commit sensitive values to your repository.
TLS everywhere#
All traffic to Runix is encrypted. Every deployment gets automatic TLS via Let's Encrypt, including custom domains.
- runixcloud.dev subdomains: TLS via wildcard certificate
- Custom domains: Automatic Let's Encrypt certificate provisioning
- API traffic: All API endpoints require HTTPS
- Database connections: Encrypted in transit
Authentication model#
Runix uses JWT tokens for authentication. Tokens are scoped to your workspace and cannot access other users' resources.
| Token type | Lifetime | Use case |
|---|---|---|
| Session token | 24 hours | Dashboard and API access |
| CLI token | 90 days | CLI and CI/CD pipelines |
| OAuth token | Managed by GitHub | GitHub repository access |
Treat your CLI token like a password. Do not commit it to version control or share it publicly. If compromised, log in again to rotate it.
Read-only filesystem#
Container filesystems are read-only by default. Only /tmp and application-specific directories (like /app/data for databases) are writable. This prevents attackers from modifying your application code at runtime.
Reporting vulnerabilities#
If you discover a security vulnerability, please report it to security@runix.dev. We take all reports seriously and will respond within 48 hours.