How We Handle Container Isolation
When you deploy an app on Deployxa, it runs in a container alongside containers from other users. How do we ensure that your container is isolated from other users' containers? How do we prevent a malicious user from accessing your data, your environment variables, or your network traffic? This is the container isolation problem, and it is one of the most important security challenges for any container platform. Here is how Deployxa handles it, the isolation techniques we use, and the trade-offs we chose.
The direct answer is that Deployxa uses Docker containers with hardened cgroups (Linux control groups) and dropped Linux capabilities for isolation. This is not the same as microVM isolation (e.g., Firecracker, used by AWS Lambda and Fly.io), which provides stronger isolation but with higher overhead. We chose Docker cgroups because they provide a good balance of isolation and performance, which is appropriate for our use case (a PaaS where users deploy their own code, not a multi-tenant SaaS where users process untrusted data). For more on Deployxa's architecture, see our article on the container networking model.
The Isolation Techniques
Deployxa uses several isolation techniques:
1. Docker containers (namespace isolation)
Docker containers use Linux namespaces to isolate processes from each other. Each container has its own PID namespace (process IDs), network namespace (network interfaces), mount namespace (file system), and UTS namespace (hostname). This means a process in one container cannot see processes in another container, cannot access another container's file system, and cannot send network traffic to another container (unless they are on the same Docker network). For more on Docker isolation, see the Docker documentation.
2. Cgroups (resource limits)
Docker containers use cgroups (Linux control groups) to limit the resources a container can use (e.g., CPU, memory, disk I/O). This means a container cannot consume all the host's resources, which prevents noisy-neighbor problems (where one container's load degrades other containers' performance). For more on cgroups, see our article on the metrics pipeline, which covers how we collect cgroup metrics.
3. Dropped capabilities
Docker containers run with a reduced set of Linux capabilities (e.g., no CAP_SYS_ADMIN, no CAP_NET_ADMIN), which means the container cannot perform privileged operations (e.g., load kernel modules, configure network interfaces). This reduces the attack surface, because even if an attacker compromises the container, they cannot escalate to the host. For more on Linux capabilities, see the Linux capabilities documentation.
4. Network isolation
Each app gets its own Docker network, and containers in different apps cannot communicate with each other (unless explicitly configured). This means a container in app A cannot send network traffic to a container in app B, which prevents cross-app attacks. For more on network isolation, see our article on the container networking model.
5. Read-only file system
Container file systems are read-only (except for designated write directories like /tmp and /data), which means an attacker cannot modify the container's code or configuration. This reduces the attack surface, because even if an attacker compromises the container, they cannot persist their changes (the changes are lost when the container restarts). For more on file system isolation, see the Docker documentation.
Step-by-Step: How a Container Is Isolated
Here is how a container is isolated from other containers.
Step 1: The container is started with namespace isolation
When Deployxa starts your container, Docker creates a new set of namespaces (PID, network, mount, UTS) for the container. This means your container's processes are isolated from other containers' processes, your container's network is isolated from other containers' networks, and your container's file system is isolated from other containers' file systems.
Step 2: The container is started with cgroup limits
Docker creates a cgroup for your container, with limits on CPU, memory, and disk I/O. This means your container cannot consume more than its allocated resources, which prevents noisy-neighbor problems.
Step 3: The container is started with dropped capabilities
Docker starts your container with a reduced set of Linux capabilities. This means your container cannot perform privileged operations (e.g., load kernel modules, configure network interfaces), which reduces the attack surface.
Step 4: The container is connected to its app's Docker network
Docker connects your container to your app's Docker network, which means your container can communicate with other containers in the same app (e.g., the backend can call the database). Containers in different apps are on different networks, which means they cannot communicate with each other.
Step 5: The container's file system is read-only
Docker starts your container with a read-only file system (except for designated write directories). This means an attacker cannot modify the container's code or configuration, even if they compromise the container.
Common Pitfalls and Troubleshooting
The first pitfall is assuming Docker isolation is the same as VM isolation. Docker containers use namespace and cgroup isolation, which is weaker than VM isolation (e.g., a kernel exploit can escape a container but not a VM). For apps that process highly sensitive data (e.g., healthcare, financial), VM isolation (e.g., via Firecracker) might be necessary. For most apps, Docker isolation is sufficient. The second pitfall is not dropping capabilities. By default, Docker containers run with a reduced set of capabilities, but some platforms (or configurations) might run containers with more capabilities, which increases the attack surface. The fix is to ensure containers run with the minimum necessary capabilities. The third pitfall is not using network isolation. If all containers are on the same network, a compromised container can attack other containers. The fix is to use per-app networks, which Deployxa does by default. The fourth pitfall is not using a read-only file system. If the file system is writable, an attacker can persist their changes (e.g., install a backdoor). The fix is to use a read-only file system with designated write directories. The fifth pitfall is not keeping the host updated. Container isolation depends on the host's kernel, which means a kernel vulnerability can compromise all containers. The fix is to keep the host's kernel updated (which Deployxa does automatically).
The Trade-Off: Docker vs MicroVM
Deployxa uses Docker containers with cgroups and dropped capabilities, not microVMs (e.g., Firecracker). This is a deliberate trade-off. Docker containers are faster (near-zero startup overhead) and more efficient (lower memory overhead) than microVMs, which means we can run more containers per host, which keeps costs low. The trade-off is that Docker isolation is weaker than microVM isolation (a kernel exploit can escape a container but not a microVM). For our use case (a PaaS where users deploy their own code), this trade-off is appropriate, because users are deploying their own code (not processing untrusted data from other users), and the risk of a kernel exploit is low. For platforms that process untrusted data from multiple users (e.g., a code execution platform like Replit), microVM isolation might be necessary. For more on this trade-off, see our article on Deployxa vs Fly.io, which compares Docker containers with Fly.io's microVM-based approach.
How Isolation Integrates with the Security Model
Container isolation is one piece of Deployxa's security model, which also includes authentication (OAuth 2.1 PKCE for the MCP server), authorization (scoped tokens, confirmation gates for destructive actions), and audit logging (all actions are logged). For more on the security model, see our article on securing agentic cloud deployments. For more on authentication, see our article on the JWT authentication trap.
Lessons Learned
Building the container isolation model taught us several lessons. First, Docker isolation is sufficient for most use cases. Docker containers with cgroups and dropped capabilities provide a good balance of isolation and performance, which is appropriate for a PaaS. Second, microVMs are overkill for most use cases. MicroVMs (e.g., Firecracker) provide stronger isolation but with higher overhead, which is only necessary for platforms that process untrusted data from multiple users. Third, network isolation is essential. Per-app networks prevent cross-app attacks, which is a critical security measure. Fourth, a read-only file system is a cheap and effective security measure. It prevents attackers from persisting their changes, which limits the damage of a compromise. Fifth, keeping the host updated is critical. Container isolation depends on the host's kernel, which means a kernel vulnerability can compromise all containers. The fix is to keep the host's kernel updated (which Deployxa does automatically). For more on security, see our articles on the security headers gap and the rate limiting gap.
Advanced Security Patterns
Beyond the basics, container security benefits from several advanced patterns. The first is image scanning. Scan your container images for known vulnerabilities (e.g., with Trivy, Snyk, or Clair) before deploying them, which catches vulnerabilities in your base image or dependencies. The second is runtime security. Use a runtime security tool (e.g., Falco, Sysdig) that monitors container behavior in real time and alerts on suspicious activity (e.g., a container trying to access the host's file system). The third is secrets management. Use a secrets manager (e.g., Doppler, AWS Secrets Manager, HashiCorp Vault) to store secrets, rather than environment variables, which reduces the risk of secret leakage. The fourth is network policies. Use network policies to control which containers can communicate with each other, which limits the blast radius of a compromise. The fifth is compliance scanning. Use a compliance scanning tool (e.g., kube-bench, CIS-CAT) to verify your container configuration meets security benchmarks (e.g., CIS Docker Benchmark), which ensures your containers are configured securely. For more on security, see our articles on the JWT authentication trap and securing agentic cloud deployments.
When Advanced Security Is Not Needed
Advanced security is not always needed. For hobby projects, the default security (Docker isolation, dropped capabilities, network isolation) is sufficient, and advanced security tools add complexity without providing significant benefit. For internal tools (e.g., admin dashboards) that are only accessed by trusted users, the default security is fine. For apps that do not handle sensitive data (e.g., a public blog), the default security is fine. For these apps, the default security is sufficient. The key is to match the security to the app's needs: for apps that handle sensitive data or are exposed to the internet, advanced security is valuable; for hobby projects and internal tools, the default is fine. For more on security, see our articles on the container networking model and the security headers gap.
Conclusion: A Balanced Isolation Model
Deployxa's container isolation model uses Docker containers with cgroups and dropped capabilities, which provides a good balance of isolation and performance. By using namespace isolation, cgroup limits, dropped capabilities, network isolation, and a read-only file system, we ensure that your container is isolated from other users' containers, which protects your data and your app. For more on Deployxa's engineering, see our articles on the container networking model and the auto-scaling architecture. Learn about the build cache architecture and how we handle SSL at scale in our companion articles. Explore our free developer tools to speed up your workflow. Try Deployxa Drop for an instant live preview with zero signup.