Name: Node Congress 2026
Start: 2026-03-26T15:00:00.000Z
End: 2026-03-27T20:00:00.000Z

Lera

Luca Del Puppo

David Pugh

David Barry

Weslley Araújo

Mert Can Altin

Jeroen van Wissen

Thorsten Hell

João Cidade Silva

Mangirdas Darguzis

Alex Hayton

David Passarelli

Boris Karaivanov

khouchane Mahmoud

Vitor Barbosa

Mario Loco

Luca Fregoso

Alex Perez

Tamara

Fathima Fasna

Basseydou OUATTARA

Rob Lark

Emilie Follin

Yakovlev Eugen

eran

Chris

Srikanth Doddi

Hauke Baasch

Sudhakar Kirubakaran

Varun

Arturo Martinez

Va Da

Svetlana Smirnova

Gert-Jan Kooijmans

Cap'n Web es una nueva biblioteca de código abierto que te permite exponer APIs de JavaScript y TypeScript a través de la Web, incluyendo sobre HTTP o WebSocket. A diferencia de casi todos los demás sistemas RPC anteriores, Cap'n Web admite pasar funciones y objetos sobre RPC "por referencia". Esta característica, que suena simple, tiene profundas implicaciones que cambian completamente cómo se diseñan las APIs. En esta masterclass presentaré una serie de ejemplos que muestran cómo usar las funciones y objetos de primera clase de Cap'n Web para implementar una variedad de patrones comunes de diseño de API, como autorización, pub-sub y streaming. Mostraré cómo Cap'n Web puede integrarse bien con marcos de UI reactivos, e incluso tocaré brevemente cómo puede ser una herramienta poderosa para el sandboxing de agentes de IA.

No REST para Cap'n Web

Kenton Varda advocates for using CapnWeb, an RPC protocol, over REST for web APIs, emphasizing benefits for humans and AI agents. CapnWeb simplifies client-server communications by treating them as function calls. TypeScript type checking ensures method accuracy in CapnWeb across JavaScript runtimes. Stubs in CapnWeb allow method calls to execute on remote objects and simulate all possible method names for remote calls. Converting REST APIs to CapnWeb streamlines code and improves API calls. CapnWeb enhances API functionality with object-specific RPC sessions and promises pipelining for multilevel API optimization. AI agent security challenges are addressed with sandboxing and token protection in CapnWeb. CapnWeb capabilities for AI agents include passing restricted CapnWeb stubs and exploring capability-based security with CapnProto.

Cap'n Web is a new open source library that lets you expose JavaScript and TypeScript APIs across the Web, including over HTTP or WebSocket. Unlike almost all other RPC systems before it, Cap'n Web supports passing functions and objects over RPC "by reference". This simple-sounding feature has deep implications that completely change how APIs are designed. In this talk I will present a series of examples showing how to use Cap'n Web's first-class functions and objects to implement a variety of common API design patterns, such as authorization, pub-sub, and streaming. I will show how Cap'n Web can integrate nicely with reactive UI frameworks, and even touch briefly on how it can be a powerful tool for sandboxing AI agents.

No REST for Cap'n Web

Kenton Varda

Has estado implementando Node.js de manera incorrecta. Durante años, la comunidad ha tratado a Node.js como un simple runtime: iniciar un proceso, ponerlo detrás de un proxy inverso, escalar horizontalmente. Pero este enfoque ignora problemas arquitectónicos fundamentales que se vuelven dolorosamente obvios en producción: el cuello de botella del event loop de un solo hilo, la utilización ineficiente de recursos, las herramientas fragmentadas y la complejidad operativa de gestionar múltiples servicios.En esta charla, argumentaré por qué Node.js necesita un servidor de aplicaciones adecuado y por qué construimos Watt para resolver estos problemas. Profundizaremos en la arquitectura: cómo SO_REUSEPORT permite la distribución de carga a nivel de kernel sin la sobrecarga de IPC, cómo múltiples workers dentro de una sola unidad de implementación pueden lograr un escalado casi lineal, y cómo un runtime unificado puede orquestar frameworks de frontend como Next.js junto con microservicios de backend.Verás datos reales de benchmarks: 93% más rápida latencia media en comparación con clusters PM2, 99.8% de fiabilidad bajo carga sostenida y reducciones dramáticas en los costos de infraestructura. Más importante aún, entenderás por qué estas mejoras ocurren a nivel arquitectónico.Ya sea que estés ejecutando Next.js, Fastify, o cualquier carga de trabajo de Node.js que consuma CPU, te irás con una perspectiva fundamentalmente diferente sobre cómo las aplicaciones Node.js deben ser construidas, implementadas y escaladas.Sin magia. Sin exageraciones. Solo mejor arquitectura.

Por qué Node.js necesita un servidor de aplicaciones

Matteo Collina discusses Node.js, its single-threaded design, and the introduction of threads in 2018 for parallelism and CPU utilization. Node.js production monitoring focuses on application health, fault tolerance, and event loop efficiency. VAT architecture improves Node.js applications with thread migration and monitoring. Node.js manages threads and failures independently with Prometheus monitoring. Scalability in Node.js involves Kubernetes clusters and in-process scaling. Next.js with React SSR for Node.js applications enables dynamic scaling and performance. Node.js handles CPU blocking and SSR performance by utilizing multiple threads.

You've been deploying Node.js wrong. For years, the community has treated Node.js as a simple runtime—start a process, put it behind a reverse proxy, scale horizontally. But this approach ignores fundamental architectural problems that become painfully obvious in production: the single-threaded event loop bottleneck, inefficient resource utilization, fragmented tooling, and the operational complexity of managing multiple services.In this talk, I'll make the case for why Node.js needs a proper application server—and why we built Watt to solve these problems. We'll go deep into the architecture: how SO_REUSEPORT enables kernel-level load distribution without IPC overhead, how multiple workers within a single deployment unit can achieve near-linear scaling, and how a unified runtime can orchestrate frontend frameworks like Next.js alongside backend microservices.You'll see real benchmark data: 93% faster median latency compared to PM2 clusters, 99.8% reliability under sustained load, and dramatic reductions in infrastructure costs. More importantly, you'll understand why these improvements happen at the architectural level.Whether you're running Next.js, Fastify, or any CPU-bound Node.js workload, you'll leave with a fundamentally different perspective on how Node.js applications should be built, deployed, and scaled.No magic. No hype. Just better architecture.

