# Where Zuplo Runs > **Scope of this page** > > This page documents the Zuplo **gateway** runtime (API, AI, and MCP gateways), not the Developer Portal. > > It applies to every Zuplo hosting option: Managed Edge, Managed Dedicated, and Self-Hosted. See [Hosting options](https://zuplo.com/docs/articles/hosting-options). Zuplo runs the same gateway in three places: at the edge, on a dedicated instance in the cloud you choose, or on your own infrastructure. Wherever the gateway runs, it can route to backends on AWS, Google Cloud, Azure, other providers, or your own data center. This page explains the hosting options and how Zuplo fits into a single-cloud, multi-cloud, or hybrid environment. ## Hosting options | Option | Where the gateway runs | Choose it when you want | | ---------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | [Managed Edge](../managed-edge/overview.md) | Serverless, across 300+ data centers worldwide | Global low latency and automatic scaling with no infrastructure to manage | | [Managed Dedicated](../dedicated/overview.mdx) | An isolated instance that Zuplo operates on the cloud provider and regions you choose | A specific cloud or region, private networking, or dedicated compliance requirements | | [Self-Hosted](../self-hosted/overview.md) | Your Kubernetes cluster, in any cloud or private data center, installed with a Helm chart | Full control of the infrastructure that serves your API traffic | Managed Edge is the default for every Zuplo project. For a closer look at each option, see [Hosting Options](../articles/hosting-options.mdx). ### Managed Edge Your gateway runs in hundreds of data centers worldwide, close to your clients. Each request reaches the nearest location, runs through your policies, and goes straight to your backend, wherever that backend runs. If one location has an issue, traffic routes to the next nearest location automatically. ### Managed Dedicated Zuplo runs a dedicated, isolated instance of the gateway for you on the cloud provider of your choice: - [Akamai Connected Cloud](../dedicated/akamai/architecture.mdx) - [AWS](../dedicated/aws/architecture.mdx) - [Azure](../dedicated/azure/architecture.mdx) - [Google Cloud](../dedicated/gcp/architecture.mdx) - Equinix, TerraSwitch, and other providers on request You pick the regions, so you can keep traffic in a specific country or next to your backends. You can also deploy instances in multiple regions for high availability and disaster recovery. ### Self-Hosted You install Zuplo on your own Kubernetes cluster with a single Helm chart. The cluster can run in any cloud or in a private data center. API traffic to your gateways stays on your infrastructure, while Zuplo provides the portal and a small set of supporting services. ## One project, any hosting option All three hosting options use the same runtime, project format, policies, and deployment workflow. Your routes, policies, custom code, and environment variables live in your Git repository, not in a cloud-specific configuration. This gives you two advantages: - **No cloud lock-in.** Zuplo isn't tied to one cloud provider's gateway, so your API layer stays the same when your backends change clouds. - **Room to grow.** A team can start on Managed Edge and move to Managed Dedicated or Self-Hosted later, for example when a compliance requirement appears, without rewriting the gateway. ## Connecting to backends on any cloud The gateway location and the backend location are independent. A single Zuplo project can send one route to AWS Lambda, another to Google Cloud Run, and another to a service in your own data center, while clients see one API with one set of authentication, rate limits, and analytics. Clients Zuplo Gateway AWS Google Cloud Azure On-premises data center Pick the connection method that matches where each backend runs: | Backend | How Zuplo connects | | ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------- | | Behind AWS, Azure, or Google Cloud IAM | [IAM authentication](../articles/upstream-iam-auth.mdx) policies sign each request with credentials your cloud provider trusts | | Any backend that can check a certificate | [mTLS](../articles/securing-backend-mtls.mdx), so the gateway and backend authenticate each other | | No public endpoint, bare metal, or on premises | A [secure tunnel](../articles/secure-tunnel.mdx) that opens an outbound connection from your network, with no inbound firewall rules | | In a private VPC or VNet, with Managed Dedicated | [Private networking](../dedicated/networking.mdx) such as AWS PrivateLink, Azure Private Link, or Google Cloud Private Service Connect | | Any backend that can check a header | A [shared secret](../articles/securing-your-backend.mdx#shared-secret-or-api-key) that the gateway adds to each request | IAM authentication, mTLS, and secure tunnels are available on enterprise plans. Because each route sets its own backend URL, you can move a service from one cloud to another, or from your data center to the cloud, by changing that URL. Clients keep calling the same API. ## Related resources - [How Zuplo Works](./how-zuplo-works.mdx) - [Hosting Options](../articles/hosting-options.mdx) - [Securing your backend](../articles/securing-your-backend.mdx) - [Managed Dedicated architecture](../dedicated/architecture.mdx)