June 9, 2026
Code, Calculators, Chaos
How we run untrusted customer code at scale
They let customers run risky code — and commenters instantly did the math
TLDR: Nango says it rebuilt how it runs customer-written code so buggy or malicious programs can’t mess with its systems or other users. The comments immediately turned into a scale debate, with one sharp reply reducing the whole story to a simple traffic number and questioning how big this really is.
Nango’s big reveal is basically this: people upload code to their platform, and that code can misbehave, so the company has spent years building safer ways to keep customer programs away from its own systems. They started with a simpler setup, then got spooked after security scares around the tool they were using, split things into separate runners, and eventually moved toward Amazon’s Lambda so each job gets its own little box. In plain English: they’re trying to stop one customer’s bad or buggy code from snooping around, hogging resources, or taking everybody else down with it.
But the real popcorn moment in the community? One commenter, joeblubaugh, cut through the engineering epic with a brutally simple reality check: “60 invocations / second across all tenants.” That one line has the energy of someone walking into a 12-slide startup presentation and circling the only number that matters. The mood was instantly split between “wow, clever security work” and “wait, is this scale actually huge?” It’s classic tech-thread drama: one side praises the careful isolation and the admission that the old setup wasn’t a true safety wall, while the other side hears “150 million runs a month” and starts doing back-of-the-envelope math like it’s a sport.
The humor here is wonderfully nerdy: readers treating the post like a prestige thriller, then yanking it back to earth with calculator-snark. The hottest subtext wasn’t just security — it was whether this was a heroic infrastructure glow-up or a very fancy way to manage what one commenter implied is a surprisingly modest traffic load.
Key Points
- •Nango runs more than 150 million customer-written integration functions per month and treats that code as untrusted.
- •The platform must support low-latency actions, long-running syncs with resumability, and bursty webhooks while maintaining strict isolation and elastic scaling.
- •Nango initially used the vm2 Node.js sandbox in-process, but 2023 sandbox-escape vulnerabilities led it to reject in-process JavaScript sandboxing as a security boundary.
- •Nango then separated execution into a dispatcher and customer-specific runner services, with no direct database access from runners and persistence handled through a separate service.
- •By late 2025, Nango says the runner model had fairness and observability limitations, and AWS Lambda provided per-execution isolation through hardware-virtualized environments.