Platformatic

Vendors promise "no lock-in" for durable execution. That holds for your code, but not for your live workflows. If a workflow is paused for two weeks waiting on approvals, its state sits locked in a single operator’s journal. Want to switch providers? Every in-flight run must be drained first. For long-running workflows, that means you’re stuck… migration never finishes. You can move your code, but your state is anchored. That’s real lock-in. It’s not about bad intentions; it’s built into the architecture. We face the same reality. How many of your workflows are mid-flight right now? If you needed to move, could any of them actually go with you?

Teams everywhere are deploying model-generated code. But almost no one is rethinking what that code can actually access. Most reviews stop at "is the output correct?" The real question is "what authority does this code run with?" Only one of these gets caught in tests. The other defines your blast radius. It does not matter how good your model is. Even flawless generated code, if it runs with full app permissions, exposes your entire system. The risk lives in the execution contract. Ask yourself: who on your team can say, right now, exactly what your generated code is allowed to touch?

The most effective security shift I made this year is surprisingly simple: give your code a verb, not a toolbox. When code needs to act, the default move is to hand it a client; maybe a database connection, a fetch, or an SDK. But that quietly hands over every permission you meant to protect. A general client can go anywhere, and suddenly your boundaries are gone. Expose the operation, not the client. Instead of 𝘧𝘦𝘵𝘤𝘩(𝘶𝘳𝘭), offer 𝘳𝘦𝘤𝘰𝘳𝘥𝘴.𝘧𝘪𝘯𝘥(𝘪𝘥). Your guest receives a focused, promise-returning function. You keep control of credentials, authorization, and validation. Strong security boundaries and great API design are the same discipline. Where in your stack are you handing out a client when a single, well-defined function would be safer and smarter?

A belief worth correcting: "we run it in a worker thread, so it's isolated." A worker thread only isolates the event loop. It does nothing to restrict authority. By default, your worker has full access to the filesystem, network, environment, and process, just like the parent. You changed the location, not the permissions. Order matters. Permissions must drop before the guest code compiles or imports. If you wait, you create a window where your code has more authority than you planned. That gap is all it takes. Without checking, can you list every API your dynamic code can access right now?

We never planned to build a memcached client. But every existing option became the bottleneck in our stack. Gateway request deduplication demanded a client that could handle real production traffic at scale. Nothing out there could keep up. When something sits this close to the hot path, I expect three things: strict opaque-token verification on every response, zero runtime dependencies beyond node:net, and real-world tests against memcached servers with authentication and TLS. This client delivers on all three. What’s the slowest link in your stack that everyone ignores?

Here’s a lesson from @matteocollina deep dive into our memcached client: A single pipelined connection outperformed a ten-connection pool from legacy @nodejs clients. Same server, same loopback, same Node version. 💡 The result? Our approach delivered triple the throughput of the fastest alternative. Why did the old clients need connection pools? They couldn’t pipeline efficiently. With a smarter parser, you unlock performance: pipeline on a single connection, parse by length for speed, and merge writes for efficiency. No extra cost, just better engineering. Pooling still matters when you need to handle large values that could block a pipelined connection. That’s what poolSize is for. But let’s be clear: pooling should solve real scaling problems, not compensate for slow parsing. How many connections does your busiest cache client open, and why?

Can’t wait to join this wonderful conference! I will be talking about @workflowsdk being the most natural foundation for agents like @eve…but…with a twist ;-)

@eve sets the bar for agent frameworks in @nodejs. But beneath that clean API, there’s a layer of invisible infrastructure. One that most teams only notice when they leave Vercel behind. On @vercel, everything just works. Workflow runtime, queue delivery, persistent state, retry logic, deployment version routing; all handled for you, all out of sight. That’s the promise of a truly seamless developer experience. But shift to your own @kubernetesio cluster, and suddenly the invisible becomes visible. You start to see what Vercel was quietly managing behind the scenes: Persistent state that survives pod restarts. Distributed queues for steps across multiple pods. Retry handling when a process fails mid-step. Deployment version routing so in-flight sessions finish on the code that started them. None of this is in the framework. None of it is supposed to be. The framework is the agent model. The infrastructure is the deployment contract, and on Vercel it was invisible. How much of your production infrastructure are you discovering rather than designing? blog.platformatic.dev/run-du…

