Nitro is a toolkit for building a platform and runtime-agnostic web servers with clear and portable standards.
This document describes the principles by which the project is governed.
Nitro was created and is led by Pooya Parsa.
Nitro is committed to staying open source, with transparent and open governance. It aims to serve all frameworks and vendors openly, neutrally, and without lock-in. The project provides an inclusive and safe space for participation from framework maintainers, library authors, individual community members, and deployment providers.
In most cases, contributors are invited to the GitHub organization and Discord servers to support deeper involvement.
Nitro is designed to be fully agnostic in terms of technology choices. Not just during the initial setup, at any point, users should be able to make or revise decisions with minimal effort.
Nitro is committed to fairness, supporting both hosted and self-hosted solutions equally. It does not favor any option, other than providing clear information about the differences. Where needed, abstraction layers are used to offer a consistent experience.
For vendor-specific features, Nitro may support them under clearly prefixed namespaces. These are only added on a case-by-case basis, approved by the project lead, or implemented as standalone modules or plugins outside the core framework.
Instead of competing with other projects, Nitro focuses on delivering the best possible Nitro + XYZ integration.
Nitro follows its independent roadmap and core values, defined by the project lead. These values may not always align directly with those of other projects or platforms.
Features are not added for the sake of feature parity. They are evaluated based on their real value, alignment with Nitro’s roadmap, and the benefits they bring to the wider ecosystem.
New features may take longer to plan and implement, as Nitro prioritizes long-term support and broad compatibility. Rushing new primitives into the core is unacceptable; instead, such features should be developed externally as optional modules or plugins.
Nitro supports deployment providers through agnostic libraries and built-in presets. Presets can range from simple metadata for a specific provider to more advanced integrations with Nitro's built-in features.
Nitro avoids direct dependencies on provider SDKs, CLIs, or boilerplates, as these can lead to vendor lock-in. Any vendor-specific integration that is not a core Nitro feature should be developed outside the core framework.
Nitro embraces web standards, collaborates with initiatives like WinterCG, and supports popular runtimes such as Node.js, Deno, and Bun.
Nitro only introduces new conventions when there is a clear lack of standards and strives to minimize the introduction of opinionated patterns.
Abstractions like Nitro can sometimes introduce limitations.
To address this, Nitro aims to offer enough flexibility and customization options so users can modify nearly any part of it. If something isn’t customizable, it's considered an area for improvement.
However, misusing Nitro or relying on it in unintended ways can harm users and create a fragile ecosystem. It may also make future changes in Nitro difficult, as backward compatibility becomes harder to maintain.
To protect both users and the ecosystem, Nitro should discourage reliance on internal or undocumented APIs without clear context. Such access should be reserved for advanced users who fully understand the risks and implications.
Many thanks to NuxtLabs and individual sponsors for their generous financial support. Nitro is actively maintained and developed as a free and open project for everyone.
All changes to this document should be approved by project lead.