Gloo Solo

Gloo provides gateways that sit in front of application services and decide how requests reach them. Teams use gateway policies to centralize behavior such as authentication, routing and traffic limits instead of implementing it separately in every service. The historical Gloo name now spans distinct product generations, including Gloo Edge and Gateway API-based offerings. Identify the installed generation before choosing documentation or assuming its policies transfer to another Gloo-related product.

Deployment and operating notes

The historical Gloo URL now sits in a documentation family that distinguishes Gloo Edge, Gloo Gateway using Kubernetes Gateway API, and Solo Enterprise for kgateway. The old description does not identify which API or product generation a current installation uses. Shared vendor and Envoy ancestry do not make chart values, policies or licenses interchangeable.

Inventory installed charts, CRDs, VirtualServices or HTTPRoutes, Upstreams, authentication, rate limiting and enterprise features. Use the migration guide for that exact source and target generation, and check supported Kubernetes and Gateway API versions. Translate behavior such as rewrites, retries, TLS origination and external authorization into explicit acceptance tests. Run the replacement proxy on a separate address before moving a subset of traffic. Preserve original objects and certificates and keep the old route available until denied requests and failure responses match expectations. Do not delete old CRDs as a cleanup step until every dependent object and rollback requirement is understood.