Deployment Models

You should not have to choose between shipping quickly and keeping your traffic where it belongs. Apiway runs as a service you never operate, as a gateway inside your own cluster with the platform still managed for you, or entirely on your own infrastructure.

The choice is not only about where things run. It changes which capabilities you get. Read this page before you design against Apiway, because one difference below has architectural consequences.

The Three Models

	PaaS	Hybrid	Self-hosted
Control plane operated by	Apiway	Apiway	You
Gateway runs in	Apiway’s infrastructure	Your cluster	Your infrastructure
Micro-gateway in your cluster	No	Yes	Yes
East-west (service-to-service) enforcement	No	Yes	Yes
North-south (inbound) enforcement	Yes	Yes	Yes
Request payloads stay inside your network	No	Yes	Yes
Infrastructure for you to run	None	The gateway	All of it
Typical reason to choose it	Fastest start, nothing to operate	Internal calls must be governed, without running the platform	Data residency, regulated or air-gapped environments

The line that matters

On PaaS the gateway runs in our cluster, so it cannot govern calls between your services. It acts as a micro-gateway for our stack, not yours. Your inbound traffic is fully enforced; your service-to-service calls never reach the gateway at all, because your services are in your cluster and it is not.

If your design depends on internal calls being subject to the same identity, scopes, metering and audit as external ones, the model is Hybrid or Self-hosted. This is a capability difference, not a hosting preference, and it is the one that most often changes an architecture.

The Micro-Gateway

Alpha Gateway is a micro-gateway: it is designed to run inside the cluster that runs your services, rather than in front of it as a shared appliance. That placement gives it two jobs.

• North-south — traffic arriving from outside, routed by DNS to your public API surface.
• East-west — service-to-service calls inside the cluster, addressed through Kubernetes service aliases.

The second is the one a conventional edge gateway cannot do. Internal calls between your own services normally bypass the gateway entirely, which means the identity, scope enforcement, metering and audit trail that apply to external consumers do not apply internally — so the calls with the most access are the least observed.

East-west enforcement arrives with the micro-gateway at no extra configuration. You do not declare internal routes, register services with each other, or maintain a second policy set for traffic that never leaves the cluster. It is the same contract, the same scopes and the same audit trail, applied because the gateway sits inside the cluster rather than in front of it.

How configuration reaches it

The gateway holds no truth of its own. Core-service is the only component that deploys, and it writes the proxy surface — routes, policies, security, rate limits — to the gateway. The gateway serves traffic against what it has been given, which is why the same deployment model can target Alpha, Kong, Azure APIM, Apigee, Tyk or Zuplo without the governance changing. See Multi-Gateway.

Hybrid

The gateway runs in your cluster; the control plane remains ours to operate. You get the micro-gateway and east-west enforcement, and no request payload leaves your network — without taking on the platform itself.

Self-hosted

The complete platform, containerised, on your own infrastructure. Control plane, gateway and the data layer beneath them all inside your perimeter, for environments where residency is a legal requirement rather than a preference.

Note

Self-hosting changes where the software runs, not what it does. Governance, identity, metering and the delivery flow behave identically.

Choosing

Start on PaaS if you are evaluating: it is the fastest route from a specification to a live, governed API, and the model is a property of an environment rather than of your account — so development can stay on PaaS while production runs Hybrid or Self-hosted.

Choose Hybrid or Self-hosted from the outset if internal service-to-service traffic has to be governed, or if payloads may not leave your network. Those are design constraints, not preferences, and retrofitting them costs more than starting there.

See also: Environments · Multi-Gateway · Identity Providers · API Topology