Copy page

Networking & Infrastructure

Zuplo Self-Hosted

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 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

How It Works

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

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 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

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:

• 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.

The exact hostnames for your egress allow-list are provided during onboarding. If your environment can't allow this egress, book a meeting to review options with the Zuplo team.

Provided by Zuplo During Onboarding

• 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.

Observability

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 with the Zuplo team.