Nango, una plataforma de integraciones de API definida por código, ejecuta cada mes más de 150 millones de funciones escritas por sus clientes en tres tipos de carga muy distintos: Actions bajo demanda que deben arrancar rápido, Syncs de larga duración que replican datos durante horas y webhooks con picos impredecibles. Como el código no es confiable, el entorno de ejecución debe aislarlo de los sistemas internos, entre clientes y entre ejecuciones, manteniendo al mismo tiempo elasticidad y costes controlados.
La compañía empezó con vm2, un sandbox de Node.js en proceso, pero lo abandonó en 2023 tras una serie de vulnerabilidades de escape de sandbox que llevaron al responsable del proyecto a archivarlo. Nango dividió entonces su sistema en un dispatcher y runners dedicados por cliente, sin acceso directo a la base de datos y delegando la persistencia en un servicio independiente.
A finales de 2025, el modelo de runner compartido presentó problemas de equidad de recursos y observabilidad, por lo que Nango migró a AWS Lambda. Cada ejecución corre ahora en su propio microVM de Firecracker con aislamiento a nivel de hardware, lo que permite atribuir problemas de memoria y CPU a una única función. Para adaptarse al límite de 15 minutos de Lambda, Nango limitó las ejecuciones de Syncs a 10 minutos e introdujo un sistema de puntos de control que permite reanudar la sincronización entre invocaciones.
El reto más difícil fue el aislamiento entre clientes. Como Lambda reutiliza entornos calientes, dos clientes podrían acabar en el mismo, y un escape de sandbox podría filtrar las credenciales de la siguiente invocación. Nango asignó a cada cliente sus propias funciones Lambda, de modo que un entorno caliente nunca se reutiliza entre tenants. La tasa de arranques en frío pasó de menos del 1% a alrededor del 9%, un inconveniente que mitigan con invocaciones periódicas de prueba en los planes de pago.