zuplo 6.68.3 → 6.68.5

package/docs/articles/hosting-options.mdx

@@ -25,10 +25,10 @@ For more information, see the
 
 ## 2. Managed Dedicated
 
-We run your gateway in a dedicated, isolated VPC on the cloud provider of your
-choice, including Akamai Connected Cloud, AWS, GCP, Azure, Equinix, TerraSwitch,
-and more. You get to choose the regions where you want your service hosted to
-meet any sovereignty or data residency concerns.
+We run your gateway in a dedicated, isolated network environment on the cloud
+provider of your choice, including Akamai Connected Cloud, AWS, GCP, Azure,
+Equinix, TerraSwitch, and more. You get to choose the regions where you want
+your service hosted to meet any sovereignty or data residency concerns.
 
 Managed Dedicated is ideal for organizations that need:
 
@@ -38,7 +38,7 @@ Managed Dedicated is ideal for organizations that need:
 - Geographical deployment requirements where Managed Edge isn't feasible
 - Regulatory or compliance requirements that necessitate a dedicated instance
 - Private networking options like AWS PrivateLink, Azure Private Link, or GCP
-  Private Service Connect (available for both inbound and outbound connections)
+  Private Service Connect, depending on the traffic pattern and cloud provider
 
 For more information, see the
 [Managed Dedicated documentation](/docs/dedicated/overview.mdx) or

package/docs/dedicated/architecture.mdx

@@ -6,8 +6,8 @@ sidebar_label: Architecture
 Zuplo's managed dedicated instances are highly available, scalable, and secure.
 With a managed dedicated instance of Zuplo, your API Gateway runs on isolated
 instances and, when running on a cloud provider that supports it, a dedicated
-VPC. This document outlines the components and architecture of a managed
-dedicated instance of a Zuplo API Gateway.
+network environment. This document outlines the components and architecture of a
+managed dedicated instance of a Zuplo API Gateway.
 
 ## Components
 
@@ -84,7 +84,7 @@ instance of Zuplo and how the components interact with each other.
 
 <Diagram height="h-64">
   <DiagramNode id="client">Client</DiagramNode>
-  <DiagramGroup id="dedicated-vpc" label="Dedicated VPC">
+  <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
       Zuplo API Gateway
     </DiagramNode>
@@ -92,7 +92,7 @@ instance of Zuplo and how the components interact with each other.
       Gateway Services
     </DiagramNode>
   </DiagramGroup>
-  <DiagramGroup id="customer-vpc" label="Customer VPC">
+  <DiagramGroup id="customer-vpc" label="Customer Private Network">
     <DiagramNode id="backend">Backend</DiagramNode>
   </DiagramGroup>
   <DiagramNode id="control" variant="zuplo">
@@ -175,7 +175,7 @@ hosts only the production deployment, while the non-production instance hosts
 many other deployments (for example staging, development, QA, or any feature
 branch deployments).
 
-Each instance operates in isolation and runs within its own VPC or network.
+Each instance operates in isolation and runs within its own network environment.
 
 It's possible to have multiple instances depending on your requirements. For
 example, some customers have separate instances for production, staging, and

package/docs/dedicated/aws-private-networking.mdx

