zuplo 6.70.24 → 6.70.26

package/docs/articles/api-key-consumer-bucket-portal-ui.mdx

@@ -0,0 +1,223 @@
+---
+title: Create Consumers in a Specific Bucket
+sidebar_label: Consumers in a Specific Bucket
+description:
+  Learn how to create API key consumers in a specific bucket using the Zuplo
+  portal UI, including bucket selection, environment mapping, and
+  troubleshooting.
+---
+
+Every API key consumer in Zuplo lives inside a **bucket**, and each bucket is
+scoped to a specific environment. This guide shows how to pick a target bucket
+from the **Services** screen and create a consumer inside it.
+
+:::note
+
+For general API key management (creating consumers, viewing keys, assigning
+managers), see [Manage Keys in the Portal](./api-key-administration.mdx).
+
+:::
+
+## Prerequisites
+
+- A Zuplo project with at least one deployed environment (see the
+  [getting started tutorial](./step-1-setup-basic-gateway.mdx))
+- The [API Key Authentication policy](../policies/api-key-inbound.mdx)
+  configured on your routes
+- Permission to manage API key consumers in your project
+
+## Understanding buckets and environments
+
+Zuplo creates three buckets for every project. Each isolates its own consumers
+and keys, so a key created in one bucket only authenticates requests against the
+matching environment.
+
+| Bucket          | Environment | Git branch           |
+| --------------- | ----------- | -------------------- |
+| **Production**  | Production  | Default branch       |
+| **Preview**     | Preview     | Non-default branches |
+| **Development** | Development | Local development    |
+
+![Diagram showing each Zuplo environment (Production, Preview, Development) mapping one-to-one to its matching bucket](../../public/media/api-key-consumer-bucket-portal-ui/bucket-environment-mapping.png)
+
+For deeper detail, see [Buckets and Environments](./api-key-buckets.mdx).
+
+### When you need a non-default bucket
+
+- **Per-environment isolation.** Keep staging keys out of production.
+- **Custom buckets.** Your team created extra buckets (QA, per-tenant) via the
+  [Developer API](./api-key-api.mdx).
+- **Shared buckets across projects.** Enterprise setups where one bucket backs
+  several projects.
+
+## Find your buckets in the portal
+
+<Stepper>
+
+1. Open your project in the [Zuplo Portal](https://portal.zuplo.com).
+
+1. Navigate to the
+   [**Services**](https://portal.zuplo.com/+/account/project/services) page.
+
+1. Locate the **API Key Service** card. Use the **environment dropdown** at the
+   top right to filter the visible buckets. Pick **All Environments** to see
+   every bucket, or pick a single environment to narrow the list.
+
+</Stepper>
+
+<ModalScreenshot size="md">
+
+![Services page with the environment dropdown open, showing All Environments, Production, Preview, and Development options](../../public/media/api-key-consumer-bucket-portal-ui/services-page-dropdown.png)
+
+</ModalScreenshot>
+
+The card's **Connected to** badge shows which environment's bucket is currently
+active.
+
+## Create a consumer in a specific bucket
+
+<Stepper>
+
+1. On the **Services** page, choose the target environment from the dropdown.
+
+1. On the API Key Service card, click **Bucket Details**. The bucket's consumer
+   list opens.
+
+1. Click **Create new consumer** and fill in the form below.
+
+1. Click **Save consumer**, then confirm it appears in the list.
+
+</Stepper>
+
+<ModalScreenshot size="md">
+
+![Create new consumer modal showing Subject, Key managers, and Metadata fields plus the Save consumer button](../../public/media/api-key-consumer-bucket-portal-ui/create-consumer-modal.png)
+
+</ModalScreenshot>
+
+### Consumer form fields
+
+| Field            | Required | Runtime value       | Notes                                                                                                                           |
+| ---------------- | -------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| **Subject**      | Yes      | `request.user.sub`  | Unique within the bucket. Identifies the consumer in logs and policy code.                                                      |
+| **Key managers** | No       | n/a                 | Comma-separated emails of users who can manage this consumer's keys via the [Developer Portal](../dev-portal/introduction.mdx). |
+| **Metadata**     | No       | `request.user.data` | Valid JSON object. Plan info, customer IDs, anything your policies need at runtime.                                             |
+
+:::tip
+
+Once created, the consumer's API key only authenticates requests routed through
+an environment whose API Key Authentication policy resolves to that same bucket.
+
+:::
+
+## How bucket selection affects key validation
+
+The [API Key Authentication policy](../policies/api-key-inbound.mdx) decides
+which bucket to validate keys against. With no `bucketName` set, the policy
+defaults to the bucket that matches the current environment:
+
+| Environment | Default bucket |
+| ----------- | -------------- |
+| Production  | Production     |
+| Preview     | Preview        |
+| Development | Development    |
+
+For a custom bucket, set `bucketName` (or `bucketId`) on the policy so it checks
+the right one:
+
+```json
+{
+  "export": "ApiKeyInboundPolicy",
+  "module": "$import(@zuplo/runtime)",
+  "options": {
+    "bucketName": "my-custom-bucket",
+    "allowUnauthenticatedRequests": false
+  }
+}
+```
+
+:::caution
+
+If the consumer lives in one bucket but the policy checks a different bucket,
+the key is not found and the request returns `401 Unauthorized`. Make sure the
+policy's bucket matches the bucket where you created the consumer.
+
+:::
+
+## Using the Developer API instead
+
+To script consumer creation as part of an onboarding flow or CI/CD pipeline, use
+the [Zuplo Developer API](./api-key-api.mdx):
+
+```bash
+curl \
+  https://dev.zuplo.com/v1/accounts/$ACCOUNT_NAME/key-buckets/$BUCKET_NAME/consumers?with-api-key=true \
+  --request POST \
+  --header "Content-type: application/json" \
+  --header "Authorization: Bearer $ZAPI_KEY" \
+  --data '{
+    "name": "my-consumer",
+    "description": "Created via API",
+    "metadata": { "plan": "gold" }
+  }'
+```
+
+Replace `$ACCOUNT_NAME` with your Zuplo account name, `$BUCKET_NAME` with the
+target bucket name, and `$ZAPI_KEY` with your
+[Zuplo API key](./accounts/zuplo-api-keys.mdx). Full reference at the
+[Developer API documentation](https://dev.zuplo.com/docs).
+
+## Troubleshooting
+
+<details>
+<summary>My API key returns 401 Unauthorized</summary>
+
+Usually a bucket mismatch. The consumer is in one bucket, but the policy checks
+a different one.
+
+1. In the portal, navigate to **Services** and confirm which bucket holds the
+   consumer.
+2. Open the route's API Key Authentication policy. If `bucketName` or `bucketId`
+   is set, verify it matches the consumer's bucket. If neither is set, the
+   policy uses the current environment's default bucket.
+3. Either recreate the consumer in the correct bucket, or update the policy's
+   `bucketName` to match.
+
+</details>
+
+<details>
+<summary>I don't see the bucket I'm looking for</summary>
+
+- **Environment filter.** Set the dropdown to **All Environments** to see every
+  bucket.
+- **Custom buckets.** Buckets created via the Developer API are account-scoped,
+  not environment-scoped. They show under **All Environments**. If still
+  missing, confirm the account using the
+  [list buckets API endpoint](https://dev.zuplo.com/docs).
+- **Permissions.** Account-level roles control access to the Services page.
+  Confirm your role can view and manage API key consumers.
+
+</details>
+
+<details>
+<summary>I created a consumer but it doesn't appear in the expected environment</summary>
+
+Consumers belong to buckets, not environments directly. A consumer created while
+viewing the **Preview** environment sits in the preview bucket and only
+authenticates preview environments. Switch the dropdown to **All Environments**
+or the specific environment to locate it.
+
+</details>
+
+## Related documentation
+
+- [Buckets and Environments](./api-key-buckets.mdx): How buckets map to
+  environments
+- [Manage Keys in the Portal](./api-key-administration.mdx): General portal
+  management walkthrough
+- [API Key Authentication policy](../policies/api-key-inbound.mdx): Policy
+  configuration reference including `bucketName`
+- [Use the Developer API](./api-key-api.mdx): Programmatic consumer management
+- [Create an API Key Consumer on Login](../dev-portal/dev-portal-create-consumer-on-auth.mdx):
+  Automatically create consumers when users sign in
+- [Environments](./environments.mdx): How environments work in Zuplo

package/docs/articles/monetization/api-access.mdx

@@ -65,7 +65,7 @@ curl \
 
 Each bucket has an optional `MonetizationConfiguration` record that holds
 bucket-wide defaults. The configuration is read by the runtime and the Developer
-Portal — it is not stored in OpenMeter.
+Portal.
 
 | Method   | Path                                                 |
 | -------- | ---------------------------------------------------- |
@@ -105,8 +105,8 @@ the schema defaults (`multipleSubscriptionsEnabled: false`, `planOrder: []`,
 
 These endpoints script the Stripe integration that the
 [Monetization Service UI](./stripe-integration.md#connecting-your-stripe-account)
-runs interactively. They live on the Zuplo developer API (not OpenMeter), so the
-request shape is documented here.
+runs interactively. They live on the Zuplo developer API, so the request shape
+is documented here.
 
 ### Connect a Stripe app
 

package/docs/articles/monetization/subscription-lifecycle.md

@@ -82,7 +82,7 @@ curl -X POST https://dev.zuplo.com/v3/metering/{bucketId}/subscriptions \
 ```
 
 `plan` references the target plan by its `key` (and optionally `version`).
-Provide either `customerId` (the metering customer ULID, format
+Provide either `customerId` (the Zuplo customer ULID, format
 `^[0-7][0-9A-HJKMNP-TV-Za-hjkmnp-tv-z]{25}$`) or `customerKey` (your own
 identifier). Optional fields include `timing` (`"immediate"` by default,
 `"next_billing_cycle"`, or an RFC 3339 timestamp), `startingPhase`, `name`,

package/docs/articles/securing-backend-mtls.mdx

@@ -1,5 +1,5 @@
 ---
-title: mTLS Authentication
+title: Gateway to Origin mTLS Authentication
 ---
 
 <EnterpriseFeature name="mTLS Client Certificates" />

package/docs/articles/securing-the-gateway-with-client-mtls.mdx

@@ -0,0 +1,318 @@
+---
+title: Client mTLS Authentication
+---
+
+<EnterpriseFeature name="Client mTLS" />
+
+Client mTLS authentication lets your Zuplo gateway verify the identity of
+clients calling your API using certificates issued by your own Certificate
+Authority (CA). Both the client and the gateway authenticate each other during
+the TLS handshake, so only clients holding a certificate signed by your CA can
+reach your API.
+
+## How Client mTLS Works
+
+When a client calls your Zuplo gateway:
+
+1. The client presents a certificate issued by your CA during the TLS handshake.
+2. Zuplo's edge verifies the certificate against the CA you've uploaded and
+   passes the verification result (and parsed certificate) to your gateway
+   workers.
+3. The [`mtls-auth-inbound`](../policies/mtls-auth-inbound.md) policy on your
+   route reads the verification result, enforces it, and attaches the parsed
+   certificate metadata to `request.user.data.mtlsAuth` for use in your handlers
+   and downstream policies.
+
+CA certificates are scoped to your Zuplo **account**, not a single project or
+deployment. Once a CA is uploaded, every gateway domain on the account will
+verify presented client certificates against it. The policy on each route
+controls whether unverified traffic is rejected or allowed through.
+
+## Prerequisites
+
+Before you begin, you need:
+
+- A public CA certificate (PEM-encoded) that issued — or will issue — the client
+  certificates you want to accept
+- The [Zuplo CLI](../cli/overview.mdx) installed and authenticated
+- A Zuplo project where you can add the `mtls-auth-inbound` policy to a route
+
+:::note
+
+You only upload your **public CA certificate** to Zuplo. Private keys and issued
+client certificates stay with you and your clients.
+
+:::
+
+## 1/ Upload Your CA Certificate
+
+Use the Zuplo CLI to upload your CA certificate. The CA is registered against
+your account and is automatically made available on all of your gateway domains.
+
+First, authenticate your client:
+
+```bash
+zuplo login
+```
+
+Then you can create a CA by running:
+
+```bash
+zuplo ca-certificate create \
+  --name my_ca \
+  --cert ./ca.pem \
+  --account your-account
+```
+
+**Parameters:**
+
+- `--name`: A unique identifier for the CA. Must be a valid JavaScript
+  identifier (letters, digits, `_`, `$`; cannot start with a digit).
+- `--cert`: Path to the PEM-encoded CA certificate
+  (`-----BEGIN CERTIFICATE-----` ...). DER is not supported.
+- `--account`: Your Zuplo account name.
+
+The command returns the new CA's ID (prefixed with `mtlsca_`). You can list all
+CAs on the account at any time:
+
+```bash
+zuplo ca-certificate list --account your-account
+```
+
+See the [`ca-certificate` CLI reference](../cli/ca-certificate-create.md) for
+all available subcommands (`create`, `list`, `describe`, `update`, `delete`).
+
+:::tip{title="Using an intermediate CA"}
+
+If your client certificates are issued by an intermediate CA (rather than
+directly by your root), upload the **intermediate** itself as the CA — not the
+root. The client certs used must be directly signed by the CA certificate you
+provide to Zuplo.
+
+:::
+
+## 2/ Add the mTLS Auth Inbound Policy
+
+Add the [`mtls-auth-inbound`](../policies/mtls-auth-inbound.md) policy to any
+route that should require a verified client certificate. The policy reads the
+verification result that Zuplo's edge attached to the request and either rejects
+unverified traffic or allows it through, depending on configuration.
+
+```json title="config/policies.json"
+{
+  "name": "my-mtls-auth-inbound-policy",
+  "policyType": "mtls-auth-inbound",
+  "handler": {
+    "export": "MTLSAuthInboundPolicy",
+    "module": "$import(@zuplo/runtime)",
+    "options": {
+      "allowUnauthenticatedRequests": false,
+      "certIssuerDN": "CN=example-ca, O=Example, C=US"
+    }
+  }
+}
+```
+
+**Key options:**
+
+- `allowUnauthenticatedRequests` (default `false`): When `false`, the policy
+  rejects requests that don't present a valid client certificate signed by a CA
+  on your account. When `true`, the policy lets traffic through but still
+  attaches certificate metadata when a parseable client certificate is present —
+  useful for staged rollouts or logging-only modes.
+- `certIssuerDN`: The fully qualified issuer distinguished name that the client
+  certificate must be signed by.
+
+See the full [policy reference](../policies/mtls-auth-inbound.md) for all
+options.
+
+:::tip{title="Finding your certIssuerDN value"}
+
+The issuer DN of a client certificate is the subject DN of the CA that signed
+it. Read it directly from your CA's PEM file with `openssl`:
+
+```bash
+openssl x509 -in ca.pem -noout -subject -nameopt RFC2253
+```
+
+This prints something like `subject=CN=example-ca,O=Example,C=US`. Copy the part
+after `subject=` into `certIssuerDN`. The policy tolerates casing and whitespace
+differences, but not RDN reordering, so keep the order produced by `openssl`
+as-is.
+
+:::
+
+## 3/ Read Certificate Metadata in Your Handler
+
+When verification succeeds, the policy attaches parsed certificate metadata to
+`request.user.data.mtlsAuth`. If `request.user` does not already exist, the
+policy also sets `request.user.sub` to the certificate subject.
+
+```ts
+import { ZuploContext, ZuploRequest } from "@zuplo/runtime";
+
+export default async function (request: ZuploRequest, context: ZuploContext) {
+  const mtls = request.user?.data?.mtlsAuth;
+
+  if (!mtls) {
+    return new Response("No client certificate", { status: 401 });
+  }
+
+  context.log.info("Authenticated client", {
+    subject: mtls.subject,
+    issuer: mtls.issuer,
+    fingerprint: mtls.sha256Fingerprint,
+  });
+
+  // Authorize based on certificate subject, fingerprint, etc.
+  return new Response(`Hello, ${mtls.subject}`);
+}
+```
+
+The metadata object includes:
+
+- `subject` — the client certificate subject DN
+- `issuer` — the issuer DN (the CA that signed the certificate)
+- `notBefore` / `notAfter` — validity window in ISO 8601 format
+- `sha256Fingerprint` — SHA-256 digest of the DER-encoded certificate, uppercase
+  hex with colon separators (e.g. `AB:CD:EF:...`). Useful for pinning specific
+  client certificates.
+
+The raw client certificate is also available on
+`context.incomingRequestProperties.clientCert` in
+[RFC 9440](https://datatracker.ietf.org/doc/html/rfc9440#section-2.2) format
+(Base64-encoded DER, colon-wrapped) if you need to perform custom parsing or
+forward it to a backend.
+
+## 4/ Test with curl
+
+Once your CA is uploaded and the policy is on the route, you can verify the
+end-to-end flow with `curl`. You'll need a client certificate and private key
+issued by the CA you uploaded.
+
+Send the certificate and key with `--cert` and `--key`:
+
+```bash
+curl --cert ./client.pem --key ./client.key \
+  https://your-gateway.zuplo.app/v1/example
+```
+
+Confirm that:
+
+- A request **without** `--cert` is rejected with `401` when
+  `allowUnauthenticatedRequests` is `false`.
+- A request with a certificate signed by your uploaded CA succeeds and your
+  handler sees the parsed certificate on `request.user.data.mtlsAuth`.
+- A request with a certificate signed by a different CA is rejected.
+
+## Managing CA Certificates
+
+### Listing CAs
+
+```bash
+zuplo ca-certificate list --account your-account
+```
+
+### Inspecting a CA
+
+```bash
+zuplo ca-certificate describe \
+  --cert-id mtlsca_abc123 \
+  --account your-account
+```
+
+### Renaming a CA
+
+Only the name can be updated; to replace the certificate body, delete the CA and
+create a new one.
+
+```bash
+zuplo ca-certificate update \
+  --cert-id mtlsca_abc123 \
+  --name renamed_ca \
+  --account your-account
+```
+
+### Deleting a CA
+
+```bash
+zuplo ca-certificate delete \
+  --cert-id mtlsca_abc123 \
+  --account your-account
+```
+
+:::caution
+
+Deleting a CA stops verification for client certificates issued by it on all of
+your gateway domains. Routes that use `mtls-auth-inbound` with
+`allowUnauthenticatedRequests: false` will start rejecting those clients
+immediately. Rotate to a new CA and update your clients before deleting the old
+CA.
+
+:::
+
+### Rotating a CA
+
+To rotate the CA without downtime:
+
+1. Upload the new CA alongside the existing one with
+   `zuplo ca-certificate create`.
+2. Reissue client certificates from the new CA and distribute them to your
+   clients.
+3. Once all clients have moved to the new CA, delete the old CA with
+   `zuplo ca-certificate delete`.
+
+If you've followed the common practice of preserving the CA's subject DN across
+the rotation (only the key, serial, and validity dates change), the issuer DN on
+newly issued client certificates is identical to the previous one and
+**`certIssuerDN` does not need to change**. If the rotation deliberately changes
+the CA's subject DN, update `certIssuerDN` to match the new value before cutting
+clients over — or temporarily set `allowUnauthenticatedRequests: true` to allow
+both issuers during the transition.
+
+## Local Development
+
+The `mtls-auth-inbound` policy relies on verification metadata supplied by
+Zuplo's edge proxy and does not work in local development with `zuplo dev`. Test
+the policy in a working-copy or preview environment.
+
+## Troubleshooting
+
+### Requests are rejected with 401
+
+- Confirm the client is presenting a certificate signed by a CA that's been
+  uploaded with `zuplo ca-certificate list`.
+- If you've set `certIssuerDN`, verify it matches
+  `request.user.data.mtlsAuth.issuer` exactly (casing and whitespace are
+  tolerated, but RDN order is not).
+- Temporarily set `allowUnauthenticatedRequests: true` and log
+  `context.incomingRequestProperties.clientMtlsVerificationStatus` and
+  `context.incomingRequestProperties.clientMtlsVerificationReason` to see why
+  verification failed.
+
+### `request.user.data.mtlsAuth` is missing
+
+- The policy only attaches metadata when a parseable client certificate is
+  present on the request. Confirm the client is sending one.
+- Verify the route includes the `mtls-auth-inbound` policy.
+
+### Custom domains
+
+When a CA is uploaded, it's automatically associated with Zuplo's managed
+gateway domains. A custom domain must be _active_ in the dashboard (check the
+Settings/Custom Domains sidebar) before CA verification will become active on
+that custom domain.
+
+If you add a custom domain later and your clients aren't being verified against
+it, contact [support@zuplo.com](mailto:support@zuplo.com).
+
+## Additional Resources
+
+- [`mtls-auth-inbound` policy reference](../policies/mtls-auth-inbound.md)
+- [`ca-certificate` CLI reference](../cli/ca-certificate-create.md)
+- [Gateway to Origin mTLS Authentication](./securing-backend-mtls.mdx) — the
+  reverse direction, where Zuplo authenticates to your backend with a client
+  certificate
+
+If you need help configuring client mTLS for your account, contact us at
+[support@zuplo.com](mailto:support@zuplo.com).

package/docs/concepts/authentication.mdx

@@ -76,8 +76,8 @@ users already authenticate with an identity provider.
 
 - [Basic Auth](../policies/basic-auth-inbound.mdx) - Username/password
   authentication
-- [mTLS](../policies/mtls-auth-inbound.mdx) - Mutual TLS certificate
-  authentication
+- [mTLS](../articles/securing-the-gateway-with-client-mtls.mdx) - Mutual TLS
+  certificate authentication
 - [LDAP](../policies/ldap-auth-inbound.mdx) - LDAP directory authentication
 - [HMAC](../policies/hmac-auth-inbound.mdx) - Hash-based message authentication
 

package/docs/policies/mtls-auth-inbound/intro.md

@@ -15,9 +15,13 @@ certificate is present. If a parseable certificate is present, the policy still
 sets `request.user.data.mtlsAuth`; otherwise it leaves the request unchanged.
 
 Set `certIssuerDN` to the fully qualified issuer distinguished name to require
-on the client certificate. When set and enforcement is enabled, the policy
-rejects certificates whose parsed issuer DN does not match. Comparison is
-order-sensitive on RDNs (e.g. `"CN=foo, O=bar"` does not match
+on the client certificate. The policy rejects certificates whose parsed issuer
+DN does not match. `certIssuerDN` is required whenever enforcement is enabled
+(i.e. when `allowUnauthenticatedRequests` is not `true`); the policy fails to
+load otherwise. This guarantees that requests are pinned to a specific CA and is 
+especially important when an account has multiple CAs configured.
+
+Comparison is order-sensitive on RDNs (e.g. `"CN=foo, O=bar"` does not match
 `"O=bar, CN=foo"`, which matches RFC 4514 §2.1 semantics) but tolerant of
 casing and whitespace, so `"CN=example-ca, O=Example, C=US"` matches
 `"cn=Example-CA,o=example,c=us"`. Multi-valued RDNs (`+`) and hex-encoded
@@ -25,8 +29,5 @@ values (`#...`) are not normalized. The simplest way to obtain the expected
 value is to inspect `request.user.data.mtlsAuth.issuer` from a request signed
 by the desired CA.
 
-The `certIssuerDN` is useful when you want to distinguish between client certs from
-different CAs if you have multiple set on your account. It is recommended to set this by default.
-
 Note: this policy does not work with local development since it relies on metadata from the upstream reverse proxy,
 it is recommended to test this using a working-copy or preview environment.

package/docs/policies/mtls-auth-inbound/schema.json

@@ -41,10 +41,23 @@
             },
             "certIssuerDN": {
               "type": "string",
-              "description": "Optional fully qualified issuer distinguished name to require on the client certificate. When set, the policy rejects certificates whose parsed issuer DN does not match this string exactly. The expected format matches the parsed metadata issuer, e.g. \"CN=example-ca, O=Example, C=US\".",
+              "description": "Fully qualified issuer distinguished name to require on the client certificate. The policy rejects certificates whose parsed issuer DN does not match this string exactly. Required unless `allowUnauthenticatedRequests` is `true`. The expected format matches the parsed metadata issuer, e.g. \"CN=example-ca, O=Example, C=US\".",
               "examples": ["CN=example-ca, O=Example, C=US"]
             }
-          }
+          },
+          "anyOf": [
+            {
+              "required": ["certIssuerDN"]
+            },
+            {
+              "properties": {
+                "allowUnauthenticatedRequests": {
+                  "const": true
+                }
+              },
+              "required": ["allowUnauthenticatedRequests"]
+            }
+          ]
         }
       },
       "examples": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zuplo",
-  "version": "6.70.24",
+  "version": "6.70.26",
   "type": "module",
   "description": "The programmable API Gateway",
   "author": "Zuplo, Inc.",
@@ -19,9 +19,9 @@
     "zuplo": "zuplo.js"
   },
   "dependencies": {
-    "@zuplo/cli": "6.70.24",
-    "@zuplo/core": "6.70.24",
-    "@zuplo/runtime": "6.70.24",
+    "@zuplo/cli": "6.70.26",
+    "@zuplo/core": "6.70.26",
+    "@zuplo/runtime": "6.70.26",
     "@zuplo/test": "1.4.0"
   }
 }