Infrastructure update
Wodby infrastructure 4.0.0: app-level routing
Wodby infrastructure 4.0.0 separates application routing from app-service releases. Domains, redirects, TLS certificates, HTTP authentication, and route policies can now move through their own app-instance routing deployment without restarting application workloads.
Envoy Gateway became Wodby's public edge in infrastructure 2.0.0. That move replaced Ingress NGINX with the Kubernetes Gateway API and gave routes, redirects, and published ports a typed model. Infrastructure 4.0.0 takes the next step by giving the routing for an entire app instance one lifecycle and one owner.
Previously, routing resources were rendered by individual app-service Helm releases. The route itself belongs to the app experience, though: a hostname can become the main route, target another service, share app-level authentication, and use a certificate renewed independently of the workload. Splitting those resources across service releases made ownership harder to reason about and tied edge-only changes to service deployment.
One shared Gateway, one routing release per app instance
The cluster still has one shared Gateway managed by Envoy Gateway behind its public load balancer. With Gateway API ListenerSets, each regular app instance contributes its own listeners and keeps the rest of its edge configuration in a dedicated routing release below that shared entrypoint. Envoy Gateway's controller translates these resources into the Envoy data plane that handles the traffic.
Shared cluster entrypoint
One Gateway configures the Envoy data plane behind the cluster load balancer.
App-instance ListenerSet
Each regular app instance contributes its own listeners to the shared Gateway.
Routes and policies
HTTPRoutes, TLS, HTTP auth, redirects, and route policies describe the app edge.
Application services
Routes forward traffic to Kubernetes Services while workload releases stay independent.
App-service releases continue to own Deployments, StatefulSets, Kubernetes Services, configuration, and other runtime resources. The separation follows the actual operational boundary: routing can change while the application containers remain exactly as they are.
What becomes faster and clearer
Independent edge changes
Add a domain, change a redirect, update route settings, or edit HTTP auth without redeploying app-service workloads.
Automatic certificate updates
Certificate issuance and renewal can reconcile the app routing release directly instead of waiting for a service deployment.
One clear owner per app
A single app-instance release owns routes, listeners, TLS, auth, and routing policies, avoiding conflicts between service releases.
Routing deployments update the complete edge configuration for one app instance. If several routing changes arrive while one is running, Wodby combines the pending work and follows up only when another reconciliation is needed. The app can show Updating routing, independently of workload rebuild or redeploy flags.
These deployments are not hidden maintenance. They create normal background tasks with logs and failure state, so automatic work such as post-renewal certificate routing is visible in task history and can be diagnosed without opening an app-service deployment.
A controlled migration for existing applications
Upgrading a cluster to infrastructure 4.0.0 performs the routing ownership handoff automatically for eligible active app instances. It does not create a second set of competing live resources under a new owner.
Validate the cluster edge
Wodby upgrades and verifies Envoy Gateway and the stable Gateway API ListenerSet capability before changing app routing ownership.
Release legacy ownership
Eligible app instances receive a full deployment that removes edge resources from their app-service releases.
Apply the app routing release
Wodby creates one complete routing release for the app instance and records the work as a visible task.
During this one-time handoff, an existing instance can show Migrating routing. Paused instances remain paused and are migrated during their next full deployment after they resume. New apps on infrastructure 4.0.0 start directly with the new ownership model and do not need a migration state.
HTTP and HTTPS are the required baseline
Infrastructure 4.0.0 validates stable ListenerSet support before migration. TCPRoute and UDPRoute remain optional Gateway API capabilities, so a compatible cluster can use the new HTTP and HTTPS model even when one of those published-port protocols is unavailable. Wodby shows the detected capabilities before a port is published.
Available through the cluster infrastructure upgrade
Infrastructure 4.0.0 is the current version for new Wodby clusters. For an existing cluster, open its Infrastructure page to review the available version, detected Gateway API capabilities, and upgrade task.
Read the infrastructure 4.0.0 documentation and the routing deployment reference for the full upgrade and runtime behavior. You can also revisit the infrastructure 2.0.0 Envoy Gateway announcement for the foundation this release builds on.
Ready to review your clusters? Open the Wodby dashboard.