Clusterward renders Ingress or Gateway API resources for every service, shows the controller’s default for every network setting, and switches between ingress-nginx and Envoy Gateway without a single host going down.
Networking & ingress in Clusterward is the layer between the internet and your service: for every service, Clusterward generates the Kubernetes Ingress for ingress-nginx, or a Gateway and HTTPRoute for Envoy Gateway, with TLS, redirects and IP allowlists per domain. On top of that come network settings such as timeouts, retries, rate limits, CORS, basic auth and sticky sessions – described once and translated for both controllers. Moving a service to a different controller runs as a cutover in which both load balancers serve the hosts until DNS has moved.
Host on the service, with TLS via Let’s Encrypt, wildcard or Cloudflare.
The service’s own class or the cluster default, visible in the Network block.
Timeouts, limits and protection, each next to its default value.
Ingress, or Gateway and HTTPRoute; outdated objects are removed.
First a plan per host, then both load balancers serve traffic until DNS has moved.
Everything that is otherwise scattered across annotations and policy objects sits on one card per service.
The same setting is translated into annotations for ingress-nginx and into HTTPRoute and policies for Envoy Gateway. Anything a controller can’t do is flagged on the card instead of being silently dropped.
Requests per second or minute with burst, limited by address range or per header value such as an API key. Envoy additionally caps connections and pending requests.
Request, connection and idle timeouts; retries with per-attempt timeouts and triggers. Every field shows the default – for example, 60 instead of 15 seconds.
CORS rules, password protection from an environment variable and blocked address ranges per service. If the basic auth variable is missing, the deployment aborts instead of leaving the host open.
Before it starts, Clusterward shows for every host what happens to DNS and the certificate. During the cutover, the old and the new load balancer serve the hosts with valid certificates; Clusterward moves its own records and completes the switch one hour after every host points to the new address.
Proxy protocol on the Scaleway Load Balancer and Cloudflare’s address ranges ensure that apps and IP allowlists see the real visitor.
The widely used ingress controller, with annotations per service.
Gateway API with a shared proxy fleet and a single load balancer.
Certificates via HTTP-01 or DNS-01, including for Gateway API.
With proxy protocol; status and type visible in the cockpit.
Most settings apply to both controllers. Where they don’t, the card tells you.
| Setting | Supported by |
|---|---|
| Request and connection timeouts | nginx and Envoy |
| Retries with triggers | nginx and Envoy |
| Rate limit per address or header | Envoy; basic limit also nginx |
| CORS and basic auth | nginx and Envoy |
| Body size and buffering | nginx |
| Circuit breakers and header rules | Envoy |
| IP allowlist per domain | nginx and Envoy |
Hosts, certificates and DNS records belong to DNS & certificates. Clusterward installs and updates the controllers themselves via Cluster updates.
Which addresses can reach your workspace at all is governed by the IP allowlist under Security & access.
Cloudflare zones, automatic records, managed wildcard certificates.
Go to DNS & certificatesGit, container image or Helm chart – rolled out with a health check.
Go to DeploymentsKubernetes version, node pools and add-ons from the cockpit.
Go to Cluster updatesCan’t find your question? Write to us – we usually reply on the same business day.
Ask a questionWe set a rate limit, protect a host with basic auth and switch a service from nginx to Envoy Gateway without any downtime.