Why Node.js Needs an Application Server

Matteo Collina

En Cloudflare tenemos muchos productos. Nuestra especificación REST OpenAPI tiene más de 2.3 millones de tokens. Cuando los equipos querían permitir que los agentes de IA accedieran a sus servicios, hicieron lo que todos hacen: seleccionaron cuidadosamente los endpoints importantes para su producto, escribieron algunas definiciones de herramientas y enviaron un MCP Server que cubría una pequeña fracción de su API.Creo que lo hicimos todo mal.El límite de contexto no es un problema de MCP. Es un problema de Agente. Las herramientas probablemente deberían descubrirse bajo demanda. Los CLIs obtienen esto de forma gratuita, autodetectables y documentados por diseño. Las APIs solo necesitan un poco de ayuda.Esta charla cubrirá cómo funciona Code Mode, por qué los Dynamic Worker Loaders son súper geniales y cómo los sandboxes eficientes serán el gran desbloqueo para los Agentes. <span style="font-size:11pt;font-family:Arial,sans-serif;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap">

Every API is a Tool for Agents with Code Mode

The Talk introduces APIs, Codemode, and MCP, highlighting the role of APIs in empowering agents and AI's access to external resources. CloudFlare's evolution with MCP involves remote tool sharing and addressing challenges like large context windows. Challenges in Cloudflare's API tool access include progressive tool disclosure and splitting MCP servers. The discussion covers tool search, project management API creation, CodeMode concept, and self-documenting tools for secure tool execution. Proposed solutions include Code Mode, SDK generation, efficient control flow, token efficiency, and secure code execution. Key topics include dynamic worker loaders, Cloudflare API integration, Visitor Counter implementation, and exploring MCP server functionality.

At Cloudflare we have a lot of products. Our REST OpenAPI spec is over 2.3 million tokens. When teams wanted to let AI agents access their services, they did what everyone does: cherry-picked important endpoints for their product, wrote some tool definitions and shipped a an MCP Server that covered a small fraction of their API.I think we got it all wrong.The context limit is not an MCP problem. It's an Agent problem. Tools should probably be discovered on demand. CLIs get this for free, self-discoverable and documented by design. APIs just need a little help.This talk will cover how Code Mode works, why Dynamic Worker Loaders are super cool and how efficient sandboxes will be the great unlock for Agents. <span style="font-size:11pt;font-family:Arial,sans-serif;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap">

Matt Carey

Todos conocemos el ritual: agregar una dependencia, confiar en ella implícitamente, enviarla a producción. Durante años, eso funcionó bastante bien. Pero ahora los ataques han comenzado a volverse más inteligentes. Los ataques a la cadena de suministro que apuntan al ecosistema npm ya no son teóricos. Paquetes maliciosos que roban credenciales, secuestran variables de entorno o exfiltran datos silenciosamente a través de HTTP están apareciendo en aumentos de versiones menores. La mayor fortaleza del ecosistema de JavaScript, su apertura, se ha convertido en su mayor responsabilidad. Y luego entregamos nuestros teclados a la IA. Los asistentes de IA son, por supuesto, útiles. Pero introducen una nueva categoría de riesgo: código que no escribiste, no entiendes completamente y que quizás nunca revises lo suficiente. Los modelos pueden filtrar claves de API en la salida generada, el código escrito por IA puede eliminar archivos accidentalmente, su código puede realizar llamadas de red no intencionadas, o peor. Y si alguien ha contaminado los datos de entrenamiento, tu IA podría hacer esto a propósito. En esta charla, recorreremos ejemplos reales de vectores de amenaza, demostraremos cómo el sistema de permisos de Deno puede detener un ataque a la cadena de suministro en seco y exploraremos cómo el sandboxing de la ejecución de tu código puede proporcionarte un entorno genuinamente seguro para ejecutar código generado por IA sin la sobrecarga de levantar infraestructura Docker. Te irás con una imagen más clara del panorama de amenazas y herramientas prácticas para ejecutar código en el que quizás no confíes.

npm install && pray

JavaScript developers face security risks in npm packages with self-replicating worms compromising packages. Supply chain attacks target prolific maintainers leading to unauthorized code injections. Vulnerabilities in package maintainers and implicit trust contribute to successful attacks. Secure package installation practices vary between npm and Deno. AI-generated code introduces new security risks with embedded secrets. Secure AI code execution involves sandboxing for isolation and secure handling of API keys.

We all know the ritual: add a dependency, trust it implicitly, ship it to production. For years, that worked well enough. But now the attacks have started getting smarter. Supply chain attacks targeting the npm ecosystem aren't theoretical anymore. Malicious packages that steal credentials, hijack environment variables or silently exfiltrate data over HTTP are showing up in minor version bumps. The JavaScript ecosystem's greatest strength, its openness, has become its greatest liability. And then we handed our keyboards to AI. AI assistants are, of course, useful. But they introduce a new category of risk: code you didn't write, don't fully understand, and may never review fully enough. Models can leak API keys into generated output, AI-written code can accidentally delete files, their code can make unintended network calls, or worse. And if someone's poisoned the training data, your AI might do this on purpose. In this talk, we'll walk through real examples of threat vectors, demonstrate how Deno's permission system can stop a supply chain attack in its tracks, and explore how sandboxing your code execution can give you a genuinely safe environment to run AI-generated code without the overhead of standing up Docker infrastructure. You'll leave with a clearer picture of the threat landscape and practical tools to execute code you might not trust.

Jo Franchetti

