Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
hsin003
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
hsin003
2mo ago
containarium did the same thing with lxc as a container isolation and use eBPF for network safeguard. https://github.com/FootprintAI/Containarium
2.
▲
by
hsin003
2mo ago
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.
3.
▲
by
hsin003
2mo ago
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.
4.
▲
by
hsin003
2mo ago
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 ( https://github.com/FootprintAI/Cont
5.
▲
Show HN: Containarium – self-hosted sandbox for AI agents, MCP-native
(github.com)
5 points
by
hsin003
4mo ago
|
1 comments
6.
▲
Why your 'Private Google Access enabled' subnet still bills Cloud NAT
(github.com)
3 points
by
hsin003
5mo ago
|
1 comments
7.
▲
by
hsin003
5mo ago
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 pulling data from GCS — exactly wh
8.
▲
by
hsin003
6mo ago
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 can pass all checks and still become vulnerable later as new C
9.
▲
by
hsin003
6mo ago
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, release notes, etc.) are still worth doing. One thing this in
10.
▲
by
hsin003
6mo ago
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 that even if you catch everything during review, new CVEs can a
11.
▲
by
hsin003
6mo ago
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 it with a dev-like centralized platform ensures every se
12.
▲
by
hsin003
6mo ago
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 anyone realizing it. That’s why I think continuous monitoring and
13.
▲
by
hsin003
6mo ago
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 agent had a known CVE. Containarium now runs centralized pe
14.
▲
AI coding agents accidentally introduced vulnerable dependencies
7 points
by
hsin003
6mo ago
|
16 comments
15.
▲
by
hsin003
8mo ago
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
16.
▲
by
hsin003
8mo ago
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 you’ve seen.
17.
▲
by
hsin003
8mo ago
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 provisioning, isolation, and resource limits in your setup. More impo
18.
▲
by
hsin003
8mo ago
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
19.
▲
by
hsin003
8mo ago
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 tips on making provisioning faster or keeping resourc
20.
▲
Show HN: Hosting 100 Linux dev environments on one VM using LXC
(github.com)
16 points
by
hsin003
8mo ago
|
16 comments
21.
▲
by
hsin003
8mo ago
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.com/FootprintAI/Containarium The idea i