Viewing profile — hsin003

containarium did the same thing with lxc as a container isolation and use eBPF for network safeguard. https://github.com/FootprintAI/Containarium

have you tried lxc + eBPF? the former allows you to have lighter & faster (share kernel) and the latter gives you security. that is what we do for containarium.

does eBPF be serving for security enough? ec2 is heavy in terms of cost while containarium ( https://github.com/FootprintAI/Containarium ) can achieve both, safe & cheap.

Really cool project. It's fascinating to see more developers pushing back against the complexity of modern container orchestrators. This open-sourced project called Containarium ( …

[flagged]

We hit a Cloud NAT bill of ~$4,500/month (3.2 TiB/day at $0.045/GiB) on a project where we'd "enabled Private Google Access" on the subnet. The traffic was inference workloads pull…

[dead]

[dead]

I agree CI should catch as much as possible — image scanning and dependency checks at build time are table stakes. But in practice, CI is only a point-in-time guarantee. A build ca…

[dead]

I think both points are true in practice. Reviewing AI-generated code can require more experience than generating it, but at the same time some basic checks (dependency versions, r…

That’s a great point about fresh-context reviews — the same session that generated or assembled the code often won’t catch its own mistakes. What worried us in this incident is tha…

Totally agree — AI scaffolding automates work, but best practices like CI/CD and pentesting are still essential. Continuous monitoring is necessary for all commits, and combining i…

CVEs are time-dependent. Even if npm audit guarantees no known vulnerabilities at the moment you merge a PR, new CVEs can emerge later, silently impacting your system without anyon…

Hi HN — author here. This incident showed how AI-generated code can inadvertently introduce vulnerabilities. The cryptominer ran because a dependency version chosen by an AI coding…

Recently we discovered something unexpected on one of our servers: a cryptominer running in the background. The machine was hosting a web service built using Next.js. The first sig…

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 i…

Containarium does indeed build on LXC/Incus and isn’t trying to reinvent the wheel. If you’ve run multi-tenant sandboxes at scale, we’d love to hear what pitfalls or limitations yo…

Sorry, we want to understand your use case better. Did you provision *one VM via Proxmox* and then run *multiple users via Incus* inside it? We’re curious how you handled provision…

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" a…

That’s awesome — thanks for sharing! 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 ti…

Hi HN, 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.c…