Security

Stackpad is a multi-tenant platform — your containers run on shared infrastructure alongside other customers. Security is fundamental to the architecture, not an afterthought. This page describes the security model.

Container isolation

gVisor sandboxing

All web and service containers run inside gVisor (runsc) sandboxes — an application kernel that intercepts system calls, providing an additional layer of isolation beyond standard Linux containers. This means your code and third-party Docker images run in isolated sandboxes with no direct access to the host kernel.

Security profiles

Each service type runs with a tailored security profile:

Service type	Runtime	Capabilities	Notes
Web / Service	gVisor (runsc)	Minimal	Full sandbox isolation
Database	runc (default)	SYS_NICE, IPC_LOCK	Performance capabilities for database engines
Cache	runc (default)	IPC_LOCK	Minimal capabilities for cache engines

Databases and caches remain on the standard Docker runtime for optimal I/O performance — they don’t run untrusted code.

All containers run with:

• no-new-privileges — prevents privilege escalation
• PID limits — prevents fork bombs
• Capability dropping — only necessary Linux capabilities are granted
• Resource limits — CPU and memory cgroups prevent resource exhaustion
• Static IP networking — every service gets a fixed IP within the project network for reliable service discovery

Network isolation

Each project has its own Docker network. Services from different projects cannot communicate with each other. See Networking for details.

Protected services

Services with a web UI — like pgAdmin, n8n, Metabase, or the Supabase Studio — can be marked as protected. Only your team members can access them, verified through Stackpad’s authentication.

When a protected service is accessed:

1. Caddy intercepts the request
2. Stackpad verifies the visitor has a valid session and belongs to the organization
3. If valid, the request is proxied to the service
4. If not, a login page is shown

Toggle “Protected” in the service settings. No passwords to manage per tool — if you’re logged into Stackpad and part of the organization, you’re in.

Data encryption

At rest

• Environment variables are encrypted using AES-256-GCM before storage
• Database credentials are auto-generated and encrypted
• Backup files are stored on encrypted European storage

In transit

• External traffic is encrypted with TLS (automatic Let’s Encrypt certificates via Caddy)
• Internal traffic between nodes travels over WireGuard encrypted tunnels
• Build artifacts are transferred over the private network

API security

Authentication

Stackpad uses Better Auth for authentication:

• Email/password with email verification
• GitHub OAuth for streamlined developer signup
• Session-based auth with 30-day expiration and 24-hour refresh

Authorization

Every API request is validated:

• requireAuth middleware verifies the session
• requireOrg middleware verifies organization membership
• verifyProjectAccess() ensures the organization owns the requested project
• verifyServiceAccess() ensures the service belongs to the project

Input validation

All API inputs are validated with Zod schemas. No unvalidated user input reaches the database or container orchestration layer.

Rate limiting

• 600 requests/minute for general API endpoints
• 30 requests/minute for authentication mutations (login, signup)

Webhook security

GitHub webhooks are verified using HMAC-SHA256 with timing-safe comparison, preventing webhook spoofing.

Build security

• No shell interpolation in build commands — prevents command injection
• BuildKit secrets for build-time environment variables — not visible in image layers
• Isolated build nodes — builds run on dedicated infrastructure, not on compute nodes
• Automatic cleanup — build artifacts are removed after the image is pushed

Secret management

• Environment variable values are never returned via the API after creation
• Only variable names are displayed — values are write-only
• Secrets are never included in Temporal workflow history — only referenced by ID
• Database passwords are never logged or exposed in build output

What’s next?

• European infrastructure — data residency and GDPR
• Networking — network isolation model
• Architecture — platform architecture