Mientras que el Web streams API proporciona un enfoque uniforme para la transmisión en todos los entornos de ejecución, viene con altos costos de rendimiento y una complejidad de implementación significativa. Podemos, y debemos, hacerlo mejor.

We Deserve a Better Streams API for the Web

James Snell discusses challenges in current stream APIs, proposes a new, faster, and simpler streams API while questioning the existing Web Streams model. Discussion includes the necessity for a new API due to excessive ceremony, confusing locking mechanisms, and complex specifications, especially in controller APIs. Challenges with controller API optimization, hidden buffering, and excessive memory usage are highlighted. The talk delves into the cost and complexity of promises in JavaScript, optimizing readable streams, and managing complexity in stream implementations. Optimizing stream processing in JavaScript, data chunk processing, back pressure policies, multi-consumer patterns, and efficient branch cursor management are explored. The new API aims at simplifying stream processing by eliminating unnecessary operations, reducing promise overhead, and focusing on iterators, transforms, and back pressure for efficiency and simplified design.

While the Web streams API provides a uniform approach to streaming across all runtimes, it comes with steep performance costs and significant implementation complexity. We can, and should, do better.

James Snell

En este masterclass práctico, los participantes aprenderán cómo crear un servidor Model Context Protocol (MCP) listo para producción en Cloudflare Workers. La sesión cubre la definición de endpoints de herramientas, la integración de APIs externas, la persistencia de estado con almacenamiento KV y el despliegue global del servidor para que los asistentes de IA puedan invocar herramientas personalizadas en tiempo real. Al final del masterclass, cada asistente tendrá un servidor MCP en vivo que podrá extender y asegurar para sus propios proyectos de agentes de IA.

Building Model Context Protocol (MCP) Tools for AI Agents with Cloudflare Workers

Workshop on building MCP tools for AI agents with Cloud Flare workers, introducing the model context protocol (MCP) and its significance. Versatility of tools under MCP spec ensuring compatibility across AI agents and tools. Importance of MCP protocol in optimizing AI agents' access to services. Setting up MCP workshop involves Node.js installation and Cloudflare signup. Adding tools to the MCP server extends agent capabilities, enhancing functionality. Connecting to the MCP server using the model context protocol inspector for testing and debugging. Custom tool integration involves defining execution functions for new tool integrations. Upgrading MCP tools to DRAN API for true randomness generation. Deployment and verification of MCP application on Cloudflare for AI chat application connectivity. Integration of external database using Cloudflare KV storage for tool functionality.

In this hands on workshop participants will learn how to create a production‑ready Model Context Protocol (MCP) server on Cloudflare Workers. The session covers defining tool endpoints, integrating external APIs, persisting state with KV storage, and globally deploying the server so AI assistants can invoke custom tools in real time. By the end of the workshop every attendee will have a live MCP server they can extend and secure for their own AI‑agent projects.

Building Model Context Protocol (MCP) Tools for AI Agents with Cloudflare Workers 

Confidence Okoghenun

Los runtimes modernos de JavaScript no solo gestionan objetos de JavaScript, sino que también necesitan recolectar basura de manera segura y eficiente de objetos nativos complejos escritos en C++ y Rust. Esta charla explora cómo se utiliza cppgc (Oilpan) de V8 en Node.js, Deno y Cloudflare Workers, comparando enfoques basados en shim con la integración directa de cppgc y explicando las compensaciones de rendimiento y ciclo de vida detrás de cada diseño.

Garbage Collection Entre V8, cppgc (Oilpan), y Runtimes Nativos

Today's presentation delves into garbage collection challenges in JavaScript and native code, highlighting the impact on memory leaks and bugs. V8's implementation of minor and major garbage collection is discussed. The evolution of memory management in runtimes, including Node.js and Deno, is explored, emphasizing the shift towards automatic cleanup and improved performance. The complexity of runtime memory management, especially in handling CPP objects and bridging with workers, is outlined. Key points include the efficiency gains from generational garbage collection and the importance of migrating away from certain memory management practices for enhanced runtime performance.

Modern JavaScript runtimes don’t only manage JavaScript objects — they also need to safely and efficiently garbage collect complex native objects written in C++ and Rust. This talk explores how V8’s cppgc (Oilpan) is used in Node.js, Deno, and Cloudflare Workers, comparing shim-based approaches with direct cppgc integration and explaining the performance and lifecycle trade-offs behind each design.

Garbage Collection Between V8, cppgc (Oilpan), and Native Runtimes

Esta masterclass cierra la vieja y muy real brecha entre los desarrolladores de Node.js y la producción.Muchos desarrolladores de Node.js pueden construir APIs, servicios y backends que funcionan localmente, pero las cosas se desmoronan cuando llega el momento de contenerizar, desplegar, escalar y operar en entornos reales. Esta masterclass soluciona eso.Aquí es donde Node.js deja de ser "solo código" y se convierte en un sistema de producción confiable.Lo que aprenderás:<ul><li>Dockerizar aplicaciones de Node.js para desarrollo y producción utilizando patrones probados en batalla</li><li>Diseñar imágenes Docker limpias, rápidas y seguras para Node.js</li><li>Construir pipelines CI/CD escalables con GitHub Actions</li><li>Optimizar aplicaciones de Node.js para rendimiento, estabilidad y observabilidad</li></ul>

DevOps para Desarrolladores de JavaScript: Del Código a Producción

Introduction to JavaScript demos and Docker setup, importance of understanding Docker architecture and pitfalls to avoid. Brief history and architecture of Docker, importance in managing applications. Explanation of Docker creation process, encapsulation, image layers, and container runtime pipeline. Docker's significance for JavaScript developers in managing environments and collaborating with DevOps. Node.js Docker guide, AI-assisted Docker file creation, and challenges. Explanation of Alpine vs. Slim for Node.js in Docker. Best practices for Node.js Docker images and Dockerfile construction. Omitting unnecessary files, setting arguments, and user settings in Docker files. Utilizing non-root user for application security. Docker workflow optimization, CI/CD process, and image deployment on Docker Hub.

