Nitro gives you a clean, portable server. Whether you use it on its own or with Vite, you get consistent builds, familiar routing, and a smooth development workflow. But Nitro doesn’t explain what to do when you have several instances and a cron job, or when you need a gateway, metrics, and worker health checks. Nitro handles the server, but someone still has to manage the whole fleet.
In this episode of The Node (and more) Banter, Luca Maraschi and Matteo Collina talk with Paolo Insogna, Principal Software Engineer at Platformatic, about @platformatic/nitro. This new Watt feature connects Nitro to the Watt runtime without changing your server, build, or development workflow. No matter if you use a standalone Nitro API, a Vite-plus-Nitro frontend, or an app built with Lovable, Watt takes care of operations while Nitro keeps working as usual.
In this episode, we cover:
✅ How @platformatic/nitro works for both standalone Nitro apps and Vite applications that use Nitro as a plugin, and why the distinction matters for your development workflow
✅ What Watt adds without changing your app: gateway integration, HTTP metrics, HTTPS, Event Loop Utilization monitoring, and multi-worker reusePort support
✅ The duplicate scheduled task problem. Why Nitro starts a cron timer inside every instance, and what @platformatic/nitro/scheduler does to give Watt ownership of the clock
✅ How ICC takes over cluster-wide scheduling: one cron per job across the entire fleet, with run history, pause controls, and healthy-instance targeting, while your task code stays inside Nitro
The takeaway?
Nitro is great at building servers. It was never designed to run a fleet. One line in nitro.config is all it takes to hand the operational layer to Watt and ICC, and your routes, handlers, build output, and scheduled tasks stay exactly where they are.
