URL Redirects

📍 Where to find this in the UI

• Network level: Organization → Networks → a network's configuration → URL Redirects
• Customer level: Organization → Customers → a customer's configuration → URL Redirects

A URL redirect is a resource that responds with HTTP 302 on a "source" URL toward a "destination" URL pointing to an existing route of an app, in a given environment. It can be declared at three levels (scopeType), mutually exclusive:

The NETWORK and CUSTOMER scopes — described in the rest of this page — refer to tenants downstream of the app and remain unchanged. The APP scope, described further below, concerns the app itself; it is a dedicated model, not a variant of the other two.

Unlike standard application routing (see URLs and routing), a redirect does not route application traffic: it simply redirects the browser to the final URL.

Source block — immutable after creation

The actual source URL is not entered: it is computed automatically from the subdomain, the domain, and — if the domain is PLATFORM_MANAGED — the app's shortname:

<subdomain>.<target-env-prefix?>.<app-shortname-if-platform-domain?>.<domain>

Important: the environment prefix inserted into the source URL comes from the TARGET environment chosen in the Destination block — there is no environment specific to the source. A direct consequence: changing a redirect's target environment changes its source URL (the DNS is migrated automatically), without ever touching the URL or the infrastructure of the destination itself.

Concrete example:

textCopy
Subdomain          : monclient
Domain             : y.wakastart.app (PLATFORM_MANAGED)
App shortname      : 7owwaa
Target env (prefix): dev

→ Source URL: monclient.dev.7owwaa.y.wakastart.app

Two redirects can share the same subdomain + domain as long as their target environments have different prefixes — there is then no real DNS collision (the env prefix is part of the final FQDN).

Destination block — editable at any time

The destination's domain/host is never entered manually: it derives exclusively from the selected route + environment, recomputed automatically on every change.

Important: modifying the destination (route, environment, path, or query) never deploys or modifies that destination's actual infrastructure. The target AppUrl / route remains managed exclusively by the app's own application architecture — the redirect only updates its own internal HAProxy configuration.

Statuses

Standard Wakastart resource lifecycle:

A drift is detected if the actual URL of the target route has changed since the last reconciliation (for example if the app changed its architecture in the meantime) — the redirect stays functional but needs resynchronization.

Technical mechanism

Wakastart's classic application routing goes through Gateway API + Istio, via an HttpRoute with a RequestRedirectFilter filter for simple redirects. This mechanism is not sufficient here: Gateway API does not support query string rewriting in a redirect, yet Wakastart redirects need to be able to add/modify query parameters.

A dedicated HAProxy component shared across the whole platform (namespace wakastart-redirects) therefore handles the actual rewriting:

textCopy
https://monclient.dev.7owwaa.y.wakastart.app
            │
            ▼
   DnsRecord + ListenerSet + HttpRoute (standard, on the infra API side)
            │
            ▼
   HttpRoute routes to the shared HAProxy Service
   (instead of the classic application Service)
            │
            ▼
   HAProxy reads its map (host → target URL) and responds with 302
            │
            ▼
   https://<computed-host-of-the-target-route>/<path>?<query>

Each redirect therefore creates, on the ws-serv-infra side, the same standard resources as an application route (DnsRecord, ListenerSet, HttpRoute) — the only difference: the HttpRoute points to the shared HAProxy service rather than to an application ServiceInstance.

The effective configuration (host → target URL mapping) is a map_str file generated by the operator and pushed into a ConfigMap. Every change (creation, destination modification, deletion) triggers an automatic rollout of the HAProxy deployment to reload the up-to-date map.

App-scale redirects (App-scope)

The NETWORK and CUSTOMER scopes above address tenants downstream of the app. The APP scope answers a different need: allowing the app team itself to redirect one URL to another within its own app — typically switching between www.mysupersite.com and mysupersite.com.

A dedicated model, not an extension of the existing scopes. The APP scope relies on its own resources (AppUrlRedirect / AppUrlRedirectInstance). The NETWORK/CUSTOMER redirects are not modified and remain managed as described above.

Reserved for CUSTOM domains. As with the apex (see URLs and routing), an App-scope redirect is only possible on a CUSTOM domain attached to the app — never on a shared PLATFORM_MANAGED domain.

AppUrlRedirect (Architecture) → AppUrlRedirectInstance (per environment)

Like the rest of the architecture, an App-scope redirect is declared once, without ever choosing an environment, then instantiated per environment:

The target always remains within the same app: a URL already declared in the architecture, or the app's apex. There is therefore no possibility of an open redirect — the destination is resolved server-side.

Same technical mechanism

An App-scope redirect reuses exactly the shared HAProxy component (wakastart-redirects) described above: same standard resources on the infra API side (DnsRecord, ListenerSet, HttpRoute pointing to the shared HAProxy service), same host → target URL map reloaded on every change. Nothing specific to provision.

Warning on apex source. If the source of an App-scope redirect is the apex (no subdomain), the same blocking confirmation modal as for root-level exposure (see URLs and routing) applies: the platform does not check what already resolves on that domain. A domain also cannot carry both an apex and an apex-source App-scope redirect at the same time.

Known limitations

• RBAC: no fine-grained access control beyond WakaAdmin / OwnerAdmin (full access to redirects), in addition to the standard Network/Customer partitioning.
• Cap: 20 redirects maximum per scope. This is a current technical safety limit, with no functional justification — it may evolve.
• Deletion: unlike other infra resources that block their deletion as long as children exist, deleting a redirect never blocks on the state of its destination — the targeted route/environment is not affected.