Runtime Overview
Vectra Guard supports multiple container runtimes for sandboxing. Choose the runtime that best fits your environment and requirements.
Supported Runtimes
- Docker - Most compatible, requires Docker daemon
- Podman - Rootless, no daemon required
- Containerd - Lower-level, more control
Docker (Default)
Docker is the default and most widely supported runtime. It provides excellent compatibility and performance.
Requirements
- Docker Engine installed and running
- Docker daemon accessible (user in docker group or sudo)
- Sufficient disk space for images
sandbox:
runtime: docker
# Docker-specific options
docker:
socket: /var/run/docker.sock # Docker socket path
network_mode: bridge # Network mode
pull_policy: if-not-present # Image pull policy
# Base images
images:
default: vectraguard/base:latest
node: vectraguard/node:latest
python: vectraguard/python:latest
rust: vectraguard/rust:latestPros
- Widely supported and well-documented
- Excellent performance and compatibility
- Rich ecosystem of base images
- Good resource management
Cons
- Requires Docker daemon running
- May require root access or docker group membership
- Higher resource usage
Podman
Podman is a daemonless, rootless container runtime. It's a drop-in replacement for Docker with better security.
Requirements
- Podman installed
- No daemon required (runs as user)
- Works without root privileges
sandbox:
runtime: podman
# Podman-specific options
podman:
rootless: true # Run as non-root user
network_backend: netavark # Network backend
storage_driver: overlay # Storage driver
# Same image configuration as Docker
images:
default: vectraguard/base:latestPros
- No daemon required
- Rootless operation (more secure)
- Docker-compatible commands
- Lower resource overhead
Cons
- Less widely used than Docker
- Some advanced features may differ
- May have compatibility issues with some images
Containerd
Containerd is a lower-level runtime used by Kubernetes and Docker. It provides more control but requires more configuration.
Requirements
- Containerd installed and running
- CRI plugin enabled
- More complex setup than Docker/Podman
sandbox:
runtime: containerd
# Containerd-specific options
containerd:
socket: /run/containerd/containerd.sock
namespace: vectraguard
snapshotter: overlayfs
images:
default: docker.io/vectraguard/base:latestPros
- Lower-level control
- Used by Kubernetes (good for K8s environments)
- Efficient resource usage
- Production-grade reliability
Cons
- More complex configuration
- Less user-friendly than Docker
- Requires more setup and maintenance
Resource Configuration
Configure resource limits for sandboxed containers to prevent resource exhaustion and ensure fair sharing.
sandbox:
resources:
# CPU limits
cpu:
limit: 2 # CPU cores (can use decimals: 0.5)
shares: 1024 # CPU shares (relative priority)
quota: 200000 # CPU quota (microseconds per period)
period: 100000 # CPU period (microseconds)
# Memory limits
memory:
limit: 2GB # Maximum memory
reservation: 512MB # Guaranteed memory
swap: 1GB # Swap limit (0 to disable)
# Disk limits
disk:
limit: 10GB # Maximum disk space
iops: 1000 # IOPS limit
bandwidth: 100MB/s # Disk bandwidth
# Network limits
network:
bandwidth: 1Gbps # Network bandwidth limitTip: Set limits based on your typical workload. Too restrictive limits can slow down commands, too generous wastes resources and may allow resource exhaustion.
Base Images
Vectra Guard uses optimized base images for different programming languages and environments.
sandbox:
images:
# Default image (used when language not detected)
default: vectraguard/base:latest
# Language-specific images
node: vectraguard/node:20-latest
python: vectraguard/python:3.11-latest
rust: vectraguard/rust:1.75-latest
go: vectraguard/go:1.21-latest
java: vectraguard/java:17-latest
# Custom image
custom: your-registry/custom-image:tag
# Image pull policy
pull_policy: if-not-present # always, if-not-present, neverAvailable Base Images
vectraguard/base- Minimal base image with common toolsvectraguard/node- Node.js with npm/yarn/pnpmvectraguard/python- Python with pip/poetryvectraguard/rust- Rust with cargovectraguard/go- Go toolchainvectraguard/java- Java with Maven/Gradle
Choosing a Runtime
Use Docker If:
- You already have Docker installed
- You need maximum compatibility
- You're working in a Docker-friendly environment
- You want the easiest setup
Use Podman If:
- You can't or don't want to run a daemon
- You need rootless operation
- You're on a system without Docker
- Security is a primary concern
Use Containerd If:
- You're in a Kubernetes environment
- You need lower-level control
- You're building a production system
- You have containerd already set up
Best Practices
1. Start with Docker
Docker is the easiest to set up and most widely supported. Use it unless you have a specific reason to use another runtime.
2. Set Appropriate Resource Limits
Configure resource limits based on your typical workload. Monitor usage and adjust as needed.
3. Use Language-Specific Images
Use language-specific base images for better performance and smaller image sizes. They include only what's needed for that language.
4. Keep Images Updated
Regularly update base images to get security patches and performance improvements. Use pull_policy: always in development.
5. Monitor Resource Usage
Use runtime monitoring tools to track resource usage and identify containers that need adjustment.