Too many @nodejs teams still treat AI agents like long-running connections. In production, that mindset holds you back. A truly durable agent session is just a series of queued operations. Every tool call, every wait for user input, every restart, each step is recorded. If a process or pod disappears, another picks up instantly from the last completed step. No gaps, no lost progress. Any pod, any worker, any step, no session affinity, no sticky routing, no need to keep the original process alive. This is true horizontal scalability. The event history is the session. It belongs in persistent storage, not memory. That’s how you build for resilience and scale. The practical result? Scaling durable AI agents becomes as simple as scaling stateless APIs. Add pods, and they immediately join the pool, executing steps across every active session. Ask yourself: what happens in your current agent architecture when a process restarts mid-session? If you can’t answer with confidence, it’s time to rethink your approach. blog.platformatic.dev/run-du…

Pushing new code while an AI agent session is still running is not just a deployment detail. 𝐈𝐭 𝐢𝐬 𝐚 𝐟𝐮𝐧𝐝𝐚𝐦𝐞𝐧𝐭𝐚𝐥 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐧𝐞𝐬𝐬 𝐫𝐢𝐬𝐤. Durable agents capture every action: model calls, tool invocations, waits, user inputs. When a session resumes, the engine replays that exact history against your codebase to rebuild state. If your code has changed since the session began, replay can trigger steps out of sequence, apply results to the wrong logic, or quietly generate the wrong answers. 𝐓𝐡𝐢𝐬 𝐢𝐬 𝐰𝐡𝐞𝐫𝐞 𝐬𝐢𝐥𝐞𝐧𝐭 𝐟𝐚𝐢𝐥𝐮𝐫𝐞𝐬 𝐜𝐫𝐞𝐞𝐩 𝐢𝐧. Every deployment splits your sessions in two: 1️⃣ New sessions that must run on the latest code. 2️⃣ In-flight sessions that need to finish on the version they started with. 𝘠𝘰𝘶𝘳 𝘪𝘯𝘧𝘳𝘢𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦 𝘮𝘶𝘴𝘵 𝘵𝘳𝘢𝘤𝘬 𝘣𝘰𝘵𝘩, 𝘰𝘳 𝘺𝘰𝘶 𝘳𝘪𝘴𝘬 𝘣𝘳𝘦𝘢𝘬𝘪𝘯𝘨 𝘭𝘪𝘷𝘦 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦𝘴. A session paused for human approval might sit idle for days, generating no traffic at all. Quiet does not mean complete. ❓ Does your deployment pipeline actually know which agent sessions are still running right now? If not, you are flying blind. Read more about it ⬇️ blog.platformatic.dev/run-du…

AI agent deployments break the rules of traditional API releases. The old playbook does not apply. If a session begins on v1, whether it's paused for human input, waiting on a tool, or mid-workflow, it must finish on v1. The event history and queued actions are tightly coupled to that version. Forcing them onto v2 is a recipe for unpredictable results. Every deployment leaves you running multiple versions of your agent in parallel. Each active session pins its version until the workflow completes. This is the operational reality. Kubernetes rolling updates are blind to this complexity. They terminate pods without regard for in-flight or paused agent workflows, risking broken sessions and lost work. What’s needed: version-pinned routing, session-aware draining, and real visibility into when an old version is truly done… not just idle. This is the hidden infrastructure challenge behind every 'deploy AI agents to production' story. Ignore it, and you risk downtime, data loss, and broken user experiences.

"Zero downtime deployment" means your server never went offline. It says nothing about the users already on your site when you shipped. They're running old JS bundles, old React state, against a server that's already moved on. Next API call hits an endpoint that no longer exists. Checkout fails. Form resets. Zero downtime. Broken session. Version skew isn't a bug. It's structural. It happens on every deploy. The fix isn't preventing it; it's building systems that let multiple versions run together. Cookies, ingress routing, replica set management, and a control plane that handles the rest. Building this with @matteocollina on Wednesday. 8am PT / 5pm CEST → streamyard.com/watch/RnVyfVT…