The Node (and more) Banter

What started as a joke at the Node Collaborator Summit turned into the most compelling argument yet for why enterprises have no excuse left to avoid modernizing their native code.

In this episode of The Node (and more) Banter, Luca and Matteo are joined by Paolo, Principal Software Engineer at Platformatic, who built "Project Destino" — because in Italian, destino means doom, and yes, that's exactly how we name things.

That comment in London turned into a fully working DOOM port running at 35fps inside your terminal, with sound, powered entirely by Node.js FFI, OpenTUI, and a C library called DOOM Generic.

In this episode, we cover:
✅ How Node.js's native FFI module lets you load and run any C library. No native addons, no compilation headaches
✅ Why the game loop lives in JavaScript (via setInterval) while the engine ticks happen across the FFI boundary
✅ The FFI performance story: from 150 nanoseconds per call down to 15, close to the theoretical minimum
✅ Node.js Single Executable Applications (SEA): ship everything — game, sound, native libraries — as one binary
✅ The enterprise reality: if FFI can run DOOM, it can run your legacy DLLs — and there's no migration excuse left
✅ What's next: llama.cpp via FFI, NVIDIA GPU experiments — and possibly Prince of Persia

The takeaway?
We didn't port DOOM because it made sense. We did it because the technology made it possible — and that's exactly the point. Node.js FFI changes the migration conversation for every enterprise sitting on legacy native code. If it runs DOOM, it runs your C library. No excuses.

Many teams believe autoscaling is simple: set a CPU threshold and let Kubernetes handle it. But if you get a three-minute traffic spike and your pods need two minutes to start, users feel the lag, the spike ends, and your new pods show up too late. What if your infrastructure could predict traffic instead of just reacting?

In this episode, Luca Maraschi and Matteo Collina challenge the usual autoscaling approach—HPA, KEDA, ECS, and more. They explain the predictive scaling algorithm Platformatic created for their Intelligent Command Center (ICC). Matteo explains why scaling is a nonlinear problem that the industry keeps trying to solve with linear solutions, and how thinking of a distributed system like a neural network can change how scaling decisions are made.

In this episode, we cover:
✅ Why reactive autoscalers always use outdated data by design, and why this is a core flaw, not just a configuration issue
✅ The real cost of pod boot time that often gets ignored: spawn time, warmup, and traffic rebalancing
✅ Why CPU and memory are not the right metrics for Node.js, and what you should measure instead
✅ How Platformatic's algorithm checks event loop utilization from outside the thread, with no interference and no extra overhead
✅ The benchmark results: 99.47% success rate compared to 95% with KEDA and 90% with HPA, with P99 latency ten times better
✅ The 46-page white paper they published, and why they believe it's time to stop scaling out of fear
The takeaways?
Over-provisioning is not a safety net; it shows the model is broken. If your system cannot predict load, you will always have to choose between wasting money and getting worse performance. This episode, along with the white paper, argues that smarter scaling is now essential, not just a bonus.

Running AI agents in production isn't just about picking the right LLM. It's about the infrastructure decisions that make them safe, fast, and deployable at scale. Choosing between micro VMs, gVisor, Firecracker, or eBPF sounds like a systems engineering rabbit hole, until you realize the wrong choice can mean seconds of startup latency, infrastructure bloat, or an isolation model that doesn't match your actual threat surface.

In this episode of The Node (& More) Banter, Luca Maraschi and Matteo Collina go deep on the architecture behind Regina, Platformatic's AI agent sandbox, and explain exactly why they chose eBPF over traditional VM-based isolation. We unpack the two fundamental agent sandbox patterns, the trade-offs between logical and physical isolation, and why Node.js turned out to be a surprisingly perfect fit for systems-level eBPF work.
We'll explore:
✅ eBPF vs. micro VMs: startup latency, infrastructure complexity, and where the real boundary sits
✅ Process-level vs. container-level isolation and why granularity changes everything for agents
✅ The snowflake problem: managing stateful agents across Kubernetes pod restarts
✅ How syscall and network policies are enforced at runtime, per agent process
✅ Why Node.js is a natural fit for eBPF and why they built their own stack instead of using OpenCilium

The big picture?
Infrastructure shapes safety. If you're building or deploying AI agents on Kubernetes, this episode gives you the mental model for why isolation at the process level, not the container level, matters and why Node.js can hold its own as a systems language when the architecture is right.

Most teams building AI agents treat Kubernetes like it's optional. They spin up a Mac Mini, run their agent locally, and call it a day, until someone asks how to scale it, govern it, or deploy it across the enterprise. That's when the architecture falls apart. The question is: what does it actually take to run agents in production, at scale, inside the infrastructure you already have?

In this episode of The Node (and more) Banter, Matteo Collina and Luca Maraschi do a full debrief on Platformatic's launch week, unpacking what they shipped, why they built it, and the hard distributed systems problems they had to solve along the way. From Regina, the open-source agent runtime built on top of Watt, to a Kubernetes-native sandbox powered by eBPF, this is the behind-the-scenes breakdown of what it takes to bring agentic infrastructure to the enterprise.

In this episode, we cover:
✅ What Platformatic launched. Regina, the agent sandbox, and the enterprise Kubernetes layer
✅ Why agents are fundamentally stateful and why that breaks every assumption Kubernetes was built on
✅ How Regina lets you define agents as a combination of Markdown and TypeScript, with state stored in SQLite and communication between agents baked in
✅ The coordinator model: how Platformatic routes agent traffic inside Kubernetes without relying on a standard load balancer
✅ Why we rejected the E2B remote VM model, and built a sandbox using eBPF directly inside the cluster instead
✅ The governance problem nobody is talking about: who owns the agent, and how do you separate API access concerns from agent execution concerns?
✅ The "ask-to-get" model. How developers can request access to URLs or disk policies without blowing up the enterprise approval process
✅ Honest takes on sandbox security, adversarial escapes, and what "good enough" actually means

The takeaway?
Agents aren't a new category of software. They're stateful Node.js processes, and the hard part was never the AI model, it was everything around it: the state management, the routing, the isolation, and the governance. If you're thinking seriously about deploying agents inside your company's infrastructure, this episode gives you the full picture of what that actually requires.

Full-stack development is moving fast. TanStack Start is changing how we handle data fetching, routing, and server-client boundaries. AI tools like Claude are speeding up how we build and test these systems. But when it’s time for production, one question matters: how do you scale CPU-bound workloads like SSR without losing performance?

Luca Maraschi and Matteo Collina sit down with Tanner Linsley, creator of TanStack, to dig into the core principles behind the TanStack ecosystem and what happens when those ideas hit real infrastructure. We share recent benchmarks of TanStack Start running on Watt under heavy load, showing exactly how architecture choices affect throughput, latency, and reliability.

In this episode, we cover:
✅ The core principles behind TanStack and why they resonate with modern developer workflows
✅ What happens when TanStack Start hits production workloads, including SSR and CPU-bound bottlenecks
✅ Insights from benchmarking at 1000 req/sec on Kubernetes and what they reveal about real-world performance
✅ Why kernel-level load balancing and multi-worker architectures improve tail latency without adding overhead

If you’re building or leading teams on modern full-stack apps, this episode is for you. We break down how framework design, AI tools, and runtime architecture combine to power the next wave of scalable web systems.