This workshop closes the old and very real gap between Node.js developers and production.Many Node.js developers can build APIs, services, and backends that work locally—but things fall apart when it’s time to containerize, deploy, scale, and operate them in real environments. This workshop fixes that.This is where Node.js stops being “just code” and becomes a reliable production system.What you’ll learn:<ul><li>Dockerize Node.js applications for development and production using battle-tested patterns</li><li>Design clean, fast, and secure Docker images for Node.js</li><li>Build scalable CI/CD pipelines with GitHub Actions</li><li>Optimize Node.js apps for performance, stability, and observability</li></ul>

DevOps for JavaScript Developers: From Code to Production

Kristiyan Velkov

Los benchmarks están en todas partes, pero la producción rara vez se parece a un benchmark.Esta charla compara Node.js, Deno y Bun desde una perspectiva pragmática y orientada a la producción: depuración, observabilidad, implementación, inicios en frío y el tipo de casos límite que solo aparecen cuando hay usuarios reales y sistemas reales involucrados.

Beyond Benchmarks: Node.js, Deno, and Bun in Real Production

Vinicius Neves emphasizes practical considerations over speed comparisons when choosing a JavaScript runtime. The discussion delves into debugging and observability differences among Node, Dino, and Bun at 3 a.m. Metrics, error tracking, deployment, and serverless capabilities are explored across these runtimes. Serverless deployment challenges and considerations, including CICD integration and deployment target relevance, are highlighted. Serverless cold start performance is compared, with Bun leading, followed by Dino and Node. The talk also emphasizes hiring considerations, NPM compatibility issues, permission models, and testing workloads before committing to a runtime.

Benchmarks are everywhere, but production rarely looks like a benchmark.This talk compares Node.js, Deno, and Bun from a pragmatic, production-first perspective: debugging, observability, deployment, cold starts, and the kind of edge cases that only appear when real users and real systems are involved.

Beyond Benchmarks: node.js, Deno, and Bun in Real Production

 Vinicios Neves

La naturaleza concurrente de Node ya es poderosa, pero a menudo necesitamos sacar trabajo del servidor principal por varias razones. En este trabajo, exploraremos algunos escenarios en los que el trabajo se empuja inteligentemente a otro proceso de Node para resolver. Una vez que usamos una cola para distribuir cargas de trabajo, necesitamos identificar la naturaleza del trabajo a realizar. Para trabajos intensivos en I/O o CPU, el primero ya está perfectamente cubierto por un solo proceso de Node.js; necesitaremos ajustar la configuración del trabajador para que coincida con los recursos disponibles y el rendimiento.

Concurrencia de Node Con la Fuerza de un Toro Con BullMQ

Introducing Node's concurrency with Bull.MQ. Understanding Node's single-threaded JavaScript operation with CPU delegation and parallel processing. Exploring Node's event loop, asynchronous functions, and promise handling for CPU-intensive tasks. Efficient background job processing for improved performance and cost-efficiency, leveraging batch processing and job scheduling during off-peak server times. Challenges include user concurrency, faster responses, error handling, rate limiting, and job orchestration. Tips for transitioning to production, handling Promise All for user concurrency, and optimizing worker concurrency and error handling. Custom error handling, job retry mechanisms, retry strategies, backoff mechanisms, and dynamic rate limits. Managing job completion and failure retention, Flow Producer's job handling, efficient worker management, and horizontal scaling.

Node's concurrent nature is powerful already, but often we need to push work out of the main server for several reasons. In this work, we will explore a few scenarios in which work is cleverly pushed to another Node process to resolve. Once we use a queue to distribute workloads, we need to identify the nature of the work to be done. For either I/O- or CPU-intensive work, the first is already perfectly covered by a single Node.js process; we will need to tweak the worker setup to match the available resources and throughput.

Node's Concurrency With the Strength of a Bull With BullMQ

Edy Silva

Douglas Marques

El reciente artículo de MIT ""Recursive Language Models"" demostró que los LLMs pueden procesar entradas 100x más allá de sus ventanas de contexto, no expandiendo la ventana, sino tratando los prompts como entornos externos que el modelo explora programáticamente. Los resultados son sorprendentes: GPT-5-mini superó a GPT-5 en tareas de contexto largo mientras usaba un cómputo comparable. Esta charla demuestra cómo construir la misma arquitectura en TypeScript usando LangGraph y Node.js.Implementaremos un sistema RLM en el que un agente raíz orquesta sub-agentes recursivos, cada uno operando en un segmento de contexto enfocado sin sufrir ""context rot."" Veremos cómo aprovechar la ejecución de gráficos cíclicos de LangGraph para generar agentes hijos, agregar sus hallazgos en un estado compartido y permitir que el orquestador sintetice resultados, todo mientras mantenemos las ventanas de contexto individuales pequeñas y frescas.Al final, tendrás un patrón de trabajo para procesar documentos masivos, bases de código o conjuntos de datos que ahogarían una sola llamada LLM, usando herramientas que puedes desplegar hoy.Puntos clave:<ul><li>- Por qué las ventanas de contexto más grandes no resuelven el context rot</li><li>- Arquitectura de gráficos de agentes recursivos en LangGraph</li><li>- Gestión del estado y ejecución de herramientas a través de jerarquías de agentes</li><li>- Compromisos de costo y latencia en producción</li></ul>

Rompiendo el Techo del Contexto: Implementación de Modelos de Lenguaje Recursivos con LangGraph y TypeScript

Jamal Legaro discusses challenges with context windows in language models and recursive language models as a solution. Enhancing language model performance through metadata and summaries, orchestrator copies, and comparing scaffold and RLM approaches. Efficient management of language model operations with slicing, recursion, code execution, and context window handling. Graph-based workflow design in Langchain for agent connections and state management. Workflow management, document analysis, and using RLM for processing large documents. Detailed workflow setup, code structure with Langsmith, and node definitions with RLM benefits for cost considerations and production readiness.

