# Private deployment topologies

> How to choose where models and the systems around them run: on-premises, private cloud, hybrid with a gateway, or air-gapped.

- Web page: https://www.alesanalytics.com/docs/private-deployment-topologies
- Markdown: https://www.alesanalytics.com/docs/private-deployment-topologies.md
- Last updated: 2026-11-08
- Publisher: Ales Analytics

Technical page. On-premises, private cloud, hybrid and air-gapped. Published 2026-11-08. Last reviewed 2026-11-08. Reviewed by Ales Analytics engineering.

## In one paragraph

A private deployment runs models and the systems around them inside an environment the client controls: their own building, their own cloud account, or a network with no outside connection at all. The topology is chosen from where the data may sit, what hardware already exists, how steady the load is, and who will operate it.

## How it works

| Topology              | Summary                                                   | Reference deployment                                                 |
| --------------------- | --------------------------------------------------------- | -------------------------------------------------------------------- |
| On-premises           | GPU servers in the client's building or colocation rack   | [Single on-premises GPU server](https://www.alesanalytics.com/docs/single-on-premises-gpu-server) |
| Private cloud tenancy | GPU capacity in the client's own cloud account and region | [Private cloud tenancy](https://www.alesanalytics.com/docs/private-cloud-tenancy)                 |
| Hybrid with a gateway | Self-hosted models plus approved routes to hosted models  | [Hybrid with a gateway](https://www.alesanalytics.com/docs/hybrid-with-a-gateway)                 |
| Air-gapped            | No outside connectivity; updates by signed transfer       | [Air-gapped deployment](https://www.alesanalytics.com/docs/air-gapped-deployment)                 |

Common to all: a model gateway in front of every model, identity from the client's own provider, private networking, egress allowed only to listed hosts, and a data-residency map covering primary stores, backups, logs, indexes and vendor support access.

![Figure 1. The hybrid topology: a gateway decides what may leave.](https://www.alesanalytics.com/diagrams/rd-hybrid.svg)

## Design choices and trade-offs

- **Own or rent.** Owning hardware pays when load is steady and high; renting suits variable or uncertain load. The decision is made from measured load, not assumed.
- **Kubernetes or plain servers.** Kubernetes helps with several models and autoscaling, using the vendor's GPU device plugin and Dynamic Resource Allocation; plain servers are easier for a small team to run.
- **Where weights come from.** Pulled from an internal registry, never directly from the internet at runtime.

## When not to use it

When the data is not sensitive, volumes are low, and a hosted service's terms are acceptable, a hosted API may be the simpler choice.

## How we evaluate it

Capacity tests at the expected concurrency on the target hardware, restore tests of backups, egress tests confirming nothing reaches unlisted hosts, and failure drills for the components named in each reference deployment.

## Sources

- [Kubernetes Dynamic Resource Allocation](https://kubernetes.io/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
- Explainers: [Private deployment](https://www.alesanalytics.com/explainers/private-deployment), [Owning or renting the hardware](https://www.alesanalytics.com/explainers/own-or-rent-infrastructure)

## Contact

solutions@alesanalytics.com, or https://www.alesanalytics.com/contact.

- Every page as Markdown: https://www.alesanalytics.com/llms.txt