---
type: Axis
title: hosting (infrastructure-provider axis)
description: The hosting infra architecture axis — where the system's infrastructure lives and how many providers it spans (on-prem → single-cloud → multi-cloud → hybrid). An infra-altitude (altitude:infra), system-singleton axis whose commitment surface is the provider configuration-schema. Soft interaction with orchestration (k8s-cloud-affinity); orthogonal to host-binding (RFC #97 / RFC #75 5A).
tags: [axis, architecture, infra, hosting, cloud, on-prem, rfc-97, deep]
timestamp: 2026-06-26T00:00:00Z
---

# Hosting (infrastructure-provider axis)

> **DEEP infra axis (4.8.0a2 / #912).** The second of the three infra-altitude
> axes (`altitude: infra`). Full §6 depth + the project-type-classifier worked
> examples. Soft cross-axis interaction with `orchestration`; orthogonal to
> `host-binding` (where the services live ≠ how cloud-coupled they are).

## Concept

Hosting is the **infrastructure-provider** axis (RFC #97 §"Infra axes"): where the
system's infrastructure physically lives and how many distinct providers it spans.
The ladder runs `on-prem` (operator-owned hosts / bare metal) → `single-cloud`
(one cloud provider) → `multi-cloud` (≥2 cloud providers, provider-agnostic by
intent) → `hybrid` (on-prem AND cloud, bridged into one deployment). Its
**commitment surface is the provider configuration-schema** (§4) — the
Terraform/IaC + provider-account config that pins where things run; the
migration asymmetry lives there (account topology, networking, and IAM are
expensive to re-home once standing). Its **scope is system-singleton** (§5): a
project picks one hosting posture for the whole deployment.

The classifier gates engagement: a `script`/`desktop` project often sits at
`on-prem` (the operator's own machine) and never engages; a `web`/`distributed`
project picks a cloud posture.

## Why it is an axis (discriminator test — §2)

1. **Ordered tiers** — each rung widens where infrastructure may live (one site
   → one cloud → many clouds → bridged on-prem+cloud).
2. **Cross-cutting bundle** — a rung dictates the IaC provider set, networking
   (VPC/peering/VPN), identity (provider IAM), data residency, and the tests.
3. **Asymmetric migration cost** — standing up a second cloud (multi-cloud) or
   bridging on-prem to cloud (hybrid) is a one-way networking + identity +
   data-gravity commitment; collapsing back strands the cross-provider wiring.
4. **Requirement-keyed selection** — falsifiable probes (below) pick the rung.

## Schema view (the §6 entry — validated by `axis_catalog`)

```yaml
id: hosting
kind: architecture-axis
altitude: infra
scope: system-singleton
selection:
  probes:
    - "Does the infrastructure run on operator-owned hosts / bare metal only? → on-prem."
    - "Does it run on exactly one cloud provider? → single-cloud."
    - "Must it span two-or-more cloud providers (provider-agnostic by intent / avoid lock-in)? → multi-cloud."
    - "Must it bridge on-prem AND cloud into one deployment (data residency, burst-to-cloud)? → hybrid."
    - "Choosing a cloud tier here does NOT force cloud-specific components — that is the host-binding tier (orthogonal)."
composes_with:
  - "k8s-cloud-affinity = orchestration × hosting (SOFT — k8s does not require cloud)"
applies_when: []
tiers:
  - tier: on-prem
    commitment_delta:
      surface: configuration-schema
      delta: "infrastructure lives on operator-owned hosts / bare metal; no cloud provider account in the deploy config."
    admin_tool: "host inventory + on-prem provisioning (the operator's own machines)."
    enforcement:
      - "no cloud-provider credential or managed-service dependency in the deploy contract."
    tests:
      - "the deploy stands up on operator-owned hosts with no external provider."
    forecloses: "elastic capacity + provider-managed services; capacity is the hardware on hand."
    migration_cost_to_next: "medium — pick a cloud provider: account, networking (VPC), IAM, IaC."
  - tier: single-cloud
    commitment_delta:
      surface: configuration-schema
      delta: "one cloud provider; the IaC + account topology (VPC, IAM, regions) are that provider's."
    admin_tool: "the provider's console + one IaC provider (e.g. a single Terraform provider block)."
    enforcement:
      - "the deploy config pins one provider; networking + identity are that provider's primitives."
    tests:
      - "the IaC applies cleanly on the one provider; teardown is clean."
    forecloses: "provider-failure independence; the whole deploy shares one provider's blast radius."
    migration_cost_to_next: "high — stand up a second provider: cross-cloud networking, dual IAM, provider-agnostic IaC."
  - tier: multi-cloud
    commitment_delta:
      surface: configuration-schema
      delta: "two-or-more cloud providers, provider-agnostic by intent; IaC + networking + identity span providers."
    admin_tool: "multi-provider IaC + cross-cloud networking (peering/transit) + a unifying identity layer."
    enforcement:
      - "no single-provider-only primitive on the critical path; each provider's deploy is reproducible independently."
    tests:
      - "the deploy applies on each provider; a single provider's outage leaves the system serving."
    forecloses: "leaning on any one provider's bespoke managed service for the critical path."
    migration_cost_to_next: "high — bridge on-prem into the mix: VPN/direct-connect + data-residency split."
  - tier: hybrid
    commitment_delta:
      surface: configuration-schema
      delta: "on-prem AND cloud bridged into one deployment; workloads + data are placed by residency / latency / cost."
    admin_tool: "the cloud↔on-prem bridge (VPN/direct-connect) + a placement/residency policy."
    enforcement:
      - "every cross-boundary path tolerates the bridge being down; data residency is enforced by placement."
    tests:
      - "a bridge outage degrades gracefully; residency-pinned data never leaves its boundary."
    forecloses: "treating on-prem and cloud as one homogeneous fabric; placement is now load-bearing."
    migration_cost_to_next: "n/a — top of the ladder (the most-spanning posture)."
examples:
  - "A `web` project starts single-cloud (one provider's managed DB + object store). It climbs to multi-cloud only when a real requirement forces provider independence (lock-in avoidance, a customer's second-provider mandate), and to hybrid when data residency forces some data to stay on-prem. The skill's own deployment sits at on-prem by design (the per-project daemon runs on the operator's machine; PyPI is a publish target, not hosting): the cloud climb is unjustified, and even were it cloud-hosted, that would not by itself force cloud-specific components (host-binding stays cross-host)."
```

## Selection procedure (§8)

Bidirectional check gated by the classifier: de-escalate (YAGNI — "does anything
actually require a second provider / on-prem residency?") and escalate ("does a
residency, lock-in, or availability requirement force a wider rung?"). Recorded in
the `DeploymentRecord` tier vector; the drift phase flags actual provider config
(a second Terraform provider block under a declared `single-cloud` tier) that
diverges from the record.

## Composition (§5)

Hosting × orchestration yields the **soft** `k8s-cloud-affinity` product:
Kubernetes is *often* run on a cloud-managed control plane, but the rule is
advisory — bare-metal/on-prem k8s exists, so hosting is never *required* by an
orchestration tier (authored in `interactions.yaml`). Hosting is also kept
distinct from **host-binding**: *where* infrastructure lives (this axis) is not
*how cloud-coupled the services are* (that axis).