MIT's recent ""Recursive Language Models"" paper demonstrated that LLMs can process inputs 100x beyond their context windows — not by expanding the window, but by treating prompts as external environments the model explores programmatically. The results are striking: GPT-5-mini outperformed GPT-5 on long-context tasks while using comparable compute. This talk demonstrates how to build the same architecture in TypeScript using LangGraph and Node.js.We'll implement an RLM system in which a root agent orchestrates recursive sub-agents, each operating on a focused context slice without suffering ""context rot."" We'll see how to leverage LangGraph's cyclic graph execution to spawn child agents, aggregate their findings into a shared state, and let the orchestrator synthesize results — all while keeping individual context windows small and fresh.By the end, you'll have a working pattern for processing massive documents, codebases, or datasets that would choke a single LLM call, using tools you can deploy today.Key takeaways:<ul><li>- Why bigger context windows don't solve context rot</li><li>- Architecting recursive agent graphs in LangGraph</li><li>- Managing state and tool execution across agent hierarchies</li><li>- Cost and latency tradeoffs in production</li></ul>

Breaking the Context Ceiling: Implementing Recursive Language Models with LangGraph and TypeScript

Jamal Sinclair O'Garro

Cada desarrollador de Node.js que añade AI a sus aplicaciones enfrenta la misma elección: pagar por APIs externas o lidiar con alguna inferencia local como Ollama (que también requiere llamadas a API). Pero hay una tercera opción de la que nadie está hablando: ejecutar inferencia de ML *dentro* de tu proceso de Node.js con Transformers.js. En esta charla, te mostraré cómo generar embeddings, clasificar texto y ejecutar LLMs con nada más que `npm install`. Sin claves de API, sin latencia de red, sin procesos separados. Solo JavaScript haciendo aprendizaje automático de la manera que debería ser: simple, rápido y completamente bajo tu control.

Deja de Pagar por APIs de AI: npm Install para Inferencia en Proceso

Introduction by Ed Silva, a Node.js core collaborator, discussing the significance of AI in 2026. Companies facing challenges in AI implementation, focusing on AI integration and the need for developer skills. Demonstrations of Node.js egg cooking using Hug and Face community and model inference with Hug and Face Transformers. Transformers JS extending NLP to computer vision and audio tasks, utilizing O-N-N-X format for model execution. Tasks and examples available in Transformers.js for NLP and computer vision, emphasizing model differentiation and execution processes. Optimization techniques for model download trade-offs, GPU utilization, and experimentation possibilities with models like Hugging Face.

Every Node.js developer adding AI to their apps faces the same choice: pay for external APIs or wrestle with some local inference like Ollama (that also requires API calls). But there's a third option nobody's talking about: running ML inference *inside* your Node.js process with Transformers.js. In this talk, I'll show you how to generate embeddings, classify text, and run LLMs with nothing more than `npm install`. No API keys, no network latency, no separate processes. Just JavaScript doing machine learning the way it should: simple, fast, and fully under your control.

Stop Paying for AI APIs: npm Install Your Way to In-Process Inference

Introducción al ecosistema JS<ul><li>Móvil: React Native y Expo</li><li>Escritorio: Tauri y Electron</li><li>Servidor: Node, Bun y Deno</li></ul>Declaración del problema<ul><li>¿Cómo puedes compartir la lógica multiplataforma? Node, Bun y Deno no pueden reutilizarse en móviles. Escribir en Kotlin y Swift es extremadamente costoso. </li><li>La mayor parte del uso de internet hoy en día ocurre en aplicaciones móviles.</li><li>Esto es aún mayor en economías emergentes donde los smartphones de gama baja son el único dispositivo.</li><li>Bare es la consecuencia de alcanzar limitaciones usando node.js</li></ul>Solución<ul><li>Comparación entre node, deno, bun y bare.</li><li>Cómo enlazar Bare con React Native</li><li>Demostración móvil</li><li>Características clave de bare</li><li>Ligero </li><li>Compatible con Node.js</li><li>Complemento nativo</li><li>Ejecutable único</li><li>Actualizaciones sin preocupaciones</li></ul>

Running JavaScript Actually Everywhere

JavaScript ecosystem enables versatile development for mobile using frameworks like React Native, Expo, and Bear. Challenges arise in porting server logic to mobile due to limitations in reusing core logic between backend and mobile. Bear stands out as a versatile runtime for iOS, Android, React Native, and Expo, allowing selective module integration. The integration of Bear with React Native simplifies mobile app development and background task execution. Bear emphasizes a 'less is more' philosophy, offering flexibility in engine compilation and compatibility with various platforms. It also supports streamlined native add-on development, NAPI support, and controlled upgrades for pushing runtime limits.

Intro JS ecosystem<ul><li>Mobile: React Native and Expo</li><li>Desktop: Tauri and Electron</li><li>Server: Node, Bun and Deno</li></ul>Problem statement<ul><li>How can you share the logic cross-platform? Node, Bun and Deno can’t be reused in mobile. Writing Kotlin and Swift is extremely pricy. </li><li>Most of internet usage today happens in mobile apps.</li><li>This is even greater in emerging economies where low-end smartphones are the only device.</li><li>Bare is the consequence of reaching limitations using node.js</li></ul>Solution<ul><li>Comparison between node, deno, bun and bare.</li><li>How to link Bare with react native</li><li>Mobile demo</li><li>Key characteristics of bare</li><li>Lightweight </li><li>Node.js compatible</li><li>Native add-on</li><li>Single executable</li><li>Worry-less upgrades</li></ul>

Tony Gorez

Construir aplicaciones con TypeScript es la norma hoy en día, pero hay un gran punto de dolor, la velocidad. Al principio, todo funciona sin problemas, pero a medida que tu proyecto crece, los tiempos de compilación se alargan, tu editor se ralentiza e incluso la autocompletación básica del código se vuelve extremadamente lenta. ¿La buena noticia? Una solución ha estado escondida en la documentación de TypeScript durante años, pasada por alto pero increíblemente efectiva. En esta masterclass, descubriremos esta joya oculta, optimizaremos tu configuración y mantendremos TypeScript rápido a medida que tu aplicación escala.

