zuplo 6.70.68 → 6.70.70

package/docs/ai-gateway/getting-started.mdx

@@ -9,7 +9,7 @@ initial configuration to making your first LLM request through Zuplo.
 ## Prerequisites
 
 - A Zuplo account (sign up free at [zuplo.com](https://zuplo.com))
-- API keys for at least one LLM provider (OpenAI, Anthropic, Google Gemini,
+- API keys for at least one LLM provider (OpenAI, Anthropic, Google, Mistral,
   etc.)
 - An application that needs to call LLM APIs
 
@@ -27,9 +27,9 @@ includes Apps, Teams, and a setup guide to help you get started.
 
 ## Step 2: Configure Providers
 
-Providers are the LLM services (like OpenAI or Google Gemini) that your
-applications will use. You'll configure these once as an administrator, and your
-team members can use them without needing direct access to provider API keys.
+Providers are the LLM services (like OpenAI or Anthropic) that your applications
+will use. You'll configure these once as an administrator, and your team members
+can use them without needing direct access to provider API keys.
 
 ### Adding Your First Provider
 
@@ -43,13 +43,17 @@ team members can use them without needing direct access to provider API keys.
 ### Adding Additional Providers
 
 Repeat the process above to add more providers. This allows your teams to switch
-between providers (OpenAI, Gemini, etc.) without changing application code.
+between providers (OpenAI, Anthropic, etc.) without changing application code.
 
 **Example providers you might add:**
 
 - OpenAI (for GPT models)
-- Google Gemini (for Gemini models)
-- Additional providers as they become available
+- Anthropic (for Claude models)
+- Google (for Gemini models)
+- Mistral (for Mistral models)
+
+See [AI Providers](./providers.mdx) for the full list of supported providers and
+capabilities, including OpenAI-compatible custom providers.
 
 ## Step 3: Create a Team
 
@@ -202,7 +206,7 @@ Now that your AI Gateway is running, explore additional features:
 ### Switch Providers Without Code Changes
 
 1. Go to your app settings
-2. Change the **Provider** dropdown (for example, from OpenAI to Gemini)
+2. Change the **Provider** dropdown (for example, from OpenAI to Anthropic)
 3. Select a new model
 4. Click **Save Changes**
 

package/docs/ai-gateway/introduction.mdx

@@ -4,16 +4,17 @@ sidebar_label: Introduction
 ---
 
 Zuplo's AI Gateway acts as an intelligent proxy layer that sits between your
-engineering team's applications and LLM providers like OpenAI, Google Gemini,
-and others. Instead of your applications communicating directly with these
-providers, all requests flow through the Zuplo AI Gateway, which streams
+engineering team's applications and LLM providers like OpenAI, Anthropic,
+Google, and Mistral. Instead of your applications communicating directly with
+these providers, all requests flow through the Zuplo AI Gateway, which streams
 responses while applying policies, controls, and monitoring.
 
 ## Key Benefits
 
-**Provider Independence**: Switch between LLM providers (OpenAI, Google Gemini,
-etc.) dynamically without modifying application code. Configure your provider
-choice through the gateway rather than hard coding it into your applications.
+**Provider Independence**: Switch between LLM providers (OpenAI, Anthropic,
+Google, Mistral, and more) dynamically without modifying application code.
+Configure your provider choice through the gateway rather than hard coding it
+into your applications.
 
 **Cost Control**: Set spending limits at organization, team, and application
 levels with hierarchical budgets that cascade down through your structure.
@@ -49,9 +50,10 @@ credentials.
 ### Multi-Provider Support
 
 Configure multiple LLM providers within a single gateway project. Supported
-providers include OpenAI (GPT-4, GPT-4.5, and other models) and Google Gemini
-(all model variants). Select which models are available to your teams when
-configuring each provider.
+providers include OpenAI, Anthropic, Google, Mistral, and OpenAI-compatible
+custom providers. See [AI Providers](./providers.mdx) for the full list of
+providers and supported capabilities. Select which models are available to your
+teams when configuring each provider.
 
 ### Team Hierarchy & Budgets
 

package/docs/articles/api-key-buckets.mdx

@@ -11,10 +11,12 @@ credentials across different environments. Learn more in the
 
 Zuplo automatically creates three buckets for each project:
 
-- **Working copy**: Stores API keys for the working-copy environment
 - **Production**: Stores API keys for the production environment (your default
   Git branch)
-- **Shared**: Stores API keys shared across all other environments
+- **Preview**: Stores API keys shared across all preview environments
+  (non-default Git branches)
+- **Development**: Stores API keys for the development (working copy)
+  environment
 
 For more information on how environments relate to Git branches, see
 [Branch-Based Deployments](./branch-based-deployments.mdx).

package/docs/articles/archiving-requests-to-storage.mdx

@@ -30,7 +30,7 @@ can generate one of these on the `Shared access tokens` tab.
 Note, you should minimize the permissions - and select only the `Create`
 permission. Choose a sensible start and expiration time for your token. Note, we
 don't recommend restricting IP addresses because Zuplo runs at the edge in over
-200 data-centers world-wide.
+300 data centers worldwide.
 
 ![shared access tokens](../../public/media/guides/archiving-requests-to-storage/Untitled_1.png)
 
@@ -46,7 +46,7 @@ You'll need another environment variable called `BLOB_CONTAINER_PATH`.
 We'll write a policy called `request-archive-policy` that can be used on all
 routes.
 
-```ts title="file-archive-policy.ts"
+```ts title="modules/request-archive-policy.ts"
 import { ZuploRequest, ZuploContext } from "@zuplo/runtime";
 
 export type RequestArchivePolicyOptions = {
@@ -102,7 +102,7 @@ example below:
   "policyType": "code-policy",
   "handler": {
     "export": "default",
-    "module": "$import(./modules/archive-request-policy)",
+    "module": "$import(./modules/request-archive-policy)",
     "options": {
       "blobCreateSas": "$env(BLOB_CREATE_SAS)",
       "blobContainerPath": "$env(BLOB_CONTAINER_PATH)"
@@ -111,7 +111,7 @@ example below:
 }
 ```
 
-Don't forget to reference the `file-archive-policy` in the policies.inbound
+Don't forget to reference the `request-archive-policy` in the policies.inbound
 property of your routes.
 
 Here's the policy in action:

package/docs/articles/branch-based-deployments.mdx

@@ -34,17 +34,19 @@ bugfix/123    ─────────────────►  Preview (b
 When Zuplo deploys an environment from a branch, the environment name matches
 the branch name. For example:
 
-| Branch Name    | Environment Name | Example URL                                         |
-| -------------- | ---------------- | --------------------------------------------------- |
-| `main`         | main             | `https://my-project-main-abc1234.zuplo.app`         |
-| `staging`      | staging          | `https://my-project-staging-def5678.zuplo.app`      |
-| `feature/auth` | feature/auth     | `https://my-project-feature-auth-ghi9012.zuplo.app` |
+| Branch Name    | Environment Name | Example URL                                       |
+| -------------- | ---------------- | ------------------------------------------------- |
+| `main`         | main             | `https://my-project-main-abc1234.zuplo.app`       |
+| `staging`      | staging          | `https://my-project-staging-def5678.zuplo.app`    |
+| `feature/auth` | feature/auth     | `https://my-project-feature-au-ghi9012.zuplo.app` |
 
 :::note
 
-The environment URL includes a unique identifier to ensure each deployment has a
-distinct address. Configure [custom domains](./custom-domains.mdx) for your
-environments.
+Zuplo normalizes the branch name in the deployment URL — lowercasing it,
+replacing special characters with hyphens, and truncating it to 10 characters —
+which is why `feature/auth` appears as `feature-au`. The URL also includes a
+unique identifier to ensure each deployment has a distinct address. Configure
+[custom domains](./custom-domains.mdx) for your environments.
 
 :::
 

package/docs/articles/ci-cd-github/cleanup-on-branch-delete.mdx

@@ -34,24 +34,29 @@ jobs:
         run: |
           # The deleted branch name
           BRANCH_NAME="${{ github.event.ref }}"
-          # Convert slashes to hyphens
-          ENV_NAME="${BRANCH_NAME//\//-}"
-
-          echo "Deleting environment: $ENV_NAME"
-
-          # Ignore errors if env doesn't exist
-          npx zuplo delete \
-            --environment "$ENV_NAME" \
-            --api-key "$ZUPLO_API_KEY" \
-            --wait || true
+          # Deployment names use the format {project}-{branch}-{hash}, where
+          # the branch segment is normalized (lowercase, special characters
+          # replaced by hyphens) and truncated to 10 characters
+          ENV_NAME=$(echo "$BRANCH_NAME" | tr '/_' '--' |
+            tr '[:upper:]' '[:lower:]' | cut -c1-10 | sed 's/-*$//')
+
+          # Find the deployment for the deleted branch and delete it by URL
+          npx zuplo list --api-key "$ZUPLO_API_KEY" \
+            --output json --show-details |
+            jq -r --arg env "$ENV_NAME" \
+              '.[] | select(.name | test("-" + $env + "-[a-z0-9]+$")) | .url' |
+            while read -r URL; do
+              echo "Deleting environment: $URL"
+              npx zuplo delete --url "$URL" --api-key "$ZUPLO_API_KEY" --wait || true
+            done
 ```
 
 This workflow:
 
 1. Triggers when any branch is deleted
-2. Converts the branch name to the environment name format
-3. Deletes the corresponding Zuplo environment
-4. Continues without error if the environment doesn't exist
+2. Converts the branch name to the deployment-name branch segment format
+3. Looks up the matching deployment and deletes it by URL
+4. Continues without error if no matching environment exists
 
 ## Combining with PR Cleanup
 
@@ -95,24 +100,40 @@ jobs:
 
       - name: Cleanup stale environments
         run: |
-          # Get all remote branches
-          BRANCHES=$(git branch -r | sed 's|origin/||' | tr '/' '-' | tr -d ' ')
-
-          # List Zuplo environments and delete stale ones
-          npx zuplo list --api-key "$ZUPLO_API_KEY" --json > environments.json
-
-          cat environments.json | jq -r '.[] | .name' | while read ENV; do
-            # Skip protected environments
-            if [[ "$ENV" == "main" || "$ENV" == "production" || "$ENV" == "staging" ]]; then
-              continue
-            fi
-
-            # Delete if no matching branch exists
-            if ! echo "$BRANCHES" | grep -q "^$ENV$"; then
-              echo "Deleting stale environment: $ENV"
-              npx zuplo delete --environment "$ENV" --api-key "$ZUPLO_API_KEY" --wait || true
-            fi
-          done
+          # Get all remote branches, converted to the deployment-name branch
+          # segment format: lowercase, special characters replaced by hyphens,
+          # truncated to 10 characters
+          BRANCHES=$(git branch -r | sed 's|origin/||' | tr -d ' ' |
+            tr '/_' '--' | tr '[:upper:]' '[:lower:]' |
+            cut -c1-10 | sed 's/-*$//')
+
+          # List deployed environments as JSON. Each entry has the shape
+          # {"projectName": "...", "name": "...", "url": "..."}
+          npx zuplo list --api-key "$ZUPLO_API_KEY" \
+            --output json --show-details > environments.json
+
+          # Deployment names follow the format {project}-{branch}-{hash}
+          jq -r '.[] | "\(.name) \(.url)"' environments.json |
+            while read -r NAME URL; do
+              # Skip protected environments
+              case "$NAME" in
+                *-main-* | *-production-* | *-staging-*) continue ;;
+              esac
+
+              # Delete only if no branch matches the deployment name
+              STALE=true
+              for BRANCH in $BRANCHES; do
+                if [[ "$NAME" == *"-$BRANCH-"* ]]; then
+                  STALE=false
+                  break
+                fi
+              done
+
+              if [[ "$STALE" == "true" ]]; then
+                echo "Deleting stale environment: $NAME"
+                npx zuplo delete --url "$URL" --api-key "$ZUPLO_API_KEY" --wait || true
+              fi
+            done
 ```
 
 ## Next Steps

package/docs/articles/ci-cd-github/pr-preview-environments.mdx

@@ -71,15 +71,26 @@ jobs:
       - name: Install dependencies
         run: npm install
 
+      - name: Get deployment URL
+        id: get-url
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const comments = await github.rest.issues.listComments({
+              issue_number: context.issue.number,
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+            });
+            const match = comments.data
+              .map((c) => c.body.match(/Deployed to: (https:\/\/\S+)/))
+              .find(Boolean);
+            core.setOutput("url", match ? match[1] : "");
+
       - name: Delete environment
+        if: steps.get-url.outputs.url != ''
         run: |
-          # Environment name is based on branch name
-          BRANCH_NAME="${{ github.head_ref }}"
-          # Convert slashes to hyphens (Zuplo convention)
-          ENV_NAME="${BRANCH_NAME//\//-}"
-
           npx zuplo delete \
-            --environment "$ENV_NAME" \
+            --url "${{ steps.get-url.outputs.url }}" \
             --api-key "$ZUPLO_API_KEY" \
             --wait
 ```

package/docs/articles/custom-ci-cd-azure.mdx

@@ -38,7 +38,7 @@ npx zuplo deploy --api-key "$ZUPLO_API_KEY"
 npx zuplo test --endpoint https://your-env.zuplo.dev
 
 # Clean up environments you no longer need
-npx zuplo delete --environment pr-123 --api-key "$ZUPLO_API_KEY"
+npx zuplo delete --url "https://my-api-pr-123-d3vp01.zuplo.app" --api-key "$ZUPLO_API_KEY"
 
 # Test locally before deploying
 npx zuplo dev  # starts local server on port 9000

package/docs/articles/custom-ci-cd-bitbucket.mdx

@@ -37,7 +37,7 @@ npx zuplo deploy --api-key "$ZUPLO_API_KEY"
 npx zuplo test --endpoint https://your-env.zuplo.dev
 
 # Clean up environments you no longer need
-npx zuplo delete --environment pr-123 --api-key "$ZUPLO_API_KEY"
+npx zuplo delete --url "https://my-api-pr-123-d3vp01.zuplo.app" --api-key "$ZUPLO_API_KEY"
 
 # Test locally before deploying
 npx zuplo dev  # starts local server on port 9000

package/docs/articles/custom-ci-cd-circleci.mdx

@@ -36,7 +36,7 @@ npx zuplo deploy --api-key "$ZUPLO_API_KEY"
 npx zuplo test --endpoint https://your-env.zuplo.dev
 
 # Clean up environments you no longer need
-npx zuplo delete --environment pr-123 --api-key "$ZUPLO_API_KEY"
+npx zuplo delete --url "https://my-api-pr-123-d3vp01.zuplo.app" --api-key "$ZUPLO_API_KEY"
 
 # Test locally before deploying
 npx zuplo dev  # starts local server on port 9000

package/docs/articles/custom-ci-cd-github.mdx

@@ -54,7 +54,7 @@ npx zuplo deploy --api-key "$ZUPLO_API_KEY"
 npx zuplo test --endpoint https://your-env.zuplo.dev
 
 # Clean up environments you no longer need
-npx zuplo delete --environment pr-123 --api-key "$ZUPLO_API_KEY"
+npx zuplo delete --url "https://my-api-pr-123-d3vp01.zuplo.app" --api-key "$ZUPLO_API_KEY"
 
 # Test locally before deploying
 npx zuplo dev  # starts local server on port 9000

package/docs/articles/custom-ci-cd-gitlab.mdx

@@ -36,7 +36,7 @@ npx zuplo deploy --api-key "$ZUPLO_API_KEY"
 npx zuplo test --endpoint https://your-env.zuplo.dev
 
 # Clean up environments you no longer need
-npx zuplo delete --environment pr-123 --api-key "$ZUPLO_API_KEY"
+npx zuplo delete --url "https://my-api-pr-123-d3vp01.zuplo.app" --api-key "$ZUPLO_API_KEY"
 
 # Test locally before deploying
 npx zuplo dev  # starts local server on port 9000

package/docs/articles/graphql.mdx

@@ -0,0 +1,276 @@
+---
+title: GraphQL on Zuplo
+sidebar_label: GraphQL
+description:
+  Proxy a GraphQL API through your Zuplo gateway and publish a browsable schema
+  reference with a playground in your Dev Portal.
+tags:
+  - backends
+---
+
+Zuplo fronts GraphQL APIs the same way it fronts REST: requests pass through a
+gateway route — with whatever authentication, rate limiting, and
+GraphQL-specific policies you attach — and your Dev Portal documents the schema.
+This guide covers both halves: adding a GraphQL endpoint to your gateway routes,
+then rendering a schema reference and playground in the Dev Portal with
+`@zudoku/plugin-graphql`.
+
+## Prerequisites
+
+- A Zuplo project
+- An upstream GraphQL API to proxy
+- For the Dev Portal section: your project's
+  [Dev Portal](../dev-portal/introduction.mdx) lives in its `docs/` folder. The
+  plugin requires the `zudoku` package version `0.80.1` or newer — check the
+  version in `docs/package.json` and
+  [update the Dev Portal](../dev-portal/updating.mdx) if yours is older.
+
+## Add a GraphQL endpoint to your gateway
+
+A GraphQL API serves every query and mutation from a single endpoint, so the
+gateway route uses the [URL Rewrite handler](../handlers/url-rewrite.mdx) —
+every request goes to exactly the upstream URL — rather than URL Forward, which
+appends the incoming path.
+
+### Add a new GraphQL route
+
+<Stepper>
+
+1. **Open the Route Designer**
+
+   In the Zuplo Portal, open the **Code** tab and click **routes.oas.json**.
+   This opens the Route Designer, which lists your project's existing routes and
+   an **Add** menu.
+
+2. **Add the endpoint**
+
+   Click **Add** and select **GraphQL Endpoint**. This creates a `POST /graphql`
+   route preconfigured with the URL Rewrite handler and a demo upstream. If
+   `/graphql` is already taken, the Portal appends a short suffix (for example
+   `/graphql-b891`) — edit the path to whatever you prefer. GraphQL routes show
+   a **GraphQL** badge in the route list instead of an HTTP method.
+
+3. **Point it at your upstream**
+
+   Expand the new route. Its handler is preset to **URL Rewrite** in the
+   **Request Handler** drop-down; in the URL text box below it, replace the demo
+   URL with your GraphQL API's endpoint, for example
+   `https://api.example.com/graphql`. To use a different backend per
+   environment, reference an [environment variable](./environment-variables.mdx)
+   such as `${env.GRAPHQL_API_URL}`.
+
+4. **Save**
+
+   Save your changes. Your gateway now proxies GraphQL requests at `/graphql`.
+
+</Stepper>
+
+### Mark an existing route as GraphQL
+
+Already proxying a GraphQL API through a regular route? Open the route in the
+Route Designer, click the **⋯** menu at the end of the route's options row (next
+to the CORS and docs toggles), and check **Mark as GraphQL**. This tags the
+route as a GraphQL endpoint without changing its handler or policies.
+
+### The resulting route configuration
+
+Both paths produce a route in `routes.oas.json` with the `x-graphql` extension
+set:
+
+```json title="config/routes.oas.json"
+{
+  "paths": {
+    "/graphql": {
+      "post": {
+        "summary": "GraphQL Endpoint",
+        "x-graphql": true,
+        "x-zuplo-route": {
+          "corsPolicy": "none",
+          "handler": {
+            "export": "urlRewriteHandler",
+            "module": "$import(@zuplo/runtime)",
+            "options": {
+              "rewritePattern": "https://api.example.com/graphql"
+            }
+          },
+          "policies": {
+            "inbound": []
+          }
+        },
+        "operationId": "graphql-1a2bc3d4"
+      }
+    }
+  }
+}
+```
+
+:::tip{title="Secure the endpoint"}
+
+GraphQL has its own attack surface — deeply nested queries, expensive
+operations, and schema introspection. Zuplo ships policies for all three. See
+[Secure your GraphQL API](./graphql-security.mdx) to add complexity limits and
+disable introspection in production.
+
+:::
+
+## Document the API in your Dev Portal
+
+The `@zudoku/plugin-graphql` package renders GraphQL APIs in your Dev Portal
+from a schema. Each plugin instance produces a browsable type reference
+(queries, mutations, objects, enums, and so on) plus a playground, generated
+straight from your schema.
+
+:::caution{title="Beta"}
+
+The GraphQL plugin is in beta. During the beta it isn't available in your
+project's working copy — it only works in projects
+[connected to source control](./source-control.mdx).
+
+:::
+
+<Stepper>
+
+1. **Install the plugin**
+
+   In your project's `docs/` folder (where `zudoku.config.tsx` lives), install
+   the plugin:
+
+   ```bash
+   npm install @zudoku/plugin-graphql
+   ```
+
+   The plugin requires `zudoku` `0.80.1` or newer.
+
+2. **Add a schema**
+
+   Drop a GraphQL schema definition language (SDL) file next to your config:
+
+   ```graphql title="schema.graphql"
+   type Query {
+     product(id: ID!): Product
+   }
+
+   type Product {
+     id: ID!
+     name: String!
+     price: Float!
+   }
+   ```
+
+   Don't have an SDL file handy? Skip this step and introspect a live endpoint
+   at build time with `type: "url"` in the next step — the schema is fetched for
+   you when the portal builds.
+
+3. **Register the plugin**
+
+   Import `graphqlPlugin` and add an instance per API. The `path` is where the
+   docs mount, and `input` points at your schema:
+
+   ```tsx title="zudoku.config.tsx"
+   import { graphqlPlugin } from "@zudoku/plugin-graphql";
+
+   const config = {
+     plugins: [
+       graphqlPlugin({
+         type: "file",
+         input: "./schema.graphql",
+         path: "/graphql/ecommerce",
+         options: {
+           title: "E-Commerce GraphQL API",
+           description: "Products, orders, and customers.",
+           playground: {
+             endpoint: "https://my-gateway.example.com/graphql",
+           },
+         },
+       }),
+     ],
+   };
+
+   export default config;
+   ```
+
+   Set `playground.endpoint` to the gateway route from the first half of this
+   guide so readers run real queries through your gateway. With a file-based
+   schema the plugin doesn't know where your API lives — leave the endpoint
+   unset and the reference pages still render, but the playground asks you to
+   configure `options.playground.endpoint` before it can run operations.
+
+   With `type: "url"`, set `input` to your GraphQL endpoint's URL instead: the
+   schema is fetched via introspection when the portal builds, and the
+   playground defaults to that same URL. You can register the plugin more than
+   once to document several schemas, each with its own `path`.
+
+4. **Link it in the navigation**
+
+   Point a navigation link at the instance's `path`. Set `stack: true` so the
+   API's own pages render as a stacked sub-navigation instead of expanding
+   inline:
+
+   ```tsx title="zudoku.config.tsx"
+   navigation: [
+     {
+       type: "category",
+       label: "Documentation",
+       items: [
+         {
+           type: "link",
+           label: "E-Commerce API",
+           to: "/graphql/ecommerce",
+           stack: true,
+         },
+       ],
+     },
+   ];
+   ```
+
+   Prefer the API as its own top-level section instead? Drop the link at the top
+   level of `navigation` and leave off `stack`. See the
+   [navigation reference](../dev-portal/zudoku/configuration/navigation.mdx) for
+   all link, category, and stacking options.
+
+</Stepper>
+
+### Plugin options
+
+All options live under the instance's `options` key:
+
+| Option                | Type      | Description                                                                                                                                            |
+| --------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `title`               | `string`  | Display title for the API's overview page.                                                                                                             |
+| `description`         | `string`  | Short description shown on the overview page.                                                                                                          |
+| `showDeprecated`      | `boolean` | Include deprecated fields and operations in the reference.                                                                                             |
+| `playground.enabled`  | `boolean` | Show the playground. Defaults to `true`.                                                                                                               |
+| `playground.endpoint` | `string`  | URL the playground sends operations to. Defaults to `input` for `type: "url"`. File schemas have no default; the playground prompts for one until set. |
+| `playground.headers`  | `object`  | Default headers the playground sends with each operation.                                                                                              |
+
+## Verify it worked
+
+Open the
+[**Environments**](https://portal.zuplo.com/+/account/project/environments) tab
+in the Zuplo Portal — your build is listed there along with the URLs for both
+your gateway and your Dev Portal. Send a query through the gateway URL:
+
+```bash
+curl https://my-gateway.example.com/graphql \
+  -H "Content-Type: application/json" \
+  -d '{"query":"{ __typename }"}'
+```
+
+A working route returns a response from your upstream, such as
+`{"data":{"__typename":"Query"}}`.
+
+For the Dev Portal, open its URL from the **Environments** tab (or run
+`npm run dev` in your `docs/` folder) and go to the plugin's `path` (for example
+`/graphql/ecommerce`). The overview page lists the schema's types, and the
+playground runs operations against your configured endpoint.
+
+## Next steps
+
+- [Secure your GraphQL API](./graphql-security.mdx) — complexity limits and
+  introspection policies
+- [Testing GraphQL queries](./testing-graphql.mdx) — test the endpoint from the
+  Zuplo Portal or external tools
+- [URL Rewrite handler](../handlers/url-rewrite.mdx) — full reference for the
+  handler GraphQL routes use
+- [MCP Server GraphQL endpoints](../mcp-server/graphql.mdx) — expose GraphQL
+  queries as MCP tools for AI agents

package/docs/articles/monorepo-deployment.mdx

@@ -206,12 +206,26 @@ jobs:
       - name: Install dependencies
         run: npm install
 
+      - name: Get deployment URL
+        id: get-url
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const comments = await github.rest.issues.listComments({
+              issue_number: context.issue.number,
+              owner: context.repo.owner,
+              repo: context.repo.repo,
+            });
+            const match = comments.data
+              .map((c) => c.body.match(/Deployed to: (https:\/\/\S+)/))
+              .find(Boolean);
+            core.setOutput("url", match ? match[1] : "");
+
       - name: Delete environment
+        if: steps.get-url.outputs.url != ''
         run: |
-          BRANCH_NAME="${{ github.head_ref }}"
-          ENV_NAME="${BRANCH_NAME//\//-}"
           npx zuplo delete \
-            --environment "$ENV_NAME" \
+            --url "${{ steps.get-url.outputs.url }}" \
             --api-key "$ZUPLO_API_KEY" \
             --wait
 ```