Envoy Gateway Doesn’t Support SSI. We Migrated 20+ EKS Clusters Anyway.
How We Migrated 20+ EKS Clusters from ingress-nginx to Envoy Gateway Without Rewriting a Single Application
Platform migrations rarely happen at the perfect time.
NEOZO migration from ingress-nginx to Envoy Gateway started as a strategic initiative. We had already been evaluating Kubernetes Gateway API and saw it as the future of traffic management in Kubernetes. The ecosystem was moving beyond the traditional Ingress model, and we wanted our platform to evolve with it.
Originally, the plan was straightforward: migrate gradually, validate patterns across teams, and roll out the new architecture over time.
Then reality accelerated the timeline.
Ongoing security concerns around ingress-nginx, combined with its evolving maintenance and support situation, turned what had been a long-term modernization effort into a time-critical platform migration. Suddenly, we needed a clear path forward for more than 20 Amazon EKS clusters, hundreds of routes, and a significant portion of our customer-facing infrastructure.
At first glance, replacing one ingress controller with another didn’t seem particularly difficult.
It wasn’t.
The real challenge was preserving years of application behavior that had become deeply embedded in our platform.
Most notably, large parts of our web platform relied on Server Side Includes (SSI), a feature Envoy Gateway does not support.
For many organizations, that would have been a migration blocker.
For us, it became the most interesting part of the project.
In the end, we migrated more than 20 production EKS clusters to Envoy Gateway, adopted Gateway API, modernized our traffic management stack, and built a custom Envoy WASM extension that allowed us to preserve SSI support without changing application code.
This article shares the challenges we encountered, the architectural decisions we made, and the lessons we learned along the way.
Understanding the Real Migration Challenge
Over the years, our ingress-nginx deployment had evolved far beyond a simple ingress controller.
It had become a critical platform layer supporting:
- Rewrite rules
- Regex-based routing
- Header manipulation
- OAuth integrations
- Custom snippets
- NGINX maps
- Annotation-driven traffic behavior
Some of these capabilities translated cleanly into Gateway API resources such as HTTPRoute. Others required Envoy-specific extensions. A few forced us to rethink how certain routing patterns should be implemented.
As we analyzed our existing configuration, it became clear that the migration was less about replacing ingress-nginx and more about understanding years of accumulated traffic-management logic.
Migrating Authentication
Authentication was another important migration area.
Our ingress-nginx deployment relied heavily on oauth2-proxy integrations to protect internal applications. Requests were authenticated before reaching backend services.
With Envoy Gateway, we moved to Envoy-native authentication mechanisms while preserving the existing authentication flow and security model.
The result was a cleaner implementation that aligned better with the Gateway API ecosystem and reduced reliance on ingress-controller-specific configuration patterns.
The Biggest Blocker: SSI
While routing and authentication required work, neither represented the biggest challenge.
SSI did.
Our web platform relies heavily on Server Side Includes to assemble pages dynamically from multiple fragments at request time.
A simplified example looks like this:
<html>
<body>
<!--#include virtual="/header" -->
<!--#include virtual="/content" -->
<!--#include virtual="/footer" -->
</body>
</html>
This pattern has been part of our architecture for years and powers significant portions of our web presence.
Unfortunately, Envoy Gateway provides no native SSI support.
Without a solution, migrating to Envoy Gateway would either require application rewrites or additional infrastructure components.
Neither option was attractive.
Evaluating Our Options
We evaluated three possible approaches.
Option 1: Move to Commercial NGINX
The first option was migrating to F5 NGINX and continuing to use native SSI support.
While technically viable, this conflicted with our goal of remaining within the open-source ecosystem and continuing our adoption of Gateway API.
Option 2: Introduce Varnish and Migrate to ESI
Another option was placing Varnish in front of Envoy Gateway and replacing SSI with Edge Side Includes (ESI). This approach would have worked, but it introduced two significant drawbacks.
First, we would need to rewrite existing SSI templates and modify application behavior.
Second, it would introduce another critical component into the request path, increasing operational complexity and maintenance overhead.
We wanted to avoid both.
Option 3: Extend Envoy
The final option was the most ambitious.
If Envoy Gateway didn’t support SSI, perhaps we could add support ourselves.
Fortunately, Envoy’s WebAssembly extension model made that possible.
Building SSI Support with Envoy WASM
Instead of changing our applications, we decided to extend Envoy.
Using Envoy’s WASM SDK for Go, we built a custom HTTP filter capable of processing SSI directives during response handling.
The filter performs five core tasks:
- Intercepts HTML responses
- Detects SSI directives
- Fetches referenced fragments
- Assembles the final document
- Returns the rendered response to the client
From the application’s perspective, nothing changed.
Existing SSI templates continued to work exactly as before, allowing us to preserve years of investment while modernizing the underlying gateway infrastructure.
This approach provided several advantages:
- No application rewrites
- No SSI-to-ESI migration project
- No additional proxy layer
- Full compatibility with Envoy Gateway
- Continued use of open-source technologies
Most importantly, it transformed what appeared to be a migration blocker into a platform capability we could continue to evolve.
Rolling Out Across 20+ EKS Clusters
Once the major compatibility gaps were solved, rollout became an exercise in standardization and validation.
We introduced Gateway API resources incrementally, migrated traffic route by route, and continuously compared behavior against the existing ingress-nginx implementation.
Particular attention was given to:
- Rewrite behavior
- Authentication flows
- Header propagation
- Caching interactions
- SSI rendering correctness
By treating the project as a platform migration rather than a controller replacement, we were able to move clusters gradually while minimizing risk.
Lessons Learned
The biggest lesson from this migration is that infrastructure migrations are rarely about infrastructure alone.
Replacing ingress-nginx with Envoy Gateway was relatively straightforward.
Preserving years of accumulated application behavior was the real challenge.
Gateway API provided a cleaner and more future-proof traffic management model, but success depended on understanding every platform capability our applications relied on and finding practical ways to preserve them.
The most interesting outcome wasn’t the migration itself.
It was discovering that Envoy’s extensibility allowed us to carry a legacy capability forward without compromising our architectural goals.
By combining Gateway API, Envoy Gateway, and a custom WASM-based SSI filter, we migrated more than 20 EKS clusters while keeping our applications unchanged, our architecture simple, and our platform fully open source.