Typescript Es TAN LENTO...¿O No Lo Es?

Mike's enthusiasm for TypeScript, its widespread adoption, benefits in development, and its downside in terms of speed. Exploring TypeScript's slow performance in build speeds and its implications on project deployment in CI environments. Running TypeScript build commands and optimizing build speeds by managing project size. Reducing build times by breaking down large projects into smaller, isolated modules using monorepos. Exploring the limitations of path aliases and the importance of utilizing workspaces for efficient code isolation and faster TypeScript performance. Discussing project references efficiency in TypeScript builds and the impact on compiler and build speed. Discussing the impact of live evaluation on editor speed and how pre-build scripts can significantly improve completion time and overall typing experience. Avoid live evaluation for large projects, consider pre-builds. Discussion on TypeScript port to Go and its impact on future versions. Importance of optimizing project setup for speed and efficiency.

Building apps with TypeScript is the norm these days, but there's one major pain point, speed. At first, everything runs smoothly, but as your project grows, build times drag, your editor lags, and even basic code completion slows to a crawl. The good news? A solution has been hiding in TypeScript’s documentation for years, overlooked but incredibly effective. In this talk, we’ll uncover this hidden gem, optimize your setup, and keep TypeScript fast as your app scales.

Typescript Is SO SLOW...Or Is It?

Mike Hartington

Las aplicaciones de Node.js están cada vez más definidas por su dependency graph, sin embargo, la mayoría de las herramientas aún lo tratan como un efecto secundario opaco. node_modules oculta la estructura, los workspaces se superponen, y entender cómo se relacionan las dependencias (o incluso por qué existen) sigue siendo sorprendentemente difícil.Esta charla introduce el cliente vlt y muestra lo que es posible cuando el dependency graph se trata como un artefacto de JavaScript de primera clase. Al exponer la construcción, resolución, recorrido y consulta del gráfico como primitivas reutilizables de JavaScript, vlt permite tanto potentes flujos de trabajo de CLI como clases completamente nuevas de herramientas programáticas. Construir el cliente en JavaScript asegura que los avances en la gestión de paquetes se retroalimenten directamente en el ecosistema, fortaleciendo el corpus de bibliotecas compartidas y elevando el techo para las herramientas de Node.js.

Desbloqueando el Poder del Dependency Graph

Rui Adorno emphasizes the power of dependency graphs in JavaScript projects, highlighting the underutilized graph structure and the importance of understanding metadata. The discussion delves into advanced dependency selector syntax, integrating query language with VLT client for updates and additions, running tests, and updating versions. The exploration of VLT client features includes secure package installs, phased installation processes, and DSS capabilities. Multi-project package filtering is expanded through DSS query language with a host local selector for benefits like script inspection and AI agents.

Node.js applications are increasingly defined by their dependency graph, yet most tooling still treats it as an opaque side effect. node_modules hides structure, workspaces are layered on, and understanding how dependencies relate (or even why they exist) remains surprisingly difficult.This talk introduces the vlt client and shows what becomes possible when the dependency graph is treated as a first-class JavaScript artifact. By exposing graph construction, resolution, traversal, and querying as reusable JavaScript primitives, vlt enables both powerful CLI workflows and entirely new classes of programmatic tooling. Building the client in JavaScript ensures that advances in package management feed directly back into the ecosystem, strengthening the shared library corpus and raising the ceiling for Node.js tooling.

Unlocking the Power of the Dependency Graph

Ruy Adorno

Node.js introduce --experimental-config-file, una nueva bandera experimental que permite cargar un archivo node.config.json al inicio. Aunque agrega otro archivo de configuración, esta poderosa adición finalmente permite a los desarrolladores personalizar la ejecución de Node.js de maneras que antes eran imposibles. Esta charla explora las capacidades desbloqueadas por esta característica, incluyendo un comportamiento de tiempo de ejecución afinado, mejor portabilidad y posibles extensiones futuras.

One Config File To Rule Them All

Marco Ippolito discusses the complexities of configuring NodeJS features and the need for a centralized config file. He explains the challenges of managing multiple flags for different features and demonstrates how to enhance developer experience by using specific flags to address TypeScript integration and testing procedures. The text discusses the challenges of managing multiple configuration flags in NodeJS and introduces the concept of using node options as an alternative to passing numerous flags directly after the node command. Node options provide a solution for managing configuration flags in NodeJS, simplifying the command structure and enabling the use of .mfile for configuration settings. I sent a PR to introduce the experimental config file feature in Node.js, including two major flags: experimental default config file and experimental config file, allowing customization of configuration settings through JSON files with version-matched schemas for IDE support and auto-completion. V8 flags in Node.js provide customization options, with a priority hierarchy among CLI, Node options, and config files, excluding no-op flags. Node 25 introduces new namespaces for test configuration, watch settings, and permissions, simplifying the configuration process and enhancing developer experience. Node.js JSON configuration offers convenience with a built-in JSON parser and plans for more namespaces and explanatory text in the JSON schema to simplify configuration management.

Node.js introduces --experimental-config-file, a new experimental flag that enables loading a node.config.json file at startup. While it adds yet another config file, this powerful addition finally allows developers to customize Node.js execution in ways that were previously impossible. This talk explores the capabilities unlocked by this feature, including fine-tuned runtime behavior, improved portability, and potential future extensions.

Marco Ippolito

