Nango processes over 150 million customer-written functions monthly across three distinct workloads: on-demand actions requiring fast cold starts, long-running sync jobs spanning hours, and bursty webhook events with unpredictable spikes. Each function is untrusted code that customers write to connect their apps to Salesforce, Slack, Google Calendar, and hundreds of other APIs.

The platform evolved through three architectures after abandoning the vm2 in-process sandbox in 2023. Sandbox-escape vulnerabilities demonstrated that shared processes provide inadequate security boundaries for untrusted code. Nango moved to isolated runners with separate dispatchers, then transitioned to AWS Lambda for hardware-level isolation between executions.

However, Lambda's environment reuse created a tenant isolation problem. Different customers could share warm environments, allowing sandbox escapes to potentially access other customers' credentials. Nango solved this by pinning each customer's executions to dedicated Lambda functions, ensuring warm environments only serve the same customer repeatedly.

This approach increased cold starts from under 1% to roughly 9%, prompting them to keep paid-plan functions warm with periodic invocations. The architecture reflects a fundamental trade-off: per-customer isolation rebuilds always-on infrastructure while they continue working toward stronger sandboxing. Other platforms like E2B and Modal have converged on similar microVM-based isolation strategies.