zuplo 6.71.22 → 6.71.25

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

@@ -84,9 +84,9 @@ inside Zuplo)
 ```bash
 # Your Zuplo Account Name
 export ACCOUNT_NAME=my-account
-# Your bucket API URL (Found in Settings > General)
+# Your bucket name (Found in Services > API Key Service)
 export BUCKET_NAME=my-bucket
-# Your Zuplo API Key (Found in Settings > Zuplo API Keys)
+# Your Zuplo API Key (Found in Account Settings > Zuplo API Keys)
 export API_KEY=zpka_YOUR_API_KEY
 ```
 

package/docs/articles/hosting-options.mdx

@@ -46,16 +46,17 @@ For more information, see the
 
 ## 3. Self-Hosted (On-Premises)
 
-Run Zuplo on your own infrastructure in any cloud or private data center using
-Kubernetes. Zuplo Self-Hosted runs exclusively on Kubernetes and can be deployed
-to any Kubernetes environment. Deployment is simple and uses Helm charts.
-
-Self-Hosted is available in two deployment models:
-
-- **Hybrid Deployment**: Run the Zuplo API Gateway on your Kubernetes cluster
-  while leveraging shared services for features such as rate limiting
-- **Full Self-Hosted**: Run all Zuplo components on your Kubernetes cluster for
-  complete control and isolation
+Run Zuplo on your own infrastructure in any cloud or private data center. Zuplo
+Self-Hosted runs exclusively on Kubernetes and is installed with a single Helm
+chart into your cluster.
+
+In the standard hybrid deployment model, you run the Zuplo API Gateway and its
+management plane on your Kubernetes cluster, while a small set of Zuplo cloud
+services provides supporting features such as deployment configuration and API
+key management. All API traffic to your gateways stays on your infrastructure.
+For environments with strict egress restrictions,
+[book a meeting](https://zuplo.com/meeting) to review your requirements with the
+Zuplo team.
 
 Self-Hosted is ideal for organizations that need:
 
@@ -63,8 +64,8 @@ Self-Hosted is ideal for organizations that need:
 - To run Zuplo in a private data center or on-premises Kubernetes environment
 - To meet strict data sovereignty or regulatory requirements
 - To integrate with existing on-premises systems and networks
-- To customize the deployment architecture to match your specific requirements
 
 For more information, see the
-[Self-Hosted documentation](/docs/self-hosted/overview) or
-[book a meeting](https://zuplo.com/meeting) with us.
+[Self-Hosted documentation](/docs/self-hosted/overview.md), including the
+[requirements](/docs/self-hosted/overview.md#requirements) to prepare for a
+deployment, or [book a meeting](https://zuplo.com/meeting) with the Zuplo team.

package/docs/guides/proxying-between-zuplo-gateways.mdx

@@ -2,9 +2,8 @@
 title: Proxying Between Zuplo Gateways
 sidebar_label: Proxying Between Gateways
 description:
-  Learn how to proxy requests from one Zuplo project to another using the URL
-  Forward Handler or a custom fetch handler, propagate authentication, surface
-  upstream errors, and troubleshoot 522 timeouts.
+  Learn how to proxy requests from one Zuplo gateway to another, propagate
+  authentication, handle upstream errors, and fix 522 timeouts.
 tags:
   - backends
   - deployment

package/docs/self-hosted/overview.md

@@ -3,58 +3,145 @@ title: Zuplo Self-Hosted
 sidebar_label: Overview
 ---
 
-Zuplo Self-Hosted (also known as on-premises) is a deployment model where you
-run Zuplo on your own infrastructure in any cloud or private data center. Zuplo
-Self-Hosted runs exclusively on Kubernetes and can be deployed to any Kubernetes
-environment. Deployment is simple and uses Helm charts.
+Zuplo Self-Hosted (also known as on-prem) is a deployment model where you run
+the Zuplo API Gateway on your own infrastructure — any cloud or private data
+center. Zuplo Self-Hosted runs exclusively on Kubernetes and is installed with a
+single Helm chart into your cluster.
 
 Self-hosted deployment might be the right choice for you if you need:
 
 - Complete control over your infrastructure and deployment environment
 - To run Zuplo in a private data center or on-premises environment
-- To meet strict data sovereignty or regulatory requirements that require data
-  to remain within your infrastructure
+- To meet data sovereignty or regulatory requirements that require API traffic
+  and data to remain within your infrastructure
 - To integrate with existing on-premises systems and networks
-- To customize the deployment architecture to match your organization's specific
-  requirements
 
-## Deployment Options
+## How It Works
 
-Zuplo Self-Hosted offers two deployment models:
+Your cluster runs two groups of workloads: a small Zuplo management plane that
+receives deployments, builds gateway images inside your cluster, and manages
+certificates and routing, and the gateway deployments themselves, which serve
+your API traffic. Developers deploy to your instance directly with the Zuplo CLI
+— the same Zuplo project format and deployment workflow used on every other
+Zuplo deployment model. Gateway images are built in-cluster and stored in your
+own container registry, and API traffic is served entirely from your
+infrastructure.
+
+## Deployment Models
 
 ### Hybrid Deployment
 
-In a hybrid deployment, you run the Zuplo API Gateway on your infrastructure
-while leveraging shared services for features such as rate limiting. This
-approach provides a balance between control and operational simplicity, allowing
-you to maintain your gateway infrastructure while benefiting from managed
-services for specific features.
+You run the gateway and management plane on your infrastructure, while a small
+set of Zuplo cloud services provides supporting features such as deployment
+configuration and API key management. All API traffic to your gateways stays on
+your infrastructure. This is the standard deployment model.
+
+### Restricted-Egress Environments
+
+For environments with strict egress restrictions or stronger isolation
+requirements, [book a meeting](https://zuplo.com/meeting) to review your
+requirements with the Zuplo team.
+
+## Responsibilities
+
+Self-hosting keeps you in control of your infrastructure while Zuplo supplies
+everything Zuplo-specific — the chart, the images, and the support to run them
+well:
+
+| Phase   | Your team                                                                        | Zuplo                                                                       |
+| ------- | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |
+| Prepare | Kubernetes cluster, DNS records, TLS certificates (optional), container registry | Registry credentials, account configuration, installation guide             |
+| Install | Run the Helm install in your cluster                                             | Helm chart, component images, starter configuration reviewed with your team |
+| Operate | Cluster operations, applying updates                                             | Updated charts and images, support                                          |
+
+:::tip
+
+If this division of responsibilities doesn't fit your organization,
+[book a meeting](https://zuplo.com/meeting) with the Zuplo team. For teams that
+prefer Zuplo to run the infrastructure,
+[Managed Dedicated](../dedicated/overview.mdx) offers the same gateway fully
+operated by Zuplo.
+
+:::
+
+## Requirements
+
+This section lists what your team needs to prepare before installing Zuplo
+Self-Hosted. Use it to plan your platform and security review. Your Zuplo
+solutions architect walks through each item during onboarding.
+
+### Kubernetes Cluster
+
+- A conformant Kubernetes cluster — managed offerings such as EKS, AKS, and GKE,
+  or your own distribution.
+- Support for Services of type `LoadBalancer` to expose the ingress.
+- Cluster administrator access for the initial install (the chart installs CRDs
+  and cluster-scoped RBAC).
+- Zuplo builds gateway images inside your cluster. The build process runs
+  privileged pods, so clusters that enforce a restricted Pod Security Standard
+  cluster-wide need accommodations — discuss this with your Zuplo solutions
+  architect during onboarding.
+- Helm 3 on the machine performing the install; supported versions are confirmed
+  during onboarding.
+
+### DNS and TLS
+
+You control DNS for two names, both pointing at the cluster's ingress load
+balancer:
+
+- A wildcard subdomain for your gateway environments, for example
+  `*.api.example.com` — each deployed gateway environment receives a hostname
+  under it.
+- A hostname for the management API, for example `zuplo-admin.example.com` —
+  used by the Zuplo CLI and your CI/CD pipelines to deploy.
+
+For TLS you can either:
+
+- Use the bundled cert-manager to issue certificates automatically from an ACME
+  certificate authority (for example Let's Encrypt), which requires the
+  hostnames to be reachable for HTTP-01 challenges, or
+- Bring your own wildcard certificate as a Kubernetes TLS secret — common in
+  private-network deployments.
+
+### Container Registry
+
+Gateway images are built inside your cluster and pushed to a container registry
+that you provide. You need:
+
+- A registry your cluster can push to and pull from (for example ACR, Google
+  Artifact Registry, GitHub Container Registry, or a private Harbor).
+- Write credentials for that registry, supplied at install time.
+
+### Network Egress
+
+In the hybrid deployment model, the cluster needs outbound HTTPS access to:
 
-### Full Self-Hosted
+- Zuplo's private container registry, to pull Zuplo's component images
+  (credentials provided during onboarding).
+- Zuplo cloud services, used for deployment configuration and management API
+  authentication.
+- Your ACME certificate authority, if using automatic certificates.
 
-In a full self-hosted deployment, you run all Zuplo components on your
-infrastructure. This provides complete control and isolation, ensuring that all
-data and processing remain within your environment.
+The exact hostnames for your egress allow-list are provided during onboarding.
+If your environment can't allow this egress,
+[book a meeting](https://zuplo.com/meeting) to review options with the Zuplo
+team.
 
-## Features
+### Provided by Zuplo During Onboarding
 
-The self-hosted deployment model provides the same core features as other Zuplo
-deployment models. You can use all the same policies, integrations, and features
-as you would with edge-based or managed dedicated deployments.
+- Credentials to pull Zuplo component images from Zuplo's private registry.
+- Your account configuration and an API key for the management API.
+- The Helm chart, an installation guide, and a starter configuration reviewed
+  with your team.
 
-In addition to the standard features, self-hosted deployment provides:
+### Observability
 
-- **Kubernetes-Based**: Deploy to any Kubernetes environment using simple Helm
-  charts
-- **Complete Control**: Full control over your infrastructure, networking, and
-  security configurations
-- **Data Sovereignty**: Keep all data and processing within your infrastructure
-- **Custom Networking**: Integrate with your existing network architecture and
-  security policies
-- **Compliance**: Meet regulatory and compliance requirements that require
-  on-premises deployment
+The chart bundles a Prometheus-based metrics stack that Zuplo components use for
+autoscaling gateway deployments. You can integrate your own logging and
+monitoring stack alongside it; gateway and component logs are written to
+standard output for collection by your log shipper.
 
 ## Getting Started
 
 To learn more about self-hosting Zuplo or to discuss your specific requirements,
-[book a meeting](https://zuplo.com/meeting) with us.
+[book a meeting](https://zuplo.com/meeting) with the Zuplo team.

package/package.json

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