Has estado allí: las pruebas de Node.js pasan tanto localmente como en CI. Despliegas con confianza. Luego, el entorno de staging revela la verdad: errores que solo aparecen con colaciones reales de Postgres 16, límites de conexión reales de Redis o el comportamiento de partición de Kafka que tus mocks en memoria nunca capturaron.La solución son Testcontainers.Testcontainers es una biblioteca de pruebas que proporciona APIs fáciles y ligeras para iniciar pruebas de integración con servicios reales envueltos en contenedores Docker. Usando Testcontainers, puedes escribir pruebas que hablen con el mismo tipo de servicios que usas en producción sin mocks o servicios en memoria. Inícialos, ejecuta migraciones, ejecuta tu servicio Node.js contra ellos, verifica resultados, limpieza automática.En esta charla, te mostraremos cómo usar Testcontainers con AWS CDK y AWS Lambda Node.js APIs para enviar código más rápido, con pruebas más sólidas y un pipeline de CI/CD más confiable.

Pruebas similares a producción en CI/CD con Testcontainers y Node.js

Welcome to a talk on testing Node.js apps in production using Test Container. Developing features, passing unit tests, and deploying can be smooth. Issues post-deployment due to integration gaps are common. Test Container library facilitates real-world integration testing by encapsulating services in Docker containers. Enhancing Docker Compose with Test Containers streamlines container management. Running tests with Redis Docker image and testing with Walkie Container demonstrate easy service swapping. Dynamic port allocation and image loading considerations for isolated infrastructure.

You’ve been there: Node.js tests pass both locally and in CI. You deploy with confidence. Then staging reveals the truth—bugs that only appear with real Postgres 16 collations, actual Redis connection limits, or Kafka partition behavior your in-memory mocks never captured.The solution are Testcontainers.Testcontainers is a testing library that provides easy and lightweight APIs for bootstrapping integration tests with real services wrapped in Docker containers. Using Testcontainers, you can write tests talking to the same type of services you use in production without mocks or in-memory services. Spin them up, run migrations, execute your Node.js service against them, assert results, auto-cleanup.In this talk, we’ll show you how to use Testcontainers with AWS CDK and AWS Lambda Node.js APIs to ship code faster, with stronger tests and a more reliable CI/CD pipeline.

Production-like Testing in CI/CD with Testcontainers and Node.js

John Nguyen

Proporcionaré un análisis en profundidad de las iniciativas lideradas por el Equipo de Seguridad de Node.js, explorando su importancia y los beneficios que aportan a los usuarios finales. Desde 2022, hemos logrado muchas tareas y el objetivo de esta charla es mostrar las iniciativas concluidas, destacando los avances realizados en el fortalecimiento de la seguridad de las aplicaciones Node.js. Además, revelaré lo que puedes esperar de los próximos lanzamientos, ofreciendo un vistazo al futuro de la seguridad de Node.js. Desde la gestión de vulnerabilidades hasta prácticas de codificación segura y más allá, esta charla te equipará con valiosos conocimientos sobre las medidas tomadas para mejorar la protección y garantizar un entorno Node.js más seguro.

El Estado de la Seguridad de Node.js

Introducing Node.js security overview, defining vulnerabilities, non-vulnerabilities, and preventive measures. Discussing Node.js API input validation, real vulnerabilities like HTTP server crashes, and the importance of Node.js security in widely used platforms. Discussing the importance of Node.js maintenance, the introduction of experimental permissions in Node.js 20, and the seatbelt philosophy to protect against malicious code. Discussing the importance of maintaining up-to-date Node.js versions and using tools like npx isMyNodeVulnerable for security checks. Discussing the importance of Node.js security releases, funding, and dependency vulnerability assessment for a safer Node.js environment. Using Node.js Dependency Vulnerability Assessment to evaluate and address potential vulnerabilities, ensuring automated security checks and updates for a safer Node.js environment. Automating Node.js security release process, including configuration files for dependencies, extensive testing across various environments, and creating security release issues and blog posts automatically. Support for various environments, extensive testing with over 55 suites and 5,000 unit tests, automation efforts to streamline processes, and the establishment of a maintenance threat model for enhanced security measures. For a single pull request, it takes six hours to run tests, automation efforts in progress, maintenance threat model to address security risks, permission model roadmap, ongoing discussions on security reports, and plans for the Node.js Collaborator Summit. Active community involvement in Node.js security development, four security releases from 2024 to 2026 addressing various vulnerabilities, end-of-life version strategy with Node.js 16 and 18 having high weekly downloads, and the approach to issuing CVEs for end-of-life versions. Node.js project's strategy adjustment for CVEs to include end-of-life versions, importance of Node.js threat model, trust boundaries, and developer responsibilities. Node.js protection against network data, upgrade recommendations for different Node.js versions, and upcoming changes in Node.js release schedule.

I will provide an in-depth analysis of the initiatives led by the Node.js Security Team, exploring their significance and the benefits they bring to end-users. Since 2022, we've accomplished a lot of tasks and the goal of this talk is to showcase the concluded initiatives, highlighting the advancements made in fortifying the security of Node.js applications. Furthermore, I'll unveil what you can expect from upcoming releases, offering a glimpse into the future of Node.js security. From vulnerability management to secure coding practices and beyond, this talk will equip you with valuable insights into the measures taken to enhance protection and ensure a more secure Node.js environment.

The State of Node.js Security

Rafael Gonzaga

¿Cómo es crear un test runner desde cero? Más que eso: ¿cómo pruebas un test runner?En esta charla, desgloso Poku, un test runner que facilita las pruebas para Node.js, Bun, Deno y tú.Aprenderás sobre el poder de los subprocesos, el aislamiento y las ventajas de trabajar con concurrencia. Todo esto utilizando solo características nativas del lenguaje.También entenderás cómo es posible, en menos de 200kB, crear un test runner completo y ejecutar la misma suite de pruebas a través de todos los runtimes de JavaScript para backend.

Creando un Test Runner: ¿Qué Sucede Detrás de las Pruebas?

