We manage infrastructure applications such as Vault and Argo Workflows with Terraform, Helm, and Argo CD. Terraform creates the Argo CD ApplicationSet, the applications point to charts and values stored in Git, and Argo CD handles synchronization.
As we migrate from Ingress to Gateway API, I've noticed that many third-party charts either do not support Gateway API yet or only provide an option to create an HTTPRoute. With Ingress, a single values block usually handled the whole setup, including annotations, hosts, and paths.
Gateway API often requires additional resources that a chart may not provide, such as ReferenceGrants for cross-namespace references or controller-specific policies like Envoy Gateway's SecurityPolicy and BackendTrafficPolicy. For example, a chart may create an HTTPRoute but leave the rest of the routing and security configuration to the user.
For now, we create a manifests directory for each application and add it as another source in the Argo CD ApplicationSet. That directory contains the Gateway API and Envoy Gateway resources needed for the application.
How are others handling Gateway API resources for third-party charts? Is the expectation that charts will eventually expose more Gateway API settings, or should routing and policy resources remain separate from application charts? I'm trying to understand what the longer-term convention is likely to be as more applications add Gateway API support.
4 Answers
If the chart supports an extraObjects-style value, I put the Gateway API resources there. Otherwise, I keep them in a separate manifests source managed by the Argo CD application. Some charts also expose a small extra-resources mechanism, which can preserve the one-switch deployment experience without making the chart own every platform detail.
A separate manifests directory is a perfectly normal solution. If a chart can’t render everything cleanly in one Helm pass, we either manage the extra resources separately or patch the output with Kustomize, depending on which approach is less fragile.
The cleanest boundary is usually for the platform to own GatewayClass, Gateway, ReferenceGrant, and controller-specific policies, while the application owns its HTTPRoute. A shared Gateway can serve many routes, and keeping policies outside the application chart avoids coupling every third-party chart to a particular controller, namespace layout, or security model.
It helps to define an explicit contract: stable Gateway names and sections, which namespaces are allowed, and which policy references are permitted. CI can then verify that parentRefs and backend references still line up after chart upgrades.
The split you’re using is probably closer to the long-term model than just a temporary workaround. Gateway API is intentionally role-oriented: platform teams manage the shared entry points, application teams describe routes, and the platform or security layer controls cross-namespace access and policies.
I’d expect upstream charts to improve HTTPRoute support, but not necessarily to template every controller-specific resource. For teams that still want a single application-level switch, a small internal wrapper chart can expose one simple option while keeping the Gateway and policy ownership in the platform layer.
That’s the frustrating part: the separate-resource model is sensible, but it breaks the simple one-values-file deployment flow that Ingress provided. Wrapping the route in a small internal chart has been a useful way to restore that convenience without pushing platform-specific policies into every upstream chart.