Thanks for sharing! We’re definitely aware that Incus + Proxmox are very mature and full-featured.
Containarium is more of a "purpose-built, single-VM, SSH-first dev environment" approach:
- Lightweight: 1 VM can host 50–100+ LXC containers
- Quick provisioning: seconds instead of minutes per environment
- Focused on SSH workflows and dev sandboxing, not full datacenter management
- Minimal infra overhead: no GUI, no HA cluster required
Tradeoffs we’re aware of:
- Shared kernel (not VM-level isolation)
- Linux-only
- Less built-in tooling compared to Proxmox
We designed it to *optimize for cost efficiency and rapid dev onboarding*, rather than full-featured virtualization.
Would love to hear if you see any pitfalls with this approach compared to using Proxmox/Incus in a single-host scenario!
Good questions — yes, Containarium relies heavily on *user namespaces*. Here’s how it works:
- We enable `security.nesting=true` on unprivileged LXC containers, so Docker can run inside (rootless).
- *User namespace isolation* ensures that even if a user is “root” inside the container, they are mapped to an unprivileged UID on the host (e.g., UID 100000), preventing access to host files or devices.
This setup allows developers to run Docker and do almost anything inside their sandbox, while keeping the host safe.
The idea is simple:
- One cloud VM
- Many unprivileged LXC system containers
- Each user gets their own isolated Linux environment via SSH (ProxyJump)
- Persistent storage survives VM restarts
This is NOT Kubernetes, Docker app containers, or a web IDE.
Each container behaves like a lightweight VM (full OS, users, SSH access).
Why we built it:
We kept seeing teams pay for dozens of mostly-idle VMs just to give people
a place to SSH into. Using LXC, we can host tens or hundreds of environments
on a single VM and cut infra costs significantly.
What we’re looking for:
- Feedback from people who’ve run multi-tenant Linux systems at scale
- Security concerns we might be underestimating
- Where this approach breaks down in real-world usage
- Alternatives we should be considering (LXD, Proxmox, something else?)
Tradeoffs we’re aware of:
- Shared kernel (not VM-level isolation)
- Not suitable for untrusted workloads
- Linux-only
- Requires infra discipline (limits, monitoring, backups)
This is early-stage and open source. APIs and workflows will evolve.
We’re not trying to “replace Kubernetes” — just trying to do one thing well:
cheap, fast, SSH-based dev environments.
Would love blunt feedback from folks who’ve been down this road before.
- Did you use LXC containers, or full VMs for each sandbox?
- How did you handle SSH / network isolation?
- Any tips on making provisioning faster or keeping resources efficient?
We’re using unprivileged LXC + SSH jump hosts on a single VM for cost efficiency.
I’d love to hear what tradeoffs you found using the Proxmox API.
k_bx|1 month ago
hsin003|1 month ago
Containarium is more of a "purpose-built, single-VM, SSH-first dev environment" approach:
- Lightweight: 1 VM can host 50–100+ LXC containers - Quick provisioning: seconds instead of minutes per environment - Focused on SSH workflows and dev sandboxing, not full datacenter management - Minimal infra overhead: no GUI, no HA cluster required
Tradeoffs we’re aware of: - Shared kernel (not VM-level isolation) - Linux-only - Less built-in tooling compared to Proxmox
We designed it to *optimize for cost efficiency and rapid dev onboarding*, rather than full-featured virtualization.
Would love to hear if you see any pitfalls with this approach compared to using Proxmox/Incus in a single-host scenario!
BobbyTables2|1 month ago
If a developer can run Docker inside this, what stops them from mounting volumes from the host or changing namespaces?
Is this relying on user namespaces ?
hsin003|1 month ago
- We enable `security.nesting=true` on unprivileged LXC containers, so Docker can run inside (rootless).
- *User namespace isolation* ensures that even if a user is “root” inside the container, they are mapped to an unprivileged UID on the host (e.g., UID 100000), preventing access to host files or devices.
This setup allows developers to run Docker and do almost anything inside their sandbox, while keeping the host safe.
hsin003|1 month ago
We’ve been experimenting with an alternative to the “one VM per developer” model for SSH-based development environments.
The project is called Containarium: https://github.com/FootprintAI/Containarium
The idea is simple: - One cloud VM - Many unprivileged LXC system containers - Each user gets their own isolated Linux environment via SSH (ProxyJump) - Persistent storage survives VM restarts
This is NOT Kubernetes, Docker app containers, or a web IDE. Each container behaves like a lightweight VM (full OS, users, SSH access).
Why we built it: We kept seeing teams pay for dozens of mostly-idle VMs just to give people a place to SSH into. Using LXC, we can host tens or hundreds of environments on a single VM and cut infra costs significantly.
What we’re looking for: - Feedback from people who’ve run multi-tenant Linux systems at scale - Security concerns we might be underestimating - Where this approach breaks down in real-world usage - Alternatives we should be considering (LXD, Proxmox, something else?)
Tradeoffs we’re aware of: - Shared kernel (not VM-level isolation) - Not suitable for untrusted workloads - Linux-only - Requires infra discipline (limits, monitoring, backups)
This is early-stage and open source. APIs and workflows will evolve.
We’re not trying to “replace Kubernetes” — just trying to do one thing well: cheap, fast, SSH-based dev environments.
Would love blunt feedback from folks who’ve been down this road before.
Weryj|1 month ago
hsin003|1 month ago
If you don’t mind me asking:
- Did you use LXC containers, or full VMs for each sandbox? - How did you handle SSH / network isolation? - Any tips on making provisioning faster or keeping resources efficient?
We’re using unprivileged LXC + SSH jump hosts on a single VM for cost efficiency. I’d love to hear what tradeoffs you found using the Proxmox API.