Hey everyone, Wesley introduces unique cache runners. Creating a test runner from scratch to understand application workings with different models like BAM and Gnu. Testing scenarios reveal errors with Node.js and model definitions. BAM issues arise from gestures and mishbang conflicts while running tests. Isolation problems occur as gest loses context between runtimes. Common conflicts in test processing modes affect CLI projects and workers, posing challenges for project maintenance and runtime compatibility. Complexity of test dependencies across various runtimes challenges test runners. Emphasis on precise testing aligned with JavaScript coding philosophy. Configuration complexities for beginners in setting up tests with specific extensions and experimental features. Understanding Jest behavior and challenges in aligning test flows with JavaScript. Confusion for beginners in test execution sequencing and expectations. Importance of creating boilerplates for test execution control. Creating a custom test runner to support different runtimes and simplify testing processes. Importance of understanding the challenges faced by junior developers in test setup. Implementing a procedural approach to test execution across various runtimes. Creating subprocesses to run files across various runtimes, ensuring tests run consistently. Implementing a test executor to handle runtimes and subprocess creation efficiently. Enhancing performance by managing test files, concurrency, resource allocation, and memory usage. Introducing assert in testing for user simplicity and efficient reporting. Emphasizing developer experience and the philosophy behind project creation.

What's it like to create a test runner from scratch? More than that: how do you test a test runner?In this talk, I break down Poku, a test runner that makes testing easy for Node.js, Bun, Deno, and you.You will learn about the power of subprocesses, isolation, and the advantages of working with concurrency. All of this using only native language features.You will also understand how it is possible, in less than 200kB, to create a complete test runner and run the same test suite through all JavaScript runtimes for backend.

Creating a Test Runner: What Happens Behind the Tests?

Ejecuta tu proyecto sin ahogarte en configuraciones. Para escenarios comunes, puedes hacerlo sin configuración a través de simples extensiones usando la API de Customización de Node (no necesitas saber qué es eso). Puede ser tan simple como decirle a Node que quieres usar CSS modules y tsx: module.register('@nodejs-loaders/css-module').

Node Just Run

Using Node to simplify common tasks in local environments and CI. Customization hooks and extending Node for additional file types are discussed by Jacob Smith. Node's need to understand different file types for main.tsx. Avoid using bundlers for local environments. Extending Node with customization hooks for asynchronous work is discussed. Spinning up infrastructure for async work is crucial. Utilize single responsibility principle for handling specific functionalities like CSS modules and media URLs. Collection of loaders/customization hooks simplifies integration with Node for various tasks. You don't need extensive knowledge of the inner workings. A demonstration highlights the usefulness of this approach in web development. Using customization hooks can significantly improve testing efficiency and speed. Node can spin up quickly without needing additional time. Minimal configuration is required, focusing on CSS modules and media URLs. Small, encapsulated functionalities do one thing, not heavily interacting with each other. Alternatives like Vite and Vitest are popular but may not offer the same performance as Node alone. Customization hooks allow precise usage, unlike solutions with a broader scope. The size impact difference is significant, with tiny customization hooks compared to larger alternatives, showing similar performance in tests.

Run your project without drowning in configuration. For common scenarios, you can do, config-free via simple extensions using node's Customization API (you don't need to know what that is). It can be about as simple as telling node you want to use css modules and tsx: module.register('@nodejs-loaders/css-module').

Jacob Smith

He estado contribuyendo a un Conformance Test Suite para el proyecto Node.js: Para que los implementadores de Node-API lo ejecuten en diferentes motores de JavaScript y entornos de ejecución, como Bun, Deno y React Native. Quiero compartir la motivación del proyecto, las decisiones arquitectónicas, el progreso que hemos logrado hasta ahora y las técnicas clave utilizadas para garantizar que la implementación se mantenga independiente del entorno de ejecución.

Construyendo el Conformance Test Suite de Node-API

Kane introduces a Node.js project for a conformance test suite aiming to address compatibility issues across different runtimes like Deno and React Native. The suite ensures standardized tests for Node API, abstracting V8 for Node.js internals. It focuses on cross-runtime standardization, test porting progress, and calls for contributors to address challenges in Node API testing.

I've been contributing a Conformance Test Suite to the Node.js project: For Node-API implementors to run across different JavaScript engines and runtimes, such as Bun, Deno and React Native. I want to share motivation for the project, architectural decisions, the progress we've made so far and key techniques used to ensure the implementation stays runtime agnostic.

Building the Node-API Conformance Test Suite

Kræn Hansen

Want to master Fullstack: JS Backend, DevOps, Architecture? Join a two-day conference on all things Node.js, gathering Back-end and Full-stack engineers across the globe in the cloud is here to help you staying up-to-date on the latest Node.js tech.

Node Congress

I’m attending @NodeCongress, the biggest conf on #JavaScript backends – by clicking the badge you may get a free remote ticket & join me there with 5k other #nodejs devs & 15 great speakers #deno #cloudflare #awscloud

Master Fullstack: JS Backends, DevOps, Architecture and more! The conference on all things Node.js, DevOps, Edge-native workers (Cloudflare &amp; others), Serverless, Deno &amp; other JavaScript backend runtimes, gathering Back-end and Full-stack engineers across the globe.

Node Congress 2026

FocusReactive

Hygraph

Cloudflare

Tether.io

<a href="https://workers.cloudflare.com/" target="_blank" rel="noopener noreferrer">Cloudflare’s Developer Platform</a> lets you ship software without managing infrastructure. Modern apps need to connect users, data, and services securely and reliably. Deploy once, run everywhere on our global network. We offer primitives for compute, data, media, and AI, simplifying development and lowering costs while ensuring scalability and performance.

FocusReactive is an&nbsp;<meta charset="utf-8" id="isPasted">engineering-led <a href="https://focusreactive.com/" target="_blank" rel="noopener noreferrer">Headless CMS Development Company</a>&nbsp;and&nbsp;<a href="https://focusreactive.com/next-js-expert-agency/">NextJS development experts</a>. Independent partners of Payload CMS, Sanity, Storyblok, Vercel and Shopify. Delivering&nbsp;<meta charset="utf-8" id="isPasted">Composable content platforms built for AI SEO, growing teams, and marketing velocity.