npm - zuplo - Versions diffs - 7.12.5 → 7.12.7 - Mend

zuplo 7.12.5 → 7.12.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (579) hide show

package/docs/articles/tunnel-advanced.mdx CHANGED Viewed

@@ -1,6 +1,18 @@
 ---
 title: Advanced Tunnel Configuration
 sidebar_label: Advanced
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: >-
+      Tunnels work on Managed Dedicated, but most teams connect to private
+      backends with their cloud provider's native networking, such as a transit
+      gateway or VPC peering. See [Networking](../dedicated/networking.mdx).
+    self-hosted: >-
+      Tunnels work on Self-Hosted, but your gateway already runs on your
+      network, so most teams reach private backends directly or with native
+      networking, such as a transit gateway or VPC peering.
 ---
 <EnterpriseFeature name="Secure tunneling" />
@@ -8,40 +20,22 @@ sidebar_label: Advanced
 The [`zuplo/tunnel`](https://hub.docker.com/r/zuplo/tunnel) image covers most
 deployments without configuration beyond `TUNNEL_TOKEN`. This page is for teams
 that need more control: pinning versions, tuning the transport, rotating tokens,
-or building and running the connector image themselves.
+or mirroring the image into their own registry.
-## The cloudflared foundation
+## How the image runs
-Zuplo's tunnel is a thin packaging of
-[cloudflared](https://github.com/cloudflare/cloudflared), Cloudflare's open
-source tunnel connector. It isn't a Zuplo-specific protocol or a proprietary
-agent. The entire `zuplo/tunnel` image is the upstream
-[`cloudflare/cloudflared`](https://hub.docker.com/r/cloudflare/cloudflared)
-image with a fixed entrypoint:
+The image starts the tunnel with fixed settings:
-```dockerfile title="Dockerfile"
-FROM cloudflare/cloudflared:2026.7.3-amd64
-ENTRYPOINT ["cloudflared", "tunnel", "--no-autoupdate", "--protocol", "http2", "run"]
-```
-Two consequences follow from this. First, everything the
-[cloudflared documentation](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/)
-says about deploying, monitoring, and tuning a connector applies to your Zuplo
-tunnel. Second, you can run the upstream image yourself instead of Zuplo's — see
-[Run your own connector image](#run-your-own-connector-image).
-### Entrypoint flags
-| Flag               | Why the image sets it                                                                                                                                                                                                                        |
-| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `--no-autoupdate`  | Stops cloudflared from replacing its own binary while running. The image tag is then the only thing that determines the version, which keeps containers immutable and deployments reproducible.                                              |
-| `--protocol http2` | Forces the HTTP/2 transport. The cloudflared default, `auto`, prefers QUIC over UDP port 7844 and falls back to HTTP/2 when it can't open UDP connections. Many corporate networks block outbound UDP, so pinning HTTP/2 skips the fallback. |
-| `run`              | Runs a remotely-managed tunnel. The tunnel's routing configuration lives in Zuplo, not in a local config file, and cloudflared reads its credentials from `TUNNEL_TOKEN`.                                                                    |
+| Setting                  | Why the image sets it                                                                                                                                                                                    |
+| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| No automatic updates     | The tunnel never replaces its own binary while running. The image tag is the only thing that determines the version, which keeps containers immutable and deployments reproducible.                      |
+| HTTP/2 transport         | The tunnel connects over HTTP/2 on TCP port 443. Many corporate networks block outbound UDP, so the image doesn't try a UDP transport first.                                                             |
+| Remotely managed routing | The tunnel's routing configuration lives in Zuplo, not in a local config file. The tunnel reads its credentials from `TUNNEL_TOKEN` and fetches the rest of its configuration from Zuplo when it starts. |
 ### Container characteristics
-Because the image inherits the upstream cloudflared base, it has properties
-worth knowing when you write a deployment manifest or a security policy:
+The image has properties worth knowing when you write a deployment manifest or a
+security policy:
 - **Distroless base, no shell.** You can't exec into a running tunnel container
   to debug it. Run a separate debug container in the same network namespace
@@ -55,33 +49,31 @@ worth knowing when you write a deployment manifest or a security policy:
 ## Environment variables
-The tunnel reads cloudflared's environment variables. The ones that matter for a
-Zuplo tunnel:
+The tunnel reads these environment variables:
 | Variable                    | Default | Description                                                                                            |
 | --------------------------- | ------- | ------------------------------------------------------------------------------------------------------ |
 | `TUNNEL_TOKEN`              | none    | The tunnel's connection token, from `zuplo tunnel describe`. Required.                                 |
 | `TUNNEL_LOGLEVEL`           | `info`  | Log verbosity. One of `debug`, `info`, `warn`, `error`, or `fatal`. Use `debug` when troubleshooting.  |
 | `TUNNEL_METRICS`            | none    | Address to serve Prometheus metrics on, such as `0.0.0.0:2000`. Useful for scraping connection health. |
-| `TUNNEL_TRANSPORT_PROTOCOL` | `auto`  | Transport to Cloudflare's edge. One of `auto`, `http2`, or `quic`.                                     |
+| `TUNNEL_TRANSPORT_PROTOCOL` | `auto`  | Transport the tunnel uses to connect to Zuplo. One of `auto`, `http2`, or `quic`.                      |
 | `NO_AUTOUPDATE`             | `false` | Disables in-place binary updates.                                                                      |
-| `TUNNEL_EDGE_IP_VERSION`    | `4`     | IP version for reaching the edge. One of `4`, `6`, or `auto`.                                          |
+| `TUNNEL_EDGE_IP_VERSION`    | `4`     | IP version for connecting to Zuplo. One of `4`, `6`, or `auto`.                                        |
-:::caution{title="Flags override environment variables"}
+:::caution{title="Image settings override environment variables"}
-The `zuplo/tunnel` image sets `--no-autoupdate` and `--protocol http2` as
-command-line flags in its entrypoint, and cloudflared gives command-line flags
-precedence over environment variables. Setting `NO_AUTOUPDATE` or
-`TUNNEL_TRANSPORT_PROTOCOL` on a `zuplo/tunnel` container has no effect. To
-change either one, build your own image with a different entrypoint.
+The `zuplo/tunnel` image turns off automatic updates and sets the HTTP/2
+transport on its command line, which takes precedence over environment
+variables. Setting `NO_AUTOUPDATE` or `TUNNEL_TRANSPORT_PROTOCOL` on a
+`zuplo/tunnel` container has no effect.
 :::
 ## Pin and upgrade the image version
-The `zuplo/tunnel` tags mirror the cloudflared release they wrap, so
-`zuplo/tunnel:2025.10.1` contains cloudflared 2025.10.1. The `latest` tag always
-points at the most recent release.
+The `zuplo/tunnel` tags are date-based versions, such as
+`zuplo/tunnel:2025.10.1`. The `latest` tag always points at the most recent
+release.
 For production, pin an explicit tag rather than using `latest`, so a redeploy
 can't silently change connector versions:
@@ -92,11 +84,11 @@ docker run -d --name zuplo-tunnel \
   zuplo/tunnel:2025.10.1
 ```
-Then upgrade deliberately. Cloudflare supports cloudflared versions released
-within one year of the most recent release, and may introduce breaking changes
-that affect older versions. Check for a newer tag on a regular cadence and treat
-the upgrade as routine maintenance. Test each new version in a staging
-environment before rolling it out to production.
+Then upgrade deliberately. Versions more than a year older than the latest
+release can stop working, and new releases can include breaking changes. Check
+for a newer tag on a regular cadence and treat the upgrade as routine
+maintenance. Test each new version in a staging environment before rolling it
+out to production.
 Because tunnel instances that share a token act as replicas, you can upgrade
 without downtime: start instances on the new version, wait for them to connect,
@@ -130,69 +122,21 @@ With at least two instances running, you can rotate without dropping traffic.
 Rotating with a single instance running causes a brief interruption while the
 instance restarts. Schedule it during a maintenance window.
-## Run your own connector image
-Because the tunnel is stock cloudflared, you can build and run the connector
-yourself. Consider this when you need to:
-- Change the entrypoint flags, such as running QUIC instead of HTTP/2, or
-  exposing the metrics endpoint.
-- Mirror the image into your own registry to satisfy a policy that forbids
-  pulling from public registries.
-- Meet a scanning, signing, or base-image requirement your platform enforces.
-- Run on `arm64`, using a matching upstream tag.
+## Mirror the image into your registry
-To match the behavior of `zuplo/tunnel`, build from the upstream image and
-replicate the entrypoint:
-```dockerfile title="Dockerfile"
-FROM cloudflare/cloudflared:2026.7.3-amd64
-ENTRYPOINT ["cloudflared", "tunnel", "--no-autoupdate", "--protocol", "http2", "run"]
-```
-Replace `2026.7.3` with a current tag from
-[Docker Hub](https://hub.docker.com/r/cloudflare/cloudflared/tags) — a version
-pinned here goes stale, and running a connector more than a year behind the
-latest release falls outside Cloudflare's support window. Use the `-amd64` or
-`-arm64` suffix that matches your host architecture.
-Build and run it with the same `TUNNEL_TOKEN` you'd give the Zuplo image:
+If a policy forbids pulling from public registries, copy `zuplo/tunnel` into
+your own registry and run it from there. Keep the image unchanged and pass the
+same `TUNNEL_TOKEN`:
 ```bash
-docker build -t my-registry/tunnel:2026.7.3 .
-docker run -d --name tunnel \
-  -e TUNNEL_TOKEN=<YOUR_TUNNEL_TOKEN> \
-  my-registry/tunnel:2026.7.3
+docker pull zuplo/tunnel:2025.10.1
+docker tag zuplo/tunnel:2025.10.1 my-registry/zuplo-tunnel:2025.10.1
+docker push my-registry/zuplo-tunnel:2025.10.1
 ```
-You can also run the upstream image directly, without a Dockerfile, by supplying
-the command yourself:
-```bash
-docker run -d --name tunnel \
-  -e TUNNEL_TOKEN=<YOUR_TUNNEL_TOKEN> \
-  cloudflare/cloudflared:2026.7.3-amd64 \
-  tunnel --no-autoupdate --protocol http2 run
-```
-:::caution
-Keep the `run` subcommand and don't add a local configuration file, credentials
-file, or `--url` argument. Your tunnel is remotely managed: Zuplo owns the
-routing configuration, and cloudflared fetches it using the token. Local
-configuration conflicts with that and can stop traffic reaching your services.
-:::
-:::note
-Zuplo tests and supports the `zuplo/tunnel` image. A connector image you build
-and operate yourself is yours to maintain, and support can help with the tunnel
-and its configuration in Zuplo but not with your image or build pipeline. If
-you're unsure whether a change is safe, ask
-[Zuplo support](mailto:support@zuplo.com) before rolling it out.
-:::
+Mirror each new version the same way when you upgrade. Zuplo tests and supports
+the `zuplo/tunnel` image. If you change the image or build your own, support can
+help with the tunnel and its configuration in Zuplo but not with your image.
 ## Next steps

package/docs/articles/tunnel-services.mdx CHANGED Viewed

@@ -1,6 +1,18 @@
 ---
 title: Connect to Tunnel Services
 sidebar_label: Connect to Services
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: >-
+      Tunnels work on Managed Dedicated, but most teams connect to private
+      backends with their cloud provider's native networking, such as a transit
+      gateway or VPC peering. See [Networking](../dedicated/networking.mdx).
+    self-hosted: >-
+      Tunnels work on Self-Hosted, but your gateway already runs on your
+      network, so most teams reach private backends directly or with native
+      networking, such as a transit gateway or VPC peering.
 ---
 <EnterpriseFeature name="Secure tunneling" />
@@ -159,7 +171,7 @@ handler combines the variable with a path parameter:
 ## Next steps
-- [Advanced tunnel configuration](./tunnel-advanced.mdx) — the cloudflared
-  foundation, environment variables, and self-managed images.
+- [Advanced tunnel configuration](./tunnel-advanced.mdx) — image settings,
+  environment variables, and version pinning.
 - [Troubleshoot a tunnel](./tunnel-troubleshooting.mdx) — diagnose requests that
   don't reach your backend.

package/docs/articles/tunnel-setup.mdx CHANGED Viewed

@@ -1,6 +1,18 @@
 ---
 title: Set up a Tunnel
 sidebar_label: Setup
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: >-
+      Tunnels work on Managed Dedicated, but most teams connect to private
+      backends with their cloud provider's native networking, such as a transit
+      gateway or VPC peering. See [Networking](../dedicated/networking.mdx).
+    self-hosted: >-
+      Tunnels work on Self-Hosted, but your gateway already runs on your
+      network, so most teams reach private backends directly or with native
+      networking, such as a transit gateway or VPC peering.
 ---
 <EnterpriseFeature name="Secure tunneling" />

package/docs/articles/tunnel-troubleshooting.mdx CHANGED Viewed

@@ -1,6 +1,18 @@
 ---
 title: Troubleshoot a Tunnel
 sidebar_label: Troubleshooting
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: >-
+      Tunnels work on Managed Dedicated, but most teams connect to private
+      backends with their cloud provider's native networking, such as a transit
+      gateway or VPC peering. See [Networking](../dedicated/networking.mdx).
+    self-hosted: >-
+      Tunnels work on Self-Hosted, but your gateway already runs on your
+      network, so most teams reach private backends directly or with native
+      networking, such as a transit gateway or VPC peering.
 ---
 A tunnel spans your network and Zuplo's, so traffic often fails to reach its

package/docs/articles/update-zup-in-github-action.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Automate Zuplo API Updates with GitHub Actions
 sidebar_label: GitHub Action Automation
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <!-- vale Vale.Spelling["Huma"] = NO -->

package/docs/articles/upstream-iam-auth.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: IAM Authentication for Your Backend
 sidebar_label: Overview
+applies_to:
+  product: gateway
+  hosting: all
 ---
 IAM authentication lets your cloud provider decide whether a request from Zuplo

package/docs/articles/use-openapi-extension-data.mdx CHANGED Viewed

@@ -7,6 +7,9 @@ description:
 tags:
   - openapi
   - custom-code
+applies_to:
+  product: gateway
+  hosting: all
 ---
 The OpenAPI specification allows for the use of vendor-specific extensions to

package/docs/articles/users/multifactor-authentication.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Multifactor Authentication
 sidebar_label: Multifactor Auth
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Zuplo supports multifactor authentication (MFA) to help keep your account

package/docs/articles/users/profile.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: User Profile
 sidebar_label: Profile
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Your user profile is set automatically by your identity provider when you sign

package/docs/articles/version-support-policy.mdx CHANGED Viewed

@@ -5,6 +5,9 @@ description:
   How Zuplo approaches versioning, backward compatibility, deprecations, and
   breaking changes across the gateway runtime, specification-based features, and
   the Developer Portal.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Zuplo runs production traffic for its customers, so backward compatibility is a

package/docs/articles/versioning-on-zuplo.mdx CHANGED Viewed

@@ -7,6 +7,9 @@ description: >-
 tags:
   - openapi
   - custom-code
+applies_to:
+  product: gateway
+  hosting: all
 ---
 This guide explains how to approach versioning APIs on Zuplo.

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

@@ -1,6 +1,9 @@
 ---
 title: Configuring Zuplo with Akamai App & API Protector
 sidebar_label: Akamai App & API Protector
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Akamai App & API Protector runs at Akamai edge locations. Zuplo can be

package/docs/articles/waf-ddos-aws-waf-shield.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Configuring Zuplo with AWS WAF + Shield
 sidebar_label: AWS WAF + Shield
+applies_to:
+  product: gateway
+  hosting: all
 ---
 AWS WAF + Shield run at AWS CloudFront edge locations. Zuplo can be configured

package/docs/articles/waf-ddos-fastly.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Configuring Zuplo with Fastly Next-Gen WAF
 sidebar_label: Fastly Next-Gen WAF
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Fastly Next-Gen WAF runs at Fastly edge locations. Zuplo can be configured to

package/docs/articles/waf-ddos.mdx CHANGED Viewed

@@ -1,5 +1,13 @@
 ---
 title: Zuplo + WAF/DDoS Services
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: >-
+      Use the WAF offered by your hosting platform in front of the gateway.
+    self-hosted: >-
+      Use the WAF offered by your hosting platform in front of the gateway.
 ---
 Many customers using Zuplo (or any other gateway) often choose to deploy WAF and

package/docs/articles/when-to-use-api-keys.md CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: When to Use API Keys
 sidebar_label: When to Use Them
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Choosing the right authentication method is one of the first decisions you make

package/docs/articles/workload-identity-inbound.mdx CHANGED Viewed

@@ -6,6 +6,9 @@ description:
   own ambient credentials, then pin the route to the workloads you allow.
 tags:
   - authentication
+applies_to:
+  product: gateway
+  hosting: all
 ---
 A workload running in a cloud already has an identity: a Google service account,

package/docs/build-with-ai.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Build with AI
 sidebar_label: Build with AI
+applies_to:
+  product: gateway
+  hosting: all
 ---
 AI coding agents — Claude Code, Cursor, GitHub Copilot, Codex, Windsurf, and

package/docs/caching/cdn-caching.mdx CHANGED Viewed

@@ -4,6 +4,9 @@ description:
   Put a CDN in front of your Zuplo gateway and drive its cache from response
   headers, with separate edge and client TTLs, per-entity purge tags, and stale
   responses through a backend outage.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 A CDN in front of your gateway serves the cheapest request your API will ever

package/docs/caching/custom-caching-policy.mdx CHANGED Viewed

@@ -4,6 +4,9 @@ description:
   Write your own inbound and outbound policy pair with the Cache API when no
   built-in policy fits your caching rules, from tenant-scoped keys and size and
   status filters to upstream-driven TTLs and independent invalidation.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Custom caching code is the most expensive caching you can ship. You own it, you

package/docs/caching/dynamic-cache-rules.mdx CHANGED Viewed

@@ -5,6 +5,9 @@ description:
   TTLs and purge tags that depend on the individual request or response,
   including per-entity tags, route TTL matrices, and refusing to cache a bad
   payload.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 Static policy options answer one question: how should this route cache? That's

package/docs/caching/gateway-caching.mdx CHANGED Viewed

@@ -4,6 +4,9 @@ description:
   Use the Caching policy to store responses inside the Zuplo gateway so repeat
   requests never reach your backend. Covers cache keys, TTLs, authorization, and
   invalidation.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 The Caching policy (`caching-inbound`) stores a response inside the gateway and

package/docs/caching/overview.mdx CHANGED Viewed

@@ -5,6 +5,9 @@ description:
   Compare the four places a response can be cached when Zuplo sits in front of
   your API, what each layer costs on a miss, and how to pick the right one for a
   given endpoint.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 A cached response is one your backend never serves. Every hit removes a database

package/docs/caching/partial-response-caching.mdx CHANGED Viewed

@@ -4,6 +4,9 @@ description:
   Cache the shared portion of a response body in the programmable cache and
   fetch only the small caller-specific slice from your backend on every request.
   A worked example that turns a thousand backend calls a minute into six.
+applies_to:
+  product: gateway
+  hosting: all
 ---
 A cinema-ticketing API serves `GET /v1/showtimes/board`. Every response contains

package/docs/cli/authentication.mdx CHANGED Viewed

@@ -1,5 +1,8 @@
 ---
 title: Authentication
+applies_to:
+  product: gateway
+  hosting: all
 ---
 There are two ways to authenticate with the Zuplo Command Line Interface (CLI):

package/docs/cli/bucket-list.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Bucket List"
 sidebar_label: bucket list
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/ca-certificate-create.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Ca Certificate Create"
 sidebar_label: ca-certificate create
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/ca-certificate-delete.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Ca Certificate Delete"
 sidebar_label: ca-certificate delete
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/ca-certificate-describe.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Ca Certificate Describe"
 sidebar_label: ca-certificate describe
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/ca-certificate-list.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Ca Certificate List"
 sidebar_label: ca-certificate list
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/ca-certificate-update.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: "Zuplo CLI: Ca Certificate Update"
 sidebar_label: ca-certificate update
+applies_to:
+  product: gateway
+  hosting: all
 ---
 <CliCommand

package/docs/cli/connectivity.mdx CHANGED Viewed

@@ -1,6 +1,9 @@
 ---
 title: Zuplo CLI Network Connectivity
 sidebar_label: Network Connectivity
+applies_to:
+  product: gateway
+  hosting: all
 ---
 The Zuplo CLI is used for local development as well as performing various

package/docs/cli/create-zuplo-api.mdx CHANGED Viewed

@@ -1,5 +1,8 @@
 ---
 title: Create Zuplo API
+applies_to:
+  product: gateway
+  hosting: all
 ---
 The `create-zuplo-api` CLI makes it easy to create a new Zuplo API using the

package/docs/cli/custom-domain-create.mdx CHANGED Viewed

@@ -1,6 +1,12 @@
 ---
 title: "Zuplo CLI: Custom Domain Create"
 sidebar_label: custom-domain create
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: "Custom domains depend on your instance's configuration, and Zuplo usually configures them for you. See [Managed Dedicated: Custom Domains](../dedicated/custom-domains.mdx)."
+    self-hosted: "Custom domains depend on your cluster's configuration, because you manage DNS and certificates. See [Self-Hosted requirements](../self-hosted/requirements.md)."
 ---
 <CliCommand

package/docs/cli/custom-domain-delete.mdx CHANGED Viewed

@@ -1,6 +1,12 @@
 ---
 title: "Zuplo CLI: Custom Domain Delete"
 sidebar_label: custom-domain delete
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: "Custom domains depend on your instance's configuration, and Zuplo usually configures them for you. See [Managed Dedicated: Custom Domains](../dedicated/custom-domains.mdx)."
+    self-hosted: "Custom domains depend on your cluster's configuration, because you manage DNS and certificates. See [Self-Hosted requirements](../self-hosted/requirements.md)."
 ---
 <CliCommand

package/docs/cli/custom-domain-list.mdx CHANGED Viewed

@@ -1,6 +1,12 @@
 ---
 title: "Zuplo CLI: Custom Domain List"
 sidebar_label: custom-domain list
+applies_to:
+  product: gateway
+  hosting: all
+  differs:
+    managed-dedicated: "Custom domains depend on your instance's configuration, and Zuplo usually configures them for you. See [Managed Dedicated: Custom Domains](../dedicated/custom-domains.mdx)."
+    self-hosted: "Custom domains depend on your cluster's configuration, because you manage DNS and certificates. See [Self-Hosted requirements](../self-hosted/requirements.md)."
 ---
 <CliCommand