Show HN: Katakate – Dozens of VMs per node for safe code exec (github.com)

124 points by gbxk ↗ HN
I've built this to make it easy to host your own infra for lightweight VMs at large scale.

Intended for exec of AI-generated code, for CICD runners, or for off-chain AI DApps. Mainly to avoid Docker-in-Docker dangers and mess.

Super easy to use with CLI / Python SDK, friendly to AI engs who usually don't like to mess with VM orchestration and networking too much.

Defense-in-depth philosophy.

Would love to get feedback (and contributors: clear & exciting roadmap!), thx

20 comments

[ 5.3 ms ] story [ 38.9 ms ] thread
(comment deleted)
I would really like to see a good local sandboxing solution in this space, something that is truly local-first. This is especially important since many coding models / agentic builders will eventually become lightweight enough to run them on-device instead of having to buy tokens and share user data with big LLM cloud providers.
> something that is truly local-first

Hey, we built coderunner[1] exactly for this purpose. It's completely local. We use apple containers for this (which are 1:1 mapped to a lightweight VM).

1. Coderunner - https://github.com/instavm/coderunner

https://rstrict.cloud/ is a CLI built in Rust on top of the Landlock API for the Linux kernel.

It lets you narrow the permission scope of an executable using simple command line wrappers.

(comment deleted)
as someone in the space this ticks a lot of boxes: kubernetes-native, strong isolation, python sdk (ideal for ML scenarios). devmapper is a nice ootb approach.

Glancing at the readme, is your business model technical support? Or what's your plan with this?

Anything interesting to share around startup time for large artifacts, scaling, passing through persistent storage (or GPUs) to these sandboxes?

Curious what things like 'Multi-node cluster capabilities for distributed workloads' mean exactly? inter-VM networking?

This seems like an amazing stack that ticks a lot of boxes for me, but I really dislike cli or a custom api as the UX for this and would prefer to manage all of this with CRDs so i can just use the k8s client for everything.
Why do I need this if I already have containers and k8s for running agents?
From an outside perspective, this looks silly. Like fitting a square peg in a round hole. But I do ack "what if we could run vm's as easily as we run containers" use case and atm it seems like things like this (and katacontainers) are the only ways to do it. Wondering a few things: do all the layers of abstraction make things brittle and how is performance impacted?
Great project. There's been multiple approaches/tools in the space(top of my head I can think of e2b, arrakis, claude's new tool). how is this different?
Thanks! I'll review Arrakis and come back. E2B is often considered harder to setup and less AI engineers friendly for direct stack contributions, as Katakate is the only alternative fully implemented in Python (core modules, Typer CLI, FastAPI, Python SDK).

Our native K8s support and exposition of K8s API also makes it friendly to devops.

Finally, our deploy/infra stack is lean and tightly fits in a single Ansible playbook, which makes it easy to understand and contribute to, letting you rapidly gain full understanding and ownership of the stack.

    name: project-build
    image: alpine:latest
    namespace: default
    egress_whitelist:
      - "1.1.1.1/32"      # Cloudflare DNS
      - "8.8.8.8/32"      # Google DNS
This is basically a wide-open network policy as far as data exfiltration goes, right?

Malicious code just has to resolve <secret>.evil.com and Google/CF will forward that query to evil resolver.

Is this basically an open-source DIY version of E2B?

If so, cool! AFAICT E2B is open-source licensed but tricky to setup.

what does Katakana add on top of Kata?
Looks like an interesting project. Do you have any comments on how it is different from running gVisor?
Nice, seems way cheaper to use than the new Cloudflare Sandbox SDK solution
Update: Katakate now supports ARM architecture (on Linux) thanks to a PR merged from Katakate's first external GitHub contributor: @spullara. Thank you!