Today, we’re excited to announce kubernetes.nginx.org, a new community hub for everything NGINX networking on Kubernetes, along with a brand-new Kubernetes community Ingress-NGINX Migration Tool designed to make moving from the Kubernetes community Ingress-NGINX controller to the NGINX Ingress Controller as smooth as possible.

Whether you’re running NGINX Ingress Controller, exploring NGINX Gateway Fabric, or planning a migration to either — we want to make everything NGINX does on Kubernetes easily accessible and discoverable from a single place, whether you’re evaluating your first project or managing multiple NGINX deployments across clusters.

kubernetes.nginx.org brings it all together. Each project page includes feature overviews, version compatibility tables, quick-start installation commands, and direct links to GitHub and documentation — everything you need to get started or go deeper.

Projects:

• NGINX Ingress Controller — A production-grade Ingress API implementation with VirtualServer CRDs, TLS termination, TCP/UDP load balancing, Prometheus metrics, and OpenTelemetry support.
• NGINX Gateway Fabric — Our Gateway API implementation, fully conformant with Gateway API v1.4.1, featuring control/data plane separation, multi-cloud support, traffic splitting, and mTLS.

Migration tools:

• Ingress-NGINX Migration Tool — An interactive, web-based guide that maps your existing Ingress-NGINX annotations to NGINX Ingress Controller equivalents, with a built-in Config Analyzer and ready-to-use output.
• ingress2gateway — A CLI tool that converts Ingress resources to Gateway API resources that you will be able to deploy in NGINX Gateway Fabric, supporting multiple providers including NGINX Ingress Controller and Ingress-NGINX.

With the community Ingress-NGINX controller reaching end of maintenance at v1.15.1, many teams are now evaluating their next steps. One of the most common questions we hear is: “How do I move to NGINX Ingress Controller, and how much work is it going to be?”

The Ingress-NGINX Migration Tool is our answer. It’s an interactive, web-based guide that walks you through the entire migration process — from understanding the architectural differences between the two controllers to generating ready-to-use configuration.

What It Offers

A Config Analyzer that does the heavy lifting. Paste your existing Ingress YAML and the analyzer generates migration suggestions with copy-paste-ready output. It detects your annotations, maps them to their NGINX Ingress Controller equivalents, identifies anything unsupported, and flags the complexity of your migration.

Over 130 annotation mappings. The reference guide provides comprehensive, side-by-side mappings across roughly 40 annotation categories — covering access control, authentication, CORS, rate limiting, SSL/TLS, canary deployments, load balancing, timeouts, and more. Each mapping includes before-and-after YAML examples you can expand and copy directly.

Two migration strategies to match your approach:

• CRD-first (recommended) — Prioritizes VirtualServer resources and Policy CRDs for a more powerful and maintainable configuration model, falling back to annotations only when necessary.
• Annotation-first — Prioritizes annotation-to-annotation mappings where possible, ideal for teams that want to migrate incrementally.

Why It Matters

The two controllers look similar on the surface but differ fundamentally in how they handle configuration. The community Ingress-NGINX controller relies on nginx.ingress.kubernetes.io/ annotations and ConfigMap keys. NGINX Ingress Controller uses Custom Resource Definitions as its primary configuration model, with nginx.org/ annotations.

Manually mapping annotations one-by-one across a fleet of Ingress manifests is tedious and error-prone. The migration tool translates all possible annotations, highlights annotation to CRD migration paths, surfaces edge cases, and gives you a clear picture of what your migration will look like before you start making changes.

And with NGINX Ingress Controller v5.4.0, Policy CRDs can now be referenced directly from Ingress objects via the nginx.org/policies annotation — meaning you don’t have to convert everything to VirtualServer resources to take advantage of CRD-based policies. This significantly reduces the barrier to entry for teams migrating from annotation-heavy configurations.

Both kubernetes.nginx.org and the Ingress-NGINX Migration Tool were built with community feedback at the center. The questions we’ve seen in GitHub issues, NGINX Community forum conversations, and conference hallways directly shaped what we prioritized.

This is a living resource. As the NGINX Kubernetes ecosystem evolves — with new features, new Gateway API conformance profiles, and new tooling — the community hub will evolve with it.

Get Started

• Explore the hub: kubernetes.nginx.org
• Try the Ingress-NGINX migration tool: kubernetes.nginx.org/ingress-nginx-migration.html
• Get migration help: Ingress-NGINX Migration Help on the NGINX Community forum
• NGINX Ingress Controller on GitHub: github.com/nginx/kubernetes-ingress
• NGINX Gateway Fabric on GitHub: github.com/nginx/nginx-gateway-fabric

If you’re at KubeCon Europe 2026, come find us! We’d love to walk you through the hub and migration tool in person, hear what’s working for you, and learn what we should build next.

We’d love to hear your feedback! Open an issue, give the migration tool a spin, or if you have questions about migrating from Ingress-NGINX, head over to the Ingress-NGINX Migration Help section in the NGINX Community forum — we’re there and happy to help.