The Node (and more) Banter

Platformatic

The Node (and more) Banter is your weekly dose of unfiltered, unscripted conversations between Luca Maraschi and Matteo Collina.

We explore the edge cases, the anti-patterns, and the things no one puts in the docs. From distributed architecture to platform pitfalls and how enterprises tackle modern development—nothing’s off-limits. It’s not just Node.js®—it’s everything around it, wrapped in sharp banter, war stories, and real-world insight.

The sky’s the limit.

Play

Open in

21 episodes
weekly
Avg 32 min
English

Episodes 21

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

S2 · E33
Wednesday · 31 min
Every Week the Same Spike. Every Week Your Autoscaler Is Surprised.
Every Friday evening, your traffic goes up. Each weekday morning, your app becomes active again. Overnight, things slow down. Your autoscaler has seen this pattern many times, but tomorrow it will act like it’s new. It waits for a metric to cross a threshold, then starts adding capacity, which means you get a period of slower performance while the pods catch up. The real issue isn’t the pattern; it’s that the system keeps forgetting. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Ivan Tymoshenko, Staff Software Engineer at Platformatic, about the ICC Planner. This new layer sits on top of ICC's real-time scaler and looks ahead from seconds to weeks. Instead of treating every traffic spike like it’s new, the Planner learns repeating capacity patterns from ICC's ELU and heap signals, predicts pod demand by time of day, and turns those patterns into suggestions that operators can review, compare with past data, and approve. When a suggestion is accepted, capacity is ready before the expected load arrives, so you’re not always playing catch-up. In this episode, we cover: ✅ Why real-time scalers always miss the first few seconds of recurring demand, and why short-horizon algorithms can’t solve calendar-based issues ✅ How the Planner uses ELU and heap signals instead of just request counts, and why this matters for workloads that seem similar but are actually different ✅ The difference between baseline suggestions and pattern suggestions, and how the rules allow Friday-specific and everyday settings to work together without conflict ✅ Why accepted suggestions are snapshots that operators control, not live model outputs, and what this means for production safety when the model updates overnight The takeaway? Reactive scaling and scheduled scaling are usually seen as separate options, but ICC combines them into one control loop. The Planner takes care of what history can predict, while the live scaler manages the unexpected. This way, your Friday peak gets the needed capacity before the first request comes in, and you don’t have to pay for extra capacity the rest of the week.
S2 · E32
August 19 · 33 min
Who Gets to Decide When You Can Use AI?
Matteo works on cybersecurity for Node.js every day. AI has become essential for managing the flood of new vulnerabilities. Still, Fable blocks anything that interacts with a pointer, Anthropic's frontier models are off-limits for security research, and the US government can change the rules at any time. This leaves open source maintainers and security researchers without good options. So Matteo decided to run AI models locally. Luckily, the creator of Redis had already built just what he needed. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about Dwarf Star IV, Salvatore Sanfilippo's custom setup for running open-weight models locally. They discuss what it really takes to run a 304 billion parameter model on regular hardware. The conversation covers everything from the aggressive quantization technique that fits DeepSeek V4 Flash into 128 gigabytes, to the real challenges of self-hosted AI, like power outages, hot European summers, and NAS units overheating while you're away. It's a straightforward look at what AI sovereignty means in real life. In this episode, we cover: ✅ How Salvatore's quantization technique keeps the routing layer at high precision while pushing the experts down to two bits, and why that's what makes a 304B model fit on a MacBook Pro or a GB10 ✅ Why frontier models are effectively blocked for Node.js security work, and why that may be putting everyone at more risk, not less ✅ The freshman who found a valid, convoluted vulnerability using Kimi, and what it says about AI democratizing security research on both sides of the fence ✅ Why the spike in downloads for Keet, data retention laws, EU chat control, and companies running their own AI hardware are all the same story: infrastructure freedom is winning The takeaway? The gap between what frontier models can do and what they'll let you do is becoming a real problem for legitimate security work. Local models close that gap, but the entry cost is still high, and the capability gap is real. What's changing is that the reasons to go local are no longer just technical. They're political.
S2 · E31
August 12 · 27 min
Should You Block the Event Loop?
Every Node.js developer learns the same rule on day one: never block the event loop. Async is good, sync is bad, and the libuv thread pool is your friend. Then a real customer brought Luca and Matteo a compression problem that turned all of that upside down. Turns out, the rule is only half the story, and the other half can bring your app down. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into one of the most counterintuitive findings they've encountered while working with a customer: that for CPU-bound operations like gzip compression, async code running on a single core doesn't just underperform; it creates an unbounded queue that can take your application down with an out-of-memory explosion. And sync, the approach everyone told you to avoid, can give you a 50 to 120 percent throughput improvement. In this episode, we cover: ✅ Why the libuv thread pool becomes a bottleneck when Node.js is deployed on a single core, and why four async threads competing for one CPU is worse than doing it synchronously ✅ The hidden DoS risk in async compression: why the main thread keeps accepting requests while the libuv queue grows out of bounds and runs you out of memory ✅ Why event loop delay alone is not enough, and why Event Loop Utilization tells you what delay misses entirely when doing CPU-bound async work ✅ The PR Matteo opened to fastify-compress based on these findings, and the numbers that came out of it The takeaway? Async is not always better. For CPU-bound operations like compression and cryptography, the overhead of thread contention on a single core can cost you more than the event loop block you were trying to avoid. The right answer depends on whether you can control back pressure from your source, and most teams haven't asked that question yet.
S2 · E30
August 5 · 26 min
Nitro Builds the Server. Who Runs the Fleet?
Nitro gives you a clean, portable server. Whether you use it on its own or with Vite, you get consistent builds, familiar routing, and a smooth development workflow. But Nitro doesn’t explain what to do when you have several instances and a cron job, or when you need a gateway, metrics, and worker health checks. Nitro handles the server, but someone still has to manage the whole fleet. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Paolo Insogna, Principal Software Engineer at Platformatic, about @platformatic/nitro. This new Watt feature connects Nitro to the Watt runtime without changing your server, build, or development workflow. No matter if you use a standalone Nitro API, a Vite-plus-Nitro frontend, or an app built with Lovable, Watt takes care of operations while Nitro keeps working as usual. In this episode, we cover: ✅ How @platformatic/nitro works for both standalone Nitro apps and Vite applications that use Nitro as a plugin, and why the distinction matters for your development workflow ✅ What Watt adds without changing your app: gateway integration, HTTP metrics, HTTPS, Event Loop Utilization monitoring, and multi-worker reusePort support ✅ The duplicate scheduled task problem. Why Nitro starts a cron timer inside every instance, and what @platformatic/nitro/scheduler does to give Watt ownership of the clock ✅ How ICC takes over cluster-wide scheduling: one cron per job across the entire fleet, with run history, pause controls, and healthy-instance targeting, while your task code stays inside Nitro The takeaway? Nitro is great at building servers. It was never designed to run a fleet. One line in nitro.config is all it takes to hand the operational layer to Watt and ICC, and your routes, handlers, build output, and scheduled tasks stay exactly where they are.
S2 · E29
July 29 · 30 min
Your Bug Fix Will Never Reach the Runs That Need It
You spot a critical bug in production, fix it, deploy, and feel relieved. But then you notice the workflows that need the fix most, like 30-day subscription cycles, compliance timers paused for months, or approvals waiting on a signature, are still stuck on the old version. They never get the fix. That’s not a safety net. It’s a risk that never disappears. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina discuss Platformatic’s new research paper on the Workflow Upgrade Risk model, or WUR. This data-driven method replaces the usual “pin everything” approach with a measurable score. Using only the telemetry your workflow engine already saves, WUR rates each in-flight run and shows which ones can safely move to the new version, which need a human check, and which really must stay pinned. No dry runs, sandboxes, or shadow execution needed. In this episode, we cover: ✅ Why pinning by default isn’t the best choice for enterprise workflows, and what “forgone-fix exposure” really costs your organization ✅ How the WUR model uses your engine’s existing event log to create an upgrade risk score for each run, and why having zero false negatives across 64,920 verdicts is important ✅ The three-part policy that replaces the simple pin-or-deploy choice: migrate what’s proven safe, review what’s uncertain, and only pin what’s truly incompatible ✅ Why the model backs up what engineers have always thought: small, frequent deployments are safer. Plus, how WUR lets you break any release into a series of deployments, each with a clear risk limit. The takeaway? Durable workflow engines already pay the storage cost of complete execution histories. The WUR model converts that cost into an analytical asset. For any enterprise running long-lived workflows, payment processing, compliance, approvals, drip campaigns, the question is no longer "is it safe to deploy?" It is "which runs are safe to move, and which ones do we owe a fix to?" Now you can answer both before you ship.
S2 · E28
July 22 · 27 min
Are Your AI Agents Really Production Ready?
Eve is a well-designed open-source agent framework. It offers a clean programming model, filesystem-based instructions and tools, and durable sessions built on the Workflow SDK. However, running Eve in a real enterprise Kubernetes environment needs extra infrastructure that isn't included by default. We built that missing piece, and in this episode, we share the full story of how Watt made it possible. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic. Together, they walk through every integration point between Eve and Watt, covering everything from standalone agents to Eve embedded inside Next.js applications, from self-hosted workflow state with @platformatic/world to distributed step execution across Kubernetes pods and workers. In this episode, we cover: ✅ How @platformatic/eve connects Eve to Watt as a first-class capability, giving it lifecycle management, HTTP metrics, and a production runtime without any changes to your agent code ✅ How @platformatic/world replaces Vercel's hosted workflow infrastructure with PostgreSQL-backed state, queues, and retries that run inside your own cluster ✅ How Eve steps are distributed across Kubernetes pods and Watt workers, and how ICC manages retries when a process stops in the middle of a step ✅ The role of skew protection in durable workflow execution, why a workflow that starts on version 1 must finish on version 1, and how ICC and the Workflow Service work together to enforce that guarantee The takeaway? Eve manages the agent model. Watt and ICC take care of everything that Kubernetes and the Enterprise require, including deployment lifecycle, distributed execution, scaling, and version-safe workflow replay. The integration is deep, and this episode covers all of it.
S2 · E27
July 15 · 28 min
Is AI Saving Open Source Or Just Using It?
People keep saying that AI helps developers get more done. But few are asking who pays for the computing power, tokens, and time needed to keep the open-source projects behind AI running. Node.js maintainers often use their own servers, patch together free subscriptions, and struggle to get access to the latest models they need to strengthen the core infrastructure that supports the AI industry. So who ends up paying for all this? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about their daily work with the latest models like Fable, Grok 4.5, and Codex, and what it really takes to run agents for a large open-source project. They discuss seeing 20-30% performance gains in Node.js micro-benchmarks with Fable, leaving tmux sessions running for months, and facing the tough fact that Node.js still can't access the advanced cybersecurity models it needs for protection. In this episode, we cover: ✅ How Matteo uses Fable with Claude Code's slash goal operator to deliver real performance improvements to Node.js, and where it still falls short ✅ The difference between short-context laptop agents and long-running server agents, and why your MacBook isn't the right place for the latter ✅ The open source compute problem that often gets overlooked: who pays for the tokens and machines when most maintainers are volunteers? ✅ Why Matteo can't use Fable to strengthen Node.js against security threats, and what it means that Node.js isn't included in Project Glasswing The takeaway? AI is bringing new life to open source contributions in ways that would have seemed impossible just two years ago. But it's also creating a new kind of inequality, dividing projects that have access to the latest models from those that do not. Node.js is used in almost every AI product available today. At the very least, the industry should give its maintainers the tools they need to keep it secure.
S2 · E26
July 8 · 30 min
Your Node.js Gateway It's Doing Twice the Work
You launch a new product. Thousands of users click the same link at the same time. The cache is cold, and your Node.js app starts generating the exact same response hundreds of times simultaneously, burning CPU, hammering your database, and slowing down for everyone. This is the thundering herd problem, and most teams only discover it the hard way. So what if your gateway could just... not do that? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina are joined by Paolo Insogna, Principal Software Engineer at Platformatic and Node.js TSC member, to break down how request deduplication works at the gateway level and why it changes the way you think about traffic spikes in Node.js. From the leader/waiter model to distributed coordination with Valkey, Paolo walks through exactly how Platformatic Gateway stops duplicate in-flight requests from reaching your upstream services, without touching a single line of your app code. In this episode, we cover: ✅ What the thundering herd problem actually is, and why caching alone doesn't solve it ✅ How gateway request deduplication works: the leader/waiter model explained in plain terms ✅ Memory vs. Valkey: when single-instance deduplication is enough and when you need distributed coordination ✅ The metrics that prove it's working, and what to watch for when rolling it out in production The takeaway? Caching protects you from future requests. Deduplication protects you while the first response is still being generated. They solve different problems, and running without both means your app is one viral moment away from a very bad day. Paolo built this into Platformatic Gateway so you get the protection without changing your backend, and this episode shows you exactly how it works.
S2 · E25
July 1 · 38 min
How Do You Build Skew Protection? Let's unpack it
"Zero downtime" doesn’t mean there’s no risk. When you release new code, some users still have the old version open in their browser, using outdated JS bundles and React state, without realizing anything has changed. Teams usually find out when a checkout fails or a form resets in the middle of a session. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down the version skew problem from scratch. They explain what really happens during a deployment, why forcing a reload isn’t an option, and how to keep several app versions running at once without causing issues for users. They walk through the solution live, covering cookies, ingress routing, Kubernetes replica sets, and show the control plane they built to manage it all. We will cover: ✅ Why version skew happens with every deployment and isn’t just a bug you can fix ✅ How old JS bundles and mismatched React state can quietly break live user sessions ✅ Why making users reload the page doesn’t solve the problem, and how it can hurt your e-commerce business ✅ How cookies and ingress controllers help send users to the right app version without causing problems✅ How the control plane architecture manages replica set registration, routing, and smooth shutdowns in Kubernetes The takeaway? Version skew isn’t a sign your deployment failed. It’s just part of how deployments work. The best teams don’t try to avoid it; they build systems that let different versions run together. A control plane won’t make things simple, but it does put the complexity in a place you can manage.
S2 · E24
June 24 · 27 min
Why Shipping Fast Breaks Your Users (and How to Stop It)
You deploy several times a day. Your team moves quickly, and your lead time is short. But each deployment can quietly disrupt users already on your site. There are no big warnings, just someone clicking around, suddenly running into errors because the app in their browser and your updated server are out of sync. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about version skew: what it is, why it naturally happens when you ship isomorphic JavaScript apps, and why most teams don’t set up skew protection until it causes problems in production. Here’s what we discuss in this episode: ✅ What isomorphic JavaScript actually means, and how running the same code on both the server and client leads to the skew problem ✅ Why version skew is different from API versioning, and how treating it like an API issue leaves you vulnerable when a user loads an old bundle, but the server has already changed ✅ Why shipping faster increases the chance for things to break, and how skew protection helps reduce that risk ✅ Why slowing down isn’t the solution: what Accelerate’s data shows about deploy frequency, lead time, and how small batches actually lower risk The takeaway? Shipping fast isn’t a problem; it’s the goal, and the data supports this. But fast deploys and isomorphic apps always lead to version skew, which stays hidden until a real user with an old bundle gets a 404 on something you removed earlier. Skew protection lets you keep deploying all day without quietly breaking users who arrived before lunch.
S2 · E23
June 17 · 31 min
Node.js Left 26% Performance on the Table for 10 Years
A default set in May 2015 just got its first change. One constant. One number. And it was silently costing Node.js up to 26% throughput on some of the most common workloads in the ecosystem: file reads, HTTP parsing, stream chunking. Nobody broke it. Nobody was ignoring it. It was just stuck in a world that no longer existed. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina explain how they investigated a small but important change that was just released in Node.js 26.3.0. They discuss how modern applications moved past an old assumption, why multi-threaded apps suffered the most, and what it takes to show that a simple fix is safe for millions of users. In this episode, we cover: ✅ How a default set in 2015 quietly stopped making sense as applications and hardware evolved ✅ Why the fix helped some workloads by 26%, and had zero impact on others ✅ How Matteo traced the slowdown all the way down to the operating system level to understand what was really happening ✅ The cost of the change, and how to think about whether it matters for your own application The takeaway? The biggest performance gains often don’t come from major rewrites. Sometimes, it’s just a setting that made sense years ago and was never revisited. The real lesson is about the assumptions built into the tools you use daily, and what can change when someone finally checks them.
S2 · E22
June 10 · 35 min
Performance/Memory tradeoff. Can we have both instead?
Memory and performance often compete with each other. Most developers only notice this tradeoff when something goes wrong, not during the initial design. At that point, the key decisions are already set. In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the memory-performance tradeoff from two sides: how to plan for it during design, and how to handle it at runtime if it becomes an issue. They use flame graphs on Kafka workloads to reveal hidden bottlenecks and explain a clear approach that makes memory debugging more reliable. This episode covers: ✅ Why the memory-performance tradeoff begins at design time, not after your app crashes ✅ How to find this tradeoff in your architecture before you start coding ✅ How flame graphs work in real situations and what they show about Kafka pipelines that other tools miss ✅ A step-by-step way to debug memory issues without guessing. The takeaway? The chicken-and-egg problem is not something you solve once and for all, but something you learn to manage. Developers who think about it during design build systems that don't cause late-night surprises. Flame graphs simply help you spot what you should have planned for.
S2 · E21
June 3 · 30 min
How Do We Scale Rate Limiting in Node.js?
Your Node.js service has rate limiting. You tested it, it worked, you shipped it. But your limit lives in the memory of a single process, and the moment you run more than one instance behind a load balancer, every replica enforces its own private budget. Ten instances means ten times the traffic you thought you were allowing. That is not a smaller problem at scale, it is a different problem entirely. So what does rate limiting that actually holds across a cluster look like? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina dig into rate limiting for Node.js applications, why the obvious approach quietly fails in production, and how to build limits that survive horizontal scaling. In this episode, we cover: ✅ The mechanics of in-process rate limiting and the trap of the in-memory store. ✅ Why per-instance counters cannot enforce a global limit once you scale out. ✅ How to back rate limiting with a shared store like Redis or Valkey, and the patterns that actually work. ✅ The operational realities: clock skew across nodes, what happens when your shared store goes down, and the consistency-versus-performance balance you have to choose. The takeaway? A rate limit is a promise about your whole system, not one process. If it only holds on a single instance, it is lying to you. Get distributed rate limiting right, and Node.js handles abuse and traffic spikes gracefully. Get it wrong, and you will find out the hard way, in production, under load.
S2 · E20
May 27 · 28 min
Requests, Limits, and the Throttling Trap: K8s Resources for Node.js
You set a CPU limit on your pod, the node has plenty of capacity to spare, and yet your Node.js service is throttled to a crawl. How does that happen? The answer lives deep in the Linux kernel, in the CFS bandwidth controller and cgroups, and most teams never look there. Requests and limits are not two knobs for the same thing. One drives scheduling, the other enforces a hard quota, and confusing them is how you end up paying for CPU you can never actually use. So how do you size them right for an event-loop runtime? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina break down how Kubernetes CPU and memory allocation actually works, what requests and limits really do at the kernel level, and why the defaults quietly sabotage Node.js workloads. In this episode, we cover: ✅ What CPU requests and limits actually mean, and why they are not interchangeable. ✅ How CFS quota and cgroups cause throttling even when the node is mostly idle. ✅ The three QoS classes (Guaranteed, Burstable, BestEffort) and which one fits a Node.js service. ✅ Why a single-threaded runtime makes limit sizing trickier than it looks, and the patterns that avoid silent throttling. The takeaway? Kubernetes will give you exactly what you asked for, including the throttling you did not mean to ask for. Get requests and limits right and your Node.js services run predictably. Get them wrong and you will burn money on capacity the scheduler will never let you touch.
S2 · E19
May 20 · 29 min
Should We Rewrite Node.js in Rust?
Bun made the switch. Zig is out, Rust is in, and AI handled most of the work, with 98% of the test suite passing. The question is no longer hypothetical; it's real now. If an AI can port an entire runtime, why are so many enterprise teams still stuck on a Node 12 codebase they're afraid to update? In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk about the Bun Zig-to-Rust port, including the memory leaks that led to the change, the rumors around it, and what it means that AI made it happen. They also look at the bigger picture: meta-cloud platforms losing their advantage, Node.js downloads passing 680 million a month thanks to AI tools, and why major AI companies still don't have a seat on the Node.js TSC, even though they build billions of dollars of products on it. In this episode, we cover: ✅ Why Bun is moving from Zig to Rust, and why memory safety matters more than the drama ✅ How AI managed to port a full runtime with 98% of tests passing, and what made this possible ✅ The key to AI-powered migrations: integration tests that focus on results, not how things are built ✅ Can enterprise teams do the same, and what does upgrading from Node 12 to Node 24 with AI really look like? The takeaway? The real breakthrough wasn't the model, but the test suite. Without integration tests, there is no migration, whether you use AI or not. That's the lesson hidden in the Bun story, and it's one most teams will miss while debating Rust versus Zig.
S2 · E18
May 13 · 36 min
We Ran DOOM in a Node.js Terminal. Now There's No Excuse for Your Legacy Native Code (with Paolo Insogna)
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.
S2 · E17
May 6 · 36 min
Predictive Autoscaling for Node.js: Why Reactive Systems Are Costing You More Than You Think
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.
S2 · E16
April 29 · 31 min
Sandboxing Ai Agents in Kubernetes: Why Regina Uses eBPF and Not a VM
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.
S2 · E15
April 22 · 34 min
Ai Agents, Kubernetes, and the Sandbox That Now Runs Inside Your Cluster
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.
S2 · E14
April 15 · 50 min
TanStack Start, AI, and Performance: Rethinking Full-Stack Architecture (with Tanner Linsley)
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.

Showing 1–20 of 21 episodes