@@ -0,0 +1,139 @@
+---
+title: "Managed Dedicated: AWS Private Networking"
+sidebar_label: AWS Private Networking
+---
+
+Zuplo Managed Dedicated can run on AWS and connect privately to backends that
+aren't exposed to the public internet. This includes private services running
+inside your VPC, internal load balancers, and services published through AWS
+PrivateLink.
+
+This page focuses on customer-facing requirements and the common AWS patterns
+used to connect Zuplo to private backends.
+
+## When to use this
+
+AWS private networking is a good fit when you need to:
+
+- Keep your backend off the public internet while still using Zuplo as the
+  public API entry point
+- Connect Zuplo to services running privately inside one or more AWS VPCs
+- Reach internal services over private IPs instead of public endpoints
+- Meet internal security or compliance requirements around network isolation
+
+## AWS connectivity options
+
+The three most common AWS patterns are:
+
+### 1. AWS PrivateLink
+
+This is usually the preferred option when your backend can be exposed as a
+PrivateLink service.
+
+Typical use cases:
+
+- Services published through an AWS PrivateLink endpoint service
+- Cross-account private service access
+- Single-service connectivity where you want service-level access instead of
+  broader VPC access
+
+Why teams choose this pattern:
+
+- Access is scoped to a specific service instead of an entire VPC
+- It works well across AWS accounts
+- It reduces the network coordination needed compared with broader peering
+  patterns
+
+### 2. VPC peering
+
+This is the right option when Zuplo needs private network access into a single
+customer VPC and the backend is reachable by private IP.
+
+Typical use cases:
+
+- Internal load balancers
+- Private ECS or EKS services
+- Self-managed applications reachable only inside a VPC
+
+Why teams choose this pattern:
+
+- It is a simple fit for one-to-one VPC connectivity
+- Zuplo can reach internal services that are not exposed through PrivateLink
+- It works well when the backend lives in a small number of VPCs
+
+### 3. Transit Gateway
+
+This is usually the best option when the customer already uses a hub-and-spoke
+AWS network design or needs connectivity across multiple VPCs.
+
+Typical use cases:
+
+- Multi-VPC AWS environments
+- Shared services VPCs
+- More complex enterprise network topologies
+
+Why teams choose this pattern:
+
+- It scales better than maintaining many point-to-point VPC peerings
+- It fits existing AWS network hub designs
+- It is often the cleanest option when Zuplo must reach multiple private
+  backends
+
+## What is required from your side
+
+The exact setup depends on your AWS design, but most projects need:
+
+- The AWS region or regions where Zuplo should run
+- The target service details, such as VPC IDs, account IDs, or PrivateLink
+  service details
+- A DNS plan for private name resolution
+- Route table and security group approval
+- Non-overlapping CIDR ranges if VPC peering or Transit Gateway is used
+
+If your team manages AWS through Terraform, Zuplo can work within that model.
+The ownership split depends on your environment and security model.
+
+## DNS requirements
+
+Private connectivity on AWS depends on DNS as much as it depends on routing.
+
+For private connectivity to work, Zuplo needs to resolve your backend to the
+correct private address or endpoint. That usually means one of the following:
+
+- Using private DNS with AWS PrivateLink
+- Using your existing Route 53 private hosted zone design
+- Using your shared DNS resolver strategy
+
+Without the correct DNS configuration, the network path can exist while traffic
+still resolves to the public endpoint.
+
+## Planning considerations
+
+Before implementation, align on:
+
+- Whether **PrivateLink**, **VPC peering**, or **Transit Gateway** is the better
+  fit
+- Which environments need private connectivity, such as production only or both
+  production and non-production
+- CIDR planning for peered or attached VPCs
+- Which team owns the AWS networking changes
+- Whether the connection should be provisioned through Terraform
+
+## Recommendation
+
+In most AWS environments:
+
+- Use **PrivateLink** when the backend can be published as a private service
+- Use **VPC peering** for simpler one-to-one private network connectivity
+- Use **Transit Gateway** when Zuplo needs to connect into a larger multi-VPC
+  AWS network
+
+If you are evaluating Zuplo for a private AWS workload, those are the three
+patterns to expect.
+
+## Next steps
+
+- 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-private-networking.mdx

@@ -0,0 +1,166 @@
+---
+title: "Managed Dedicated: Azure Private Networking"
+sidebar_label: Azure Private Networking
+---
+
+Zuplo Managed Dedicated can run on Azure and connect privately to backends that
+aren't exposed to the public internet. This includes Azure Container Apps, Azure
+App Service, AKS, and internal services that are only reachable inside your
+Azure network.
+
+This page focuses on customer-facing requirements and the common Azure patterns
+used to connect Zuplo to private backends.
+
+## When to use this
+
+Azure private networking is a good fit when you need to:
+
+- Keep your backend off the public internet while still using Zuplo as the
+  public API entry point
+- Connect Zuplo to Azure Container Apps or App Service using private access
+- Reach services that are only available inside your Azure Virtual Network
+  (VNet)
+- Meet internal security or compliance requirements around network isolation
+
+## Azure connectivity options
+
+Azure uses **VNet peering**, not VPC peering.
+
+The two most common patterns are:
+
+### 1. Private Endpoint
+
+This is usually the preferred option when your backend supports Azure Private
+Link.
+
+Typical use cases:
+
+- Azure Container Apps
+- Azure App Service
+- Azure SQL
+- Azure Storage
+- Azure Key Vault
+
+Why teams choose this pattern:
+
+- Access is scoped to a specific service instead of an entire network
+- It is easier to review from a security perspective
+- It avoids broader Layer 3 connectivity between VNets when you only need
+  private access to a specific service
+- Your wider VNet does not need to be exposed to Zuplo
+
+### 2. VNet peering
+
+This is the right option when your backend is only reachable on private IP
+addresses inside your VNet, or when Zuplo needs access to multiple internal
+services.
+
+Typical use cases:
+
+- Internal load balancers
+- Private AKS services
+- Self-managed applications reachable only inside a VNet
+- Hub-and-spoke Azure network designs
+
+Why teams choose this pattern:
+
+- Zuplo can reach internal services that are not exposed through Private Link
+- It works well for broader private connectivity needs
+- It fits existing enterprise Azure network topologies
+
+## Azure Container Apps
+
+Yes, Zuplo can connect to Azure Container Apps that are restricted to private
+networking.
+
+The pattern depends on how your environment is configured:
+
+- If your **Container Apps environment** uses **Private Endpoint**, Zuplo
+  connects through Private Link and private DNS
+- If your Container Apps environment is internal and your app is reachable only
+  on private IPs inside your VNet, Zuplo connects through **VNet peering**
+
+Important details for Container Apps:
+
+- The private endpoint is created on the **managed environment**, not on an
+  individual container app
+- If you use an internal Container Apps environment, DNS must resolve the
+  environment's private address correctly
+- If you use app ingress set to **Internal**, that traffic is limited to the
+  same Container Apps environment. For private access from outside that
+  environment, use VNet-reachable ingress with the correct DNS setup
+
+This lets you keep Azure Container Apps private while still presenting a public
+API through Zuplo.
+
+## What is required from your side
+
+The exact setup depends on your Azure design, but most projects need:
+
+- The Azure region or regions where Zuplo should run
+- The target service details, such as the VNet, resource ID, or Private
+  Endpoint-enabled service
+- A DNS plan for private name resolution
+- Network approval for peering or Private Endpoint connections
+- Non-overlapping CIDR ranges if VNet peering is used
+
+If your team manages Azure through Terraform, Zuplo can work within that model.
+The ownership split depends on your environment and security model.
+
+## DNS requirements
+
+Private connectivity on Azure depends on DNS as much as it depends on routing.
+
+For private connectivity to work, Zuplo needs to resolve your backend to the
+correct private address. That usually means one of the following:
+
+- Linking the relevant Azure Private DNS zone to every VNet that needs to
+  resolve the private service
+- Forwarding DNS through your existing Azure DNS architecture
+- Using your shared DNS resolver strategy
+
+Common examples include:
+
+- `privatelink.azurewebsites.net` for Azure App Service private endpoints
+- `privatelink.{region}.azurecontainerapps.io` for Azure Container Apps private
+  endpoints
+- The Container Apps environment's own private DNS zone when you use an internal
+  environment
+
+Without the correct DNS configuration, the network path can exist while traffic
+still resolves to the public endpoint.
+
+## Planning considerations
+
+Before implementation, align on:
+
+- Whether **Private Endpoint** or **VNet peering** is the better fit
+- Which environments need private connectivity, such as production only or both
+  production and non-production
+- CIDR planning for any peered VNets
+- Which team owns the Azure networking changes
+- Whether the connection should be provisioned through Terraform
+
+## Recommendation
+
+In most Azure environments:
+
+- Use **Private Endpoint** when the backend supports it, especially for Azure
+  PaaS services where you only need private access to a specific service
+- Use **VNet peering** when the backend is only reachable on private IPs inside
+  your VNet or when Zuplo needs broader private connectivity into your Azure
+  network
+
+In practice, Private Endpoint is usually the cleaner fit for Azure Container
+Apps and App Service. VNet peering is usually the better fit for internal load
+balancers, private AKS services, or broader VNet-to-VNet connectivity.
+
+If you are evaluating Zuplo for a private Azure workload, those are the two
+patterns to expect.
+
+## Next steps
+
+- 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/gcp-private-networking.mdx

@@ -0,0 +1,124 @@
+---
+title: "Managed Dedicated: GCP Private Networking"
+sidebar_label: GCP Private Networking
+---
+
+Zuplo Managed Dedicated can run on Google Cloud and connect privately to
+backends that aren't exposed to the public internet. This includes services
+running inside your VPC, internal load balancers, GKE workloads, and services
+published through Private Service Connect.
+
+This page focuses on customer-facing requirements and the common GCP patterns
+used to connect Zuplo to private backends.
+
+## When to use this
+
+GCP private networking is a good fit when you need to:
+
+- Keep your backend off the public internet while still using Zuplo as the
+  public API entry point
+- Connect Zuplo to services running privately inside your Google Cloud network
+- Reach internal services over private IPs instead of public endpoints
+- Meet internal security or compliance requirements around network isolation
+
+## GCP connectivity options
+
+The two most common GCP patterns are:
+
+### 1. Private Service Connect
+
+This is usually the preferred option when your backend can be exposed through
+Private Service Connect.
+
+Typical use cases:
+
+- Services published privately through Private Service Connect
+- Single-service connectivity where you want service-level access instead of
+  broader VPC access
+- Architectures where you want to reduce network coupling between Zuplo and the
+  rest of your environment
+
+Why teams choose this pattern:
+
+- Access is scoped to a specific service instead of an entire VPC
+- It provides a clean service-oriented model for private access
+- It reduces the network coordination needed compared with broader peering
+  patterns
+
+### 2. VPC Network Peering
+
+This is the right option when Zuplo needs private network access into a
+customer-managed VPC and the backend is reachable by private IP.
+
+Typical use cases:
+
+- Internal load balancers
+- Private GKE services
+- Self-managed applications reachable only inside a VPC
+
+Why teams choose this pattern:
+
+- It is a simple fit for one-to-one VPC connectivity
+- Zuplo can reach internal services that are not exposed through Private Service
+  Connect
+- It works well when the backend lives in a small number of VPCs
+
+## What is required from your side
+
+The exact setup depends on your GCP design, but most projects need:
+
+- The Google Cloud region or regions where Zuplo should run
+- The target service details, such as project IDs, VPC names, internal load
+  balancers, or Private Service Connect service attachments
+- A DNS plan for private name resolution
+- Firewall rule approval
+- Non-overlapping IP ranges if VPC Network Peering is used
+
+If your team manages GCP through Terraform, Zuplo can work within that model.
+The ownership split depends on your environment and security model.
+
+## DNS requirements
+
+Private connectivity on Google Cloud depends on DNS as much as it depends on
+routing.
+
+For private connectivity to work, Zuplo needs to resolve your backend to the
+correct private address or endpoint. That usually means one of the following:
+
+- Using your existing Cloud DNS private zone design
+- Authorizing the relevant private zones across the connected networks
+- Using your shared DNS resolver strategy
+
+Without the correct DNS configuration, the network path can exist while traffic
+still resolves to the public endpoint.
+
+## Planning considerations
+
+Before implementation, align on:
+
+- Whether **Private Service Connect** or **VPC Network Peering** is the better
+  fit
+- Which environments need private connectivity, such as production only or both
+  production and non-production
+- IP range planning for peered VPCs
+- Which team owns the GCP networking changes
+- Whether the connection should be provisioned through Terraform
+
+## Recommendation
+
+In most Google Cloud environments:
+
+- Use **Private Service Connect** when the backend can be exposed as a private
+  service
+- Use **VPC Network Peering** when the backend is only reachable on private IPs
+  inside your VPC
+
+If you are evaluating Zuplo for a private GCP workload, those are the two
+patterns to expect.
+
+## Next steps
+
+- 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

@@ -10,55 +10,66 @@ requirements.
 Common configurations include:
 
 - Using Zuplo as the public ingress to your API and using network connectivity
-  such as AWS Transit Gateway, PrivateLink, or VPC Peering to connect to your
-  backend services.
+  such as PrivateLink, Private Service Connect, VNet or VPC peering, or
+  provider-native network hubs to connect to your backend services.
 - Restricting access to the public internet by configuring your API Gateway to
-  only accept traffic from specific IP ranges or VPCs allowing you to put WAFs,
-  IDS/IPS, or other security appliances in front of your API Gateway.
+  only accept traffic from specific IP ranges or private networks, allowing you
+  to put WAFs, IDS/IPS, or other security appliances in front of your API
+  Gateway.
 - Multiple dedicated managed instances of Zuplo can be deployed across multiple
   regions to provide high availability and disaster recovery.
 
 To discuss your networking requirements, please contact your account manager.
 
-## Zuplo Ingress to Customer VPC
+## Cloud-specific guidance
+
+- For AWS private backend connectivity, see
+  [AWS Private Networking](./aws-private-networking.mdx)
+- For Azure private backend connectivity, see
+  [Azure Private Networking](./azure-private-networking.mdx)
+- For Google Cloud private backend connectivity, see
+  [GCP Private Networking](./gcp-private-networking.mdx)
+
+## Zuplo Ingress to Customer Private Network
 
 The default setup for dedicated managed Zuplo is to use your Zuplo API Gateway
 as the public ingress to your API. This is the simplest setup and allows Zuplo
 to manage things like SSL certificates on your behalf.
 
-In this setup your VPC isn't exposed to the public internet at all. Instead,
-your Zuplo API Gateway will use a network connection such as AWS Transit
-Gateway, PrivateLink, or VPC Peering to connect to your backend services.
+In this setup your private network isn't exposed to the public internet at all.
+Instead, your Zuplo API Gateway uses a private network connection to reach your
+backend services.
 
 <Diagram height="h-48">
   <DiagramNode id="client">Client</DiagramNode>
-  <DiagramGroup id="dedicated-vpc" label="Dedicated VPC">
+  <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
       Zuplo API Gateway
     </DiagramNode>
   </DiagramGroup>
-  <DiagramGroup id="customer-vpc" label="Customer VPC">
+  <DiagramGroup id="customer-vpc" label="Customer Private Network">
     <DiagramNode id="backend">Backend</DiagramNode>
   </DiagramGroup>
   <DiagramEdge from="client" to="gateway" />
   <DiagramEdge from="gateway" to="backend" />
 </Diagram>
 
-## Customer VPC Ingress to Zuplo API Gateway
+## Customer Private Network Ingress to Zuplo API Gateway
 
 If you have custom networking requirements, such as using a static IP address
 you already own, or if you want to run services such as WAFs, IDS/IPS, or other
 security products in front of your API Gateway, Zuplo can be configured to
-accept traffic from your VPC then route it to your backend. Your backend could
-be in the same VPC as your ingress or in another VPC.
+accept traffic from your private network and then route it to your backend. Your
+backend could be in the same network as your ingress or in another private
+network.
 
 <Diagram height="h-64">
   <DiagramNode id="client">Client</DiagramNode>
-  <DiagramGroup id="customer-vpc" label="Customer VPC">
+  <DiagramGroup id="customer-vpc" label="Customer Private Network">
     <DiagramNode id="waf">WAF</DiagramNode>
     <DiagramNode id="backend">Backend</DiagramNode>
   </DiagramGroup>
-  <DiagramGroup id="dedicated-vpc" label="Dedicated VPC">
+  <DiagramGroup id="dedicated-vpc" label="Dedicated Network">
     <DiagramNode id="gateway" variant="zuplo">
       Zuplo API Gateway
     </DiagramNode>

package/docs/dedicated/overview.mdx

@@ -48,12 +48,12 @@ features as you would with edge-based deployments.
 In addition to the standard features, managed dedicated hosting provides:
 
 - **Custom Networking Configurations** - Configure your API Gateway to only be
-  accessible from specific VPCs or IP ranges
-- **Private Networking Options** - Support for AWS PrivateLink, Azure Private
-  Link, and GCP Private Service Connect for both inbound and outbound
-  connections
-- **Isolated VPC Deployment** - Your gateway runs in a dedicated, isolated VPC
-  for maximum security and isolation
+  accessible from specific private networks or IP ranges
+- **Private Networking Options** - Support for provider-native private
+  connectivity patterns such as AWS PrivateLink, Azure Private Link, and GCP
+  Private Service Connect, depending on the traffic pattern and cloud provider
+- **Isolated Network Deployment** - Your gateway runs in a dedicated, isolated
+  network environment for maximum security and isolation
 - **Custom Ingress Options** - Use your own static IP addresses or security
   appliances (WAFs, IDS/IPS) in front of your API Gateway
 

package/package.json

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