zuplo 7.10.0 → 7.11.1

package/docs/ai-gateway/bedrock-mantle.mdx

@@ -83,10 +83,8 @@ Streaming (`stream: true`) works on all three serving endpoints.
 
 On the OpenAI-compatible side, endpoint support is per model, decided by AWS:
 
-- The GPT-5.x models (`openai.gpt-5.6-sol`, `openai.gpt-5.5`, and family) serve
-  the Responses API only. Sending one to `/v1/chat/completions` returns Mantle's
-  own error that the model doesn't support that API.
-- The GPT-OSS models (`openai.gpt-oss-120b`, `openai.gpt-oss-20b`) serve both
+- The GPT-5.x models (`openai.gpt-5.6-sol`, `openai.gpt-5.5`, and family) and
+  the GPT-OSS models (`openai.gpt-oss-120b`, `openai.gpt-oss-20b`) serve both
   chat completions and the Responses API.
 - Most of the other models serve chat completions only, and answer
   `/v1/responses` with an error.
@@ -319,8 +317,8 @@ serves both APIs, so it can be confusing—support is per model family, per the
 [endpoint table](#supported-endpoints-by-model-family).
 
 **Mantle answers that the model doesn't support the API.** Endpoint support is
-per model on the OpenAI-compatible side—the GPT-5.x models serve only
-`/v1/responses`, and most other models serve only `/v1/chat/completions`. Check
+per model on the OpenAI-compatible side. The GPT-5.x and GPT-OSS models serve
+both endpoints, but most other models serve only `/v1/chat/completions`. Check
 the **APIs supported** row on the model's AWS model card.
 
 **A model in the picker fails at request time.** The model picker lists Mantle's

package/docs/ai-gateway/fallback.mdx

@@ -11,14 +11,17 @@ out, or an applicable usage limit is exceeded, instead of returning an error to
 the caller. They're configured with the **Fallback Model** policy in the app's
 [policy chain](./policy-chains.mdx).
 
-The AI Gateway offers two independent fallback mechanisms, each triggered by a
-different condition:
+The AI Gateway offers two fallback mechanisms, each triggered by a different
+condition:
 
 | Mechanism              | Triggers when…                                                                                         | Without a fallback set…                     |
 | ---------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------- |
 | **Fallback & Timeout** | The primary fails with a retryable error (`5xx`, `408`, `425`, `429`), a network failure, or a timeout | The gateway returns the error to the caller |
 | **Quota Fallback**     | An app, pool, or gateway usage limit is exceeded                                                       | The request is blocked with a `429`         |
 
+If you set both, the fallback also backs up the quota fallback. For details, see
+[How the two fallbacks combine](#how-the-two-fallbacks-combine).
+
 Both are configured entirely in the Zuplo Portal, and either can route to _any_
 provider—the fallback doesn't have to share the primary's provider. Fallback
 models are referenced like any model, as `providerName/model`.
@@ -82,21 +85,41 @@ toward every applicable limit.
 
 ## How the two fallbacks combine
 
-The mechanisms are evaluated independently and can both be active on the same
-app:
+Both fallbacks can be active on the same app. The fallback model backs up
+whichever model the request goes to first:
 
-- A request that's **over quota** routes to the quota fallback model.
-- A request that's **within quota** but hits an **error or timeout** on the
-  primary routes to the error and timeout fallback model.
+- A request that's **within quota** goes to the primary model. If the primary
+  fails with a retryable error or times out, the request moves to the fallback
+  model.
+- A request that's **over quota** goes to the quota fallback model. If the quota
+  fallback fails the same way, the request moves to the fallback model.
 
-Set whichever fallbacks match the failure modes you want to protect against.
-Neither is required.
+As a result, an over-quota request can still run on the fallback model. Set
+whichever fallbacks match the failure modes you want to protect against. Neither
+is required.
 
 :::note
 
-Error and timeout fallback applies to Chat Completions and Embeddings requests.
-Requests to the native `/v1/messages` and `/v1/responses` endpoints pass through
-without retrying a backup model; the quota fallback still applies to them.
+On Chat Completions and Embeddings requests, the fallback covers every failure
+that the **Fallback & Timeout** row lists. Other requests follow narrower rules:
+
+- **Responses and Messages requests** (`POST /v1/responses` and
+  `POST /v1/messages`) move to the fallback only on a `429`. The gateway first
+  retries the primary twice, after 250 ms and then after 500 ms. The request
+  moves only if the primary still returns `429` and the fallback model serves
+  the same endpoint. A `5xx` error, a network failure, or a timeout doesn't move
+  the request, and the fallback timeout doesn't apply. Over quota, these
+  requests use the quota fallback only if it serves the endpoint. Otherwise, the
+  gateway returns `429`.
+- **Token counting requests** (`/v1/messages/count_tokens`) never use the
+  fallback. Over quota, they use the quota fallback only if it can count tokens.
+  Otherwise, the gateway returns `429`.
+- **[System One](./jev.mdx) requests** (`/v1/systemone`) and requests that
+  retrieve, delete, or list the input items of a stored response never use
+  either fallback. Over quota, the gateway returns `429`.
+
+No model serves both `/v1/responses` and `/v1/messages`. If your clients call
+both endpoints, each fallback model covers at most one of them.
 
 :::
 

package/docs/articles/waf-ddos-akamai.md

@@ -9,59 +9,47 @@ configured to run as a custom origin behind Akamai.
 ## Securing Zuplo from Direct Access
 
 With any WAF product, you will want to ensure that network traffic can't bypass
-your WAF and hit your Zuplo Gateway directly. Akamai offers several ways to
-ensure that your gateway is only accessible through the WAF.
+your WAF and hit your Zuplo Gateway directly. To do that, every request from
+Akamai must prove that it came from **your** Akamai property, not just from
+Akamai's network.
 
-The information below is a summary of Akamai's own recommendations for securing
-your backend - regardless of whether you are using Zuplo, another gateway, or
-Akamai origins. You can reference the
-[Akamai documentation](https://techdocs.akamai.com/application-security/docs/origin-server-protection).
+Use one of these:
 
-### IP Address Restrictions
+| Method                                        | How it works                                                                                                       |
+| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| [Shared secret header](#shared-secret-header) | Akamai adds a secret header to every request it forwards. The gateway rejects requests without it.                 |
+| [Mutual TLS](#mutual-tls-mtls)                | Akamai presents a client certificate when it connects to the gateway. The gateway rejects connections without one. |
 
-Akamai maintains a list of IP addresses that you can use to restrict access to
-your Zuplo Gateway. This is a good way to ensure that only Akamai can access
-your gateway. However, as Akamai is a multi-tenant service, this method isn't
-sufficient to protect unauthorized traffic from hitting your gateway.
+:::warning
 
-In Zuplo, you can use a
-[custom code policy](../policies/custom-code-inbound.mdx) to limit traffic to
-only the Akamai IP addresses. Add a module in your project (for example,
-`modules/ip-restriction.ts`) that allows only your permitted IP ranges, then
-configure the policy with the IP ranges that Akamai publishes for your account
-in Akamai Control Center.
+Don't rely on Akamai IP addresses alone. Akamai's edge IP ranges, including the
+[Origin IP ACL](https://techdocs.akamai.com/origin-ip-acl/docs/update-your-origin-server)
+ranges, are shared by every Akamai customer. Anyone with an Akamai account can
+configure a property that points at your gateway and sends traffic from those
+addresses. Akamai's own
+[guidance](https://techdocs.akamai.com/origin-ip-acl/docs/recommendations-and-caveats)
+states that Origin IP ACL "isn't a substitute for authentication". See
+[IP-based restrictions](#ip-based-restrictions).
 
-```json
-{
-  "name": "allow-akamai-only",
-  "policyType": "custom-code-inbound",
-  "handler": {
-    "export": "default",
-    "module": "$import(./modules/ip-restriction)",
-    "options": {
-      "allowedIpAddresses": ["23.32.0.0/11", "104.64.0.0/10"]
-    }
-  }
-}
-```
+:::
 
-With this policy in place, only Akamai traffic will be allowed to hit your Zuplo
-Gateway.
+The rest of this section summarizes Akamai's recommendations for securing an
+origin. For the full details, see the
+[Akamai documentation](https://techdocs.akamai.com/application-security/docs/origin-server-protection).
 
-### Custom Headers
+### Shared Secret Header
 
-Another way to ensure that traffic is coming from Akamai is to use custom
-headers. Custom headers can be added to your Akamai configuration and then
-checked by your Zuplo Gateway. This provides an additional layer of security on
-top of IP address restrictions and prevents any unauthorized traffic from
-hitting your gateway - regardless of the source.
+A shared secret header is the simplest option, and it works on every Zuplo plan.
 
-In Akamai, you can configure custom headers using the Property Manager or the
-Akamai API. Add a custom header with a secret value that only you and Akamai
-know.
+In Akamai, use the
+[Modify Incoming Request Header](https://techdocs.akamai.com/property-mgr/docs/modify-incoming-req-header)
+behavior in Property Manager to add a header, such as `x-akamai-auth`, with a
+long random value. Store the same value in Zuplo as a secret
+[environment variable](./environment-variables.mdx) named
+`AKAMAI_SECRET_HEADER_VALUE`.
 
-In Zuplo, you can use a small custom code policy to limit traffic to only those
-requests that include the custom header and secret value.
+In Zuplo, add a small custom code policy that rejects requests without the
+header and secret value.
 
 ```ts title="modules/require-akamai-header.ts"
 import {
@@ -94,59 +82,79 @@ export default async function policy(
 }
 ```
 
-With this policy in place, only requests that include the custom header with the
-secret value will be allowed to hit your Zuplo Gateway.
-
-## Additional Akamai Origin Security Options
+Add this policy first in the inbound policy list of every route. With it in
+place, only requests that carry the secret value reach your Zuplo Gateway. Treat
+the value like any other credential: rotate it periodically by updating the
+Akamai behavior and the environment variable together.
 
-Akamai provides several additional security features to protect your origin
-servers beyond IP restrictions and custom headers:
+### Mutual TLS (mTLS)
 
-### Mutual TLS (mTLS) Authentication
+Mutual TLS authenticates Akamai with a certificate instead of a header value.
+It's the strongest option, and there's no secret in the request for anything
+downstream to log or leak.
 
-Use mutual TLS to establish secure, certificate-based authentication between
-Akamai edge servers and your origin. This ensures only authenticated Akamai
-servers can connect to your backend.
+1. In Akamai, upload a client certificate to the
+   [mTLS Origin Keystore](https://techdocs.akamai.com/property-mgr/docs/mtls-origin-keystore)
+   and attach it to your property's origin.
+2. In Zuplo, upload the CA certificate that issued it and add the
+   [`mtls-auth-inbound`](/docs/policies/mtls-auth-inbound) policy to your
+   routes. See
+   [Client mTLS authentication](./securing-the-gateway-with-client-mtls.mdx).
 
-Learn more:
-[mTLS Origin Keystore](https://techdocs.akamai.com/property-mgr/docs/mtls-origin-keystore)
+Use a CA that issues certificates only for Akamai. CA certificates in Zuplo are
+scoped to your account, so any client certificate that the CA issues passes the
+check.
 
-### Origin IP Access Control List
+### IP-Based Restrictions
 
-Configure an IP-based access control list that specifically defines which Akamai
-IP addresses can access your origin servers. This provides more granular control
-than general IP restrictions.
-
-Learn more:
-[Origin IP ACL](https://techdocs.akamai.com/origin-ip-acl/docs/welcome)
+Akamai maintains a list of IP addresses that you can use to restrict access to
+your Zuplo Gateway. This is a good way to ensure that only Akamai can access
+your gateway. However, Akamai is a multi-tenant service, so this method isn't
+enough on its own to keep unauthorized traffic from reaching your gateway. Use
+it **in addition to** a shared secret header or mTLS, never instead of one.
+
+1. In Akamai, add the
+   [Origin IP Access Control List](https://techdocs.akamai.com/origin-ip-acl/docs/set-up-origin-ip-acl)
+   behavior to your property, in the same rule as the Origin Server behavior.
+   Without this behavior, requests to your origin can come from any Akamai edge
+   address, not just the Origin IP ACL ranges.
+2. In Zuplo, add the
+   [IP Address Restriction](/docs/policies/ip-address-restriction-inbound)
+   policy with the
+   [Origin IP ACL ranges](https://techdocs.akamai.com/origin-ip-acl/docs/update-your-origin-server).
+   The ranges below were current when this page was written. Check Akamai's list
+   before you use them.
 
-### Site Shield
+```json
+{
+  "name": "allow-akamai-ips",
+  "policyType": "ip-address-restriction-inbound",
+  "handler": {
+    "export": "IpAddressRestrictionInboundPolicy",
+    "module": "$import(@zuplo/runtime)",
+    "options": {
+      "allow": [
+        "2.16.0.0/13",
+        "23.0.0.0/12",
+        "23.192.0.0/11",
+        "23.32.0.0/11",
+        "95.100.0.0/15",
+        "184.24.0.0/13",
+        "2a02:26f0::/32",
+        "2600:1400::/24",
+        "2405:9600::/32"
+      ]
+    }
+  }
+}
+```
 
-Site Shield provides a dedicated set of IP addresses that Akamai uses to connect
-to your origin servers. This creates a more predictable and secure connection
-pattern between Akamai and your backend infrastructure.
+Akamai changes these ranges from time to time and announces the changes through
+the Firewall Rules Notification tool.
+[Subscribe to it](https://techdocs.akamai.com/firewall-rules/docs/subscribe-to-notifications)
+so you can update the policy before old ranges are retired.
 
-Learn more:
 [Site Shield](https://techdocs.akamai.com/site-shield/docs/welcome-site-shield)
-
-### Authentication Token 2.0
-
-Implement token-based authentication for origin requests. This method allows you
-to validate that requests are coming from legitimate Akamai edge servers using
-cryptographic tokens.
-
-Learn more:
-[Auth Token 2.0](https://techdocs.akamai.com/property-mgr/docs/auth-token-2-0-ver)
-
-### Custom Request Headers with Shared Secrets
-
-Configure Akamai to modify incoming request headers and add shared secret values
-that your origin can validate. This is similar to the custom header approach
-mentioned above but provides more advanced header manipulation capabilities.
-
-Learn more:
-[Modify Incoming Request Header](https://techdocs.akamai.com/property-mgr/docs/modify-incoming-req-header)
-
-These security measures can be used individually or combined to create multiple
-layers of protection for your Zuplo Gateway when running behind Akamai App & API
-Protector.
+is an alternative to Origin IP ACL that uses a smaller set of addresses. Like
+Origin IP ACL, it restricts where traffic comes from but doesn't authenticate
+your property, so pair it with a shared secret header or mTLS.

package/docs/dedicated/akamai/architecture.mdx

@@ -22,8 +22,9 @@ components:
    Zuplo Gateway instances based on geographic location, health status, and load
    balancing policies.
 3. **Zuplo Gateway** - Deployed on Akamai Connected Cloud, the gateway handles
-   authentication, authorization, rate limiting, and request routing. Origin IP
-   ACL ensures only Akamai edge servers can reach the gateway.
+   authentication, authorization, rate limiting, and request routing. A shared
+   secret header or mTLS ensures only your Akamai property can reach the
+   gateway.
 4. **Backend Services** - Your origin servers can be hosted on Akamai compute,
    customer VPCs, on-premise data centers, or public cloud providers.
 
@@ -55,7 +56,7 @@ to Zuplo and your backend services:
   </DiagramGroup>
   <DiagramEdge from="client" to="cdn" />
   <DiagramEdge from="cdn" to="gtm" fromSide="bottom" toSide="top" />
-  <DiagramEdge from="gtm" to="gateway" label="Origin IP ACL" />
+  <DiagramEdge from="gtm" to="gateway" label="Shared secret or mTLS" />
   <DiagramEdge from="gateway" to="backend" />
 </Diagram>
 
@@ -66,8 +67,9 @@ to Zuplo and your backend services:
 2. **CDN to GTM** - The edge server forwards the request to Akamai Global
    Traffic Manager, which determines the optimal Zuplo instance to handle the
    request.
-3. **GTM to Zuplo** - GTM routes the request to a Zuplo Gateway. Origin IP ACL
-   ensures only traffic from Akamai's edge network reaches the gateway.
+3. **GTM to Zuplo** - GTM routes the request to a Zuplo Gateway. The gateway
+   accepts the request only if it carries your shared secret header or presents
+   your mTLS client certificate.
 4. **Zuplo to Backend** - The Zuplo Gateway processes the request (applying
    policies, authentication, rate limiting) and forwards it to your backend
    services.
@@ -91,23 +93,31 @@ to continuously monitor the health of your Zuplo deployments. When a gateway
 fails health checks, GTM automatically routes traffic to healthy instances,
 providing seamless failover.
 
-### Secure connectivity with Origin IP ACL
+### Securing the connection from Akamai to Zuplo
 
-The connection between Akamai edge servers and Zuplo Gateways uses
-[Origin IP ACL](https://techdocs.akamai.com/origin-ip-acl/docs/welcome) to
-restrict access to the gateway. Origin IP ACL ensures that only requests from
-Akamai's edge network can reach your Zuplo origin. This provides:
+Every request that reaches the gateway must prove it came from **your** Akamai
+property. We recommend one of these:
 
-- **Origin protection** - Requests to your Zuplo gateway can only originate from
-  Akamai's edge servers
-- **Simplified management** - Akamai maintains a stable list of CIDR blocks to
-  configure in your firewall
-- **Automatic updates** - Subscribe to Akamai's Firewall Rules Notification tool
-  to receive alerts when IP ranges change
+- **Shared secret header** - Akamai adds a secret header to every request it
+  forwards, using the
+  [Modify Incoming Request Header](https://techdocs.akamai.com/property-mgr/docs/modify-incoming-req-header)
+  behavior. The gateway rejects requests without it.
+- **Mutual TLS** - Akamai presents a client certificate from its
+  [mTLS Origin Keystore](https://techdocs.akamai.com/property-mgr/docs/mtls-origin-keystore),
+  and the gateway rejects connections without one.
 
-All traffic between Akamai edge and origin uses TLS encryption. Origin IP ACL
-adds an additional layer of access control by restricting which IP addresses can
-connect to your gateway.
+You can add
+[Origin IP ACL](https://techdocs.akamai.com/origin-ip-acl/docs/welcome) as an
+extra layer that limits connections to Akamai's edge IP addresses. Don't use it
+on its own: the Origin IP ACL ranges are shared by every Akamai customer, and
+Akamai
+[states](https://techdocs.akamai.com/origin-ip-acl/docs/recommendations-and-caveats)
+that it "isn't a substitute for authentication".
+
+For setup steps for each option, see
+[Securing Zuplo from direct access](../../articles/waf-ddos-akamai.md#securing-zuplo-from-direct-access).
+
+All traffic between Akamai edge and origin uses TLS encryption.
 
 ## Multi-region deployment
 
@@ -266,7 +276,6 @@ deployment, see [Setting up Akamai CDNs](./cdn.mdx). This guide covers:
 
 - Property hostname configuration for Zuplo Gateway and developer portal
 - Origin server settings with host header forwarding
-- Origin IP ACL configuration for secure edge-to-origin connectivity
 - Caching behaviors for API responses
 
 ## Next steps

package/docs/dedicated/akamai/cdn.mdx

@@ -1,6 +1,6 @@
 ---
 title: Setting up Akamai CDNs
-sidebar_label: Akamai CDN
+sidebar_label: CDN Setup
 ---
 
 <!-- vale Vale.Spelling["Edgescape","Maxage"] = NO -->

package/docs/dedicated/aws/architecture.mdx

@@ -0,0 +1,50 @@
+---
+title: "Managed Dedicated: AWS Architecture"
+sidebar_label: Architecture
+description:
+  How a Zuplo Managed Dedicated instance runs on AWS, and what you need to know
+  to connect clients and backends to it.
+---
+
+A Managed Dedicated instance on AWS runs in its own VPC, in an AWS account that
+Zuplo manages, in the AWS region you choose. Zuplo provisions, operates, scales,
+and upgrades the instance. You don't need an AWS account to use it, but you need
+one to connect it to backends in your own VPC.
+
+For the components that make up every Managed Dedicated instance, see
+[Architecture](../architecture.mdx).
+
+## Availability
+
+The gateway runs across multiple availability zones in your region, and the load
+balancer in front of it spreads traffic across zones. If one zone fails, the
+other zones keep serving traffic.
+
+To run in more than one region, contact your account manager.
+
+## Inbound traffic
+
+Clients reach the gateway through a public, internet-facing load balancer. Zuplo
+terminates TLS and manages the certificates, including for your
+[custom domains](../custom-domains.mdx).
+
+To put a CDN or WAF, such as Amazon CloudFront with AWS WAF, in front of the
+gateway, make sure clients can't bypass it and call the gateway directly. Have
+the CDN add a shared secret header that the gateway checks, or authenticate the
+CDN with
+[client mTLS](../../articles/securing-the-gateway-with-client-mtls.mdx).
+
+## Outbound traffic and IP addresses
+
+The gateway reaches the internet through NAT gateways, one per availability
+zone, each with a fixed public IP address. If your backend or a third-party API
+allowlists callers by IP address, ask your account manager for these addresses.
+
+## Connecting to your backends
+
+The gateway can call any backend it can reach over the internet. To keep backend
+traffic off the public internet, use PrivateLink, VPC peering, or Transit
+Gateway. See [AWS Private Networking](./private-networking.mdx).
+
+However your backend is reached, make sure it only accepts requests from your
+gateway. See [Securing your backend](../../articles/securing-your-backend.mdx).

package/docs/dedicated/{aws-private-networking.mdx → aws/private-networking.mdx}

@@ -1,6 +1,6 @@
 ---
 title: "Managed Dedicated: AWS Private Networking"
-sidebar_label: AWS Private Networking
+sidebar_label: Private Networking
 ---
 
 Zuplo Managed Dedicated can run on AWS and connect privately to backends that
@@ -133,7 +133,7 @@ patterns to expect.
 
 ## Next steps
 
-- Review the general [Managed Dedicated networking](./networking.mdx) overview
-- Review [Managed Dedicated architecture](./architecture.mdx)
+- Review the general [Managed Dedicated networking](../networking.mdx) overview
+- Review [Managed Dedicated architecture](../architecture.mdx)
 - [Schedule time with Zuplo](https://book.zuplo.com) to review your AWS network
   design

package/docs/dedicated/azure/architecture.mdx

@@ -0,0 +1,49 @@
+---
+title: "Managed Dedicated: Azure Architecture"
+sidebar_label: Architecture
+description:
+  How a Zuplo Managed Dedicated instance runs on Azure, and what you need to
+  know to connect clients and backends to it.
+---
+
+A Managed Dedicated instance on Azure runs in its own virtual network (VNet), in
+an Azure subscription that Zuplo manages, in the Azure region you choose. Zuplo
+provisions, operates, scales, and upgrades the instance. You don't need an Azure
+subscription to use it, but you need one to connect it to backends in your own
+VNet.
+
+For the components that make up every Managed Dedicated instance, see
+[Architecture](../architecture.mdx).
+
+## Availability
+
+The gateway runs across the availability zones in your region. If one zone
+fails, the other zones keep serving traffic.
+
+To run in more than one region, contact your account manager.
+
+## Inbound traffic
+
+Clients reach the gateway through a public load balancer. Zuplo terminates TLS
+and manages the certificates, including for your
+[custom domains](../custom-domains.mdx).
+
+To put a CDN or WAF, such as Azure Front Door, in front of the gateway, make
+sure clients can't bypass it and call the gateway directly. Have the CDN add a
+shared secret header that the gateway checks, or authenticate the CDN with
+[client mTLS](../../articles/securing-the-gateway-with-client-mtls.mdx).
+
+## Outbound traffic and IP addresses
+
+The gateway reaches the internet through a NAT gateway with a fixed public IP
+address. If your backend or a third-party API allowlists callers by IP address,
+ask your account manager for this address.
+
+## Connecting to your backends
+
+The gateway can call any backend it can reach over the internet. To keep backend
+traffic off the public internet, use Private Endpoint or VNet peering. See
+[Azure Private Networking](./private-networking.mdx).
+
+However your backend is reached, make sure it only accepts requests from your
+gateway. See [Securing your backend](../../articles/securing-your-backend.mdx).

package/docs/dedicated/{azure-private-networking.mdx → azure/private-networking.mdx}

@@ -1,6 +1,6 @@
 ---
 title: "Managed Dedicated: Azure Private Networking"
-sidebar_label: Azure Private Networking
+sidebar_label: Private Networking
 ---
 
 Zuplo Managed Dedicated can run on Azure and connect privately to backends that
@@ -160,7 +160,7 @@ patterns to expect.
 
 ## Next steps
 
-- Review the general [Managed Dedicated networking](./networking.mdx) overview
-- Review [Managed Dedicated architecture](./architecture.mdx)
+- Review the general [Managed Dedicated networking](../networking.mdx) overview
+- Review [Managed Dedicated architecture](../architecture.mdx)
 - [Schedule time with Zuplo](https://book.zuplo.com) to review your Azure
   network design

package/docs/dedicated/{advanced → configuration}/host-header-override.mdx

@@ -20,7 +20,7 @@ expects aren't the same:
   web server hosts several sites and picks one based on the `Host` header. Your
   gateway connects to the shared address and names the site it wants.
 - **Private networking.** With
-  [private networking](../aws-private-networking.mdx), you reach a backend
+  [private networking](../aws/private-networking.mdx), you reach a backend
   through an internal endpoint or IP whose DNS name doesn't match the public
   hostname the backend is configured for, such as `https://10.0.4.12` with a
   `Host` of `api.acme.com`.

package/docs/dedicated/configuration/overview.mdx

@@ -0,0 +1,30 @@
+---
+title: "Managed Dedicated: Configuration"
+sidebar_label: Overview
+description: Settings in zuplo.jsonc that apply to Managed Dedicated projects.
+---
+
+Managed Dedicated projects use the same `zuplo.jsonc` file as every other Zuplo
+project. A few settings in that file are specific to Managed Dedicated. This
+page lists them. For every other setting, see
+[Project Configuration](../../programmable-api/zuplo-json.mdx).
+
+```jsonc
+{
+  "version": 1,
+  "projectType": "managed-dedicated",
+}
+```
+
+## Managed Dedicated settings
+
+| Setting                   | Description                                                                                                                                   |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
+| `projectType`             | Set to `"managed-dedicated"` for projects that deploy to a Managed Dedicated instance.                                                        |
+| `allowHostHeaderOverride` | Lets your code set a `Host` header that differs from the request URL. Off by default. See [Host Header Override](./host-header-override.mdx). |
+
+## Editing zuplo.jsonc
+
+The `zuplo.jsonc` file isn't editable in the Zuplo Portal. Connect your project
+to [source control](../source-control.mdx) and edit the file there, or push a
+local change with git. Changes take effect on your next deployment.

package/docs/dedicated/gcp/architecture.mdx

@@ -0,0 +1,51 @@
+---
+title: "Managed Dedicated: GCP Architecture"
+sidebar_label: Architecture
+description:
+  How a Zuplo Managed Dedicated instance runs on Google Cloud, and what you need
+  to know to connect clients and backends to it.
+---
+
+A Managed Dedicated instance on Google Cloud runs in its own VPC network, in a
+Google Cloud project that Zuplo manages, in the region you choose. Zuplo
+provisions, operates, scales, and upgrades the instance. You don't need a Google
+Cloud project to use it, but you need one to connect it to backends in your own
+VPC.
+
+For the components that make up every Managed Dedicated instance, see
+[Architecture](../architecture.mdx).
+
+## Availability
+
+The gateway runs across multiple zones in your region. If one zone fails, the
+other zones keep serving traffic.
+
+To run in more than one region, contact your account manager.
+
+## Inbound traffic
+
+Clients reach the gateway through a public load balancer. Zuplo terminates TLS
+and manages the certificates, including for your
+[custom domains](../custom-domains.mdx).
+
+To put a CDN or WAF, such as Cloud CDN with Google Cloud Armor, in front of the
+gateway, make sure clients can't bypass it and call the gateway directly. Have
+the CDN add a shared secret header that the gateway checks, or authenticate the
+CDN with
+[client mTLS](../../articles/securing-the-gateway-with-client-mtls.mdx).
+
+## Outbound traffic and IP addresses
+
+The gateway reaches the internet through Cloud NAT. By default, these outbound
+IP addresses aren't reserved and can change. If your backend or a third-party
+API allowlists callers by IP address, ask your account manager to reserve
+outbound addresses for your instance before you rely on them.
+
+## Connecting to your backends
+
+The gateway can call any backend it can reach over the internet. To keep backend
+traffic off the public internet, use Private Service Connect or VPC Network
+Peering. See [GCP Private Networking](./private-networking.mdx).
+
+However your backend is reached, make sure it only accepts requests from your
+gateway. See [Securing your backend](../../articles/securing-your-backend.mdx).

package/docs/dedicated/{gcp-private-networking.mdx → gcp/private-networking.mdx}

@@ -1,6 +1,6 @@
 ---
 title: "Managed Dedicated: GCP Private Networking"
-sidebar_label: GCP Private Networking
+sidebar_label: Private Networking
 ---
 
 Zuplo Managed Dedicated can run on Google Cloud and connect privately to
@@ -118,7 +118,7 @@ patterns to expect.
 
 ## Next steps
 
-- Review the general [Managed Dedicated networking](./networking.mdx) overview
-- Review [Managed Dedicated architecture](./architecture.mdx)
+- Review the general [Managed Dedicated networking](../networking.mdx) overview
+- Review [Managed Dedicated architecture](../architecture.mdx)
 - [Schedule time with Zuplo](https://book.zuplo.com) to review your GCP network
   design

package/docs/dedicated/networking.mdx

@@ -24,11 +24,13 @@ To discuss your networking requirements, please contact your account manager.
 ## Cloud-specific guidance
 
 - For AWS private backend connectivity, see
-  [AWS Private Networking](./aws-private-networking.mdx)
+  [AWS Private Networking](./aws/private-networking.mdx)
 - For Azure private backend connectivity, see
-  [Azure Private Networking](./azure-private-networking.mdx)
+  [Azure Private Networking](./azure/private-networking.mdx)
 - For Google Cloud private backend connectivity, see
-  [GCP Private Networking](./gcp-private-networking.mdx)
+  [GCP Private Networking](./gcp/private-networking.mdx)
+- For Akamai Connected Cloud, see
+  [Akamai Dedicated Architecture](./akamai/architecture.mdx)
 
 ## Zuplo Ingress to Customer Private Network
 

package/docs/dedicated/overview.mdx

@@ -26,10 +26,14 @@ Managed Dedicated hosting might be the right choice for you if you need:
 Zuplo Managed Dedicated can be deployed on a wide range of cloud providers and
 hosting platforms, including:
 
-- **Akamai Connected Cloud** - Leverage Akamai's global network infrastructure
-- **AWS** - Deploy to Amazon Web Services with full VPC integration
-- **Azure** - Run on Microsoft Azure with private networking support
-- **GCP** - Deploy to Google Cloud Platform with custom networking
+- **[Akamai Connected Cloud](./akamai/architecture.mdx)** - Leverage Akamai's
+  global network infrastructure
+- **[AWS](./aws/architecture.mdx)** - Deploy to Amazon Web Services with full
+  VPC integration
+- **[Azure](./azure/architecture.mdx)** - Run on Microsoft Azure with private
+  networking support
+- **[GCP](./gcp/architecture.mdx)** - Deploy to Google Cloud Platform with
+  custom networking
 - **Equinix** - Use Equinix data centers for colocation and connectivity
 - **TerraSwitch** - Deploy to TerraSwitch infrastructure
 - **Other providers** - Contact us to discuss support for additional providers

package/docs/dev-portal/zudoku/configuration/authentication-auth0.md

@@ -50,21 +50,7 @@ If you don't have an Auth0 account, you can sign up for a
 
    Keep the default **Refresh Token Expiration** settings unless you have specific requirements.
 
-3. Create an Auth0 API:
-   - Navigate to the [APIs section](https://manage.auth0.com/#/apis) in the Auth0 dashboard
-   - Click **Create API**
-   - Set a name (e.g., "Dev Portal API") and an identifier (e.g., `https://your-domain.com/api`)
-   - Choose **RS256** as the signing algorithm
-   - Save the API
-
-   :::warning
-
-   This step is important. If you skip creating an API, Dev Portal will not be able to validate the
-   tokens issued by Auth0, leading to authentication failures.
-
-   :::
-
-4. **Configure Zudoku**
+3. **Configure Zudoku**
 
    Add the Auth0 configuration to your [Dev Portal configuration file](./overview.md):
 
@@ -76,7 +62,6 @@ If you don't have an Auth0 account, you can sign up for a
        type: "auth0",
        domain: "your-domain.us.auth0.com",
        clientId: "<your-auth0-client-id>",
-       audience: "https://your-domain.com/api", // Your Auth0 API identifier
      },
      // ... other configuration
    };
@@ -85,7 +70,36 @@ If you don't have an Auth0 account, you can sign up for a
    Where:
    - **domain**: Your Auth0 domain (found in your application's Basic Information)
    - **clientId**: The Client ID from your Auth0 application settings
-   - **audience**: The identifier of the Auth0 API you created (e.g., `https://your-domain.com/api`)
+
+4. **(Optional) Configure an audience for API access**
+
+   Only configure an `audience` if you need the access token to call a specific API (for example,
+   when using the API playground to send authenticated requests to your backend). Without an
+   audience, Auth0 issues an opaque token that can be used to identify the user via `/userinfo` —
+   which is all Dev Portal needs for sign-in and protected routes.
+
+   :::tip
+
+   Avoid setting an audience when you don't need it. Issuing an access token scoped to an API when
+   it isn't going to call that API gives the token broader privileges than necessary.
+
+   :::
+
+   If you do need API access:
+   - Navigate to the [APIs section](https://manage.auth0.com/#/apis) in the Auth0 dashboard
+   - Click **Create API**, set a name (e.g., "Dev Portal API") and an identifier (e.g.,
+     `https://your-domain.com/api`)
+   - Choose **RS256** as the signing algorithm and save the API
+   - Add the identifier to your Dev Portal configuration:
+
+   ```typescript
+   authentication: {
+     type: "auth0",
+     domain: "your-domain.us.auth0.com",
+     clientId: "<your-auth0-client-id>",
+     audience: "https://your-domain.com/api", // Your Auth0 API identifier
+   }
+   ```
 
 </Stepper>
 
@@ -188,8 +202,9 @@ authentication: {
 3. **Authentication Loop**: Check that your Auth0 domain is a plain hostname only (e.g.,
    `your-domain.us.auth0.com`) without a protocol prefix (`https://`) or trailing slash.
 
-4. **Token Validation Errors**: Ensure the audience in your Dev Portal configuration matches the
-   identifier of the Auth0 API you created.
+4. **Token Validation Errors**: If you've configured an `audience`, make sure it matches the
+   identifier of the Auth0 API you created. If you don't need to call an API, remove `audience` from
+   your configuration — Auth0 will issue an opaque token suitable for `/userinfo`.
 
 ## Next Steps
 

package/docs/dev-portal/zudoku/configuration/overview.md

@@ -284,12 +284,16 @@ URL.
   // ...
   "redirects": [
     { "from": "/", "to": "/documentation/introduction" },
-    { "from": "/documentation", "to": "/documentation/introduction" }
+    { "from": "/documentation", "to": "/documentation/introduction" },
+    { "from": "/blog/:slug", "to": "/posts/:slug" }
   ]
   // ...
 }
 ```
 
+`from` paths can contain `:param` segments and a trailing `*` wildcard. See
+[Redirects](/dev-portal/zudoku/guides/redirects#path-parameters-and-wildcards) for details.
+
 ### `port`
 
 The port on which the development server will run. Defaults to `3000`. This option can also be

package/docs/dev-portal/zudoku/guides/redirects.md

@@ -52,6 +52,43 @@ redirects: [{ from: "/old-page", to: "/new-page" }];
 Trailing slashes in the `from` path are normalized automatically. Both `/old-page` and `/old-page/`
 will match the same redirect rule.
 
+## Path parameters and wildcards
+
+A `from` path can match more than one URL. Use `:name` for a single path segment and a trailing `*`
+for everything after a prefix. Reference the same tokens in `to` to carry the matched values over:
+
+```ts
+redirects: [
+  // /blog/hello-world → /posts/hello-world
+  { from: "/blog/:slug", to: "/posts/:slug" },
+  // /v1/guides/auth/tokens → /guides/auth/tokens
+  { from: "/v1/*", to: "/*" },
+  // /dashboard/apps/42 → https://dashboard.example.com/apps/42
+  { from: "/dashboard/*", to: "https://dashboard.example.com/*" },
+];
+```
+
+- **`:name`** matches exactly one segment. Add `?` (`:name?`) to make it optional.
+- **`*`** must be the last segment of `from`. It also matches the prefix itself, so `/dashboard/*`
+  redirects `/dashboard` too. In that case the `/*` in `to` is dropped, leaving `/` if nothing else
+  remains.
+- In `to`, `/:name` and `/*` must each fill a whole path segment, so `/posts/:slug` works and
+  `/posts-:slug` doesn't. Tokens that don't appear in `from` are left as they are.
+- Dev Portal doesn't copy the incoming query string to the target.
+
+Pages in your portal take precedence over a wildcard redirect, so `{ from: "/docs/*", to: "/" }`
+still lets visitors reach `/docs/introduction` if that page exists.
+
+Static hosts can't prerender a file for every URL a pattern matches, so pattern redirects behave
+differently from exact ones:
+
+- **Zuplo** and **Vercel**: Dev Portal turns the pattern into a regular-expression route in the build
+  output, and the platform returns an HTTP **301**.
+- **SSR deployments**: the server returns an HTTP 301, the same as exact redirects.
+- **Other static hosts**: no redirect file is written. If your host serves `404.html` (or your app's
+  `index.html`) for unknown paths, the page loads, Dev Portal matches the pattern, and the browser is
+  redirected. Otherwise, set up the redirect in your host's own configuration.
+
 ## How redirects work
 
 Dev Portal redirects operate at two levels depending on how the visitor reaches the page:

package/docs/programmable-api/zuplo-json.mdx

@@ -90,8 +90,8 @@ to `false`.
 Allow the Host header to be overridden by the client. This configuration
 defaults to `false`. This is only supported in managed dedicated environments.
 Only enable this setting if you understand the implications. See
-[Host Header Override](../dedicated/advanced/host-header-override.mdx) for when
-to use it and an example.
+[Host Header Override](../dedicated/configuration/host-header-override.mdx) for
+when to use it and an example.
 
 ```jsonc
 {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "7.10.0",
+  "version": "7.11.1",
   "type": "module",
   "description": "The official Zuplo CLI for local development and platform management",
   "homepage": "https://zuplo.com/docs/cli/overview",
@@ -32,9 +32,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "7.10.0",
-    "@zuplo/core": "7.10.0",
-    "@zuplo/runtime": "7.10.0",
-    "@zuplo/test": "7.10.0"
+    "@zuplo/cli": "7.11.1",
+    "@zuplo/core": "7.11.1",
+    "@zuplo/runtime": "7.11.1",
+    "@zuplo/test": "7.11.1"
   }
 }