---
type: Axis
title: host-binding (cloud-coupling axis)
description: The host-binding infra architecture axis — how tightly the app's services are coupled to host-specific (cloud) APIs vs portable CNCF interfaces (host-bound → mixed → cross-host). An infra-altitude (altitude:infra), system-singleton axis whose commitment surface is the interface/wire contract the services bind to. ORTHOGONAL to orchestration — k8s-on-cloud is still a host-binding choice (RFC #97 / RFC #75 5A).
tags: [axis, architecture, infra, host-binding, cncf, portability, rfc-97, deep]
timestamp: 2026-06-26T00:00:00Z
---

# Host-binding (cloud-coupling axis)

> **DEEP infra axis (4.8.0a2 / #912).** The third of the three infra-altitude
> axes (`altitude: infra`). It carries the **orthogonality contract** the whole
> infra altitude turns on: a project's *orchestration* tier (even `kubernetes`)
> says nothing about how cloud-coupled its services are — that is THIS axis, and
> it is chosen independently. The render phase reads this tier (not orchestration)
> to decide whether to recommend portable CNCF components or cloud services.

## Concept

Host-binding is the **cloud-coupling** axis (RFC #97 §"Infra axes"): how tightly
the application's services bind to **host-specific (cloud-provider) APIs** versus
**portable, host-neutral interfaces** (the CNCF / open-standard components). The
ladder runs `host-bound` (services use cloud-specific managed APIs directly — AWS
Cognito, DynamoDB, SQS) → `mixed` (some cloud-specific, some portable; an explicit
per-service decision) → `cross-host` (every service binds a portable interface;
the deployment is provider-agnostic and re-homeable). Its **commitment surface is
the interface/wire contract** (§4): the moment a service binds a cloud-specific
API it commits to that wire contract, and the migration asymmetry is the cost of
re-coding every call site against a different interface. Its **scope is
system-singleton** (§5): a project picks a default host-binding posture (a single
service can deviate, recorded on its `ConfigValue`/sidecar).

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

1. **Ordered tiers** — each rung loosens cloud coupling (provider APIs → a mix →
   fully portable interfaces).
2. **Cross-cutting bundle** — a rung dictates the component set (Cognito vs Dex,
   DynamoDB vs a portable store), the SDK dependencies, the abstraction seams, and
   the tests (mock the provider SDK vs the portable interface).
3. **Asymmetric migration cost** — un-binding from a cloud-specific API
   (`host-bound` → `cross-host`) means re-coding every call site against a
   portable interface AND migrating the managed data out; binding *to* one is a
   cheap SDK call. The cost is asymmetric and one-way-expensive.
4. **Requirement-keyed selection** — falsifiable probes (below) pick the rung.

## Orthogonality (the contract this axis carries)

**orchestration ⊥ host-binding — the load-bearing note.** A `kubernetes`
deployment running on a cloud (EKS/GKE/AKS) is STILL a host-binding choice: that
k8s cluster may bind AWS Cognito for auth (`host-bound`/`mixed`) OR run wholly
portable CNCF components (`cross-host`). **Cloud-host-specific component use is
NEVER assumed from the orchestration or hosting tier — it is exactly a
host-binding tier choice.** Consequently the render phase's component
recommendation is conditioned on THIS axis: `cross-host` → recommend portable
**CNCF** components (from `<docs>/cncf/catalog.yaml`); `host-bound` → cloud-specific
managed services are allowed. The probes below make the orthogonality falsifiable
(the "k8s-on-cloud" probe deliberately routes to a host-binding question, not an
assumption).

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

```yaml
id: host-binding
kind: architecture-axis
altitude: infra
scope: system-singleton
selection:
  probes:
    - "Do services call cloud-specific managed APIs directly (Cognito, DynamoDB, SQS)? → host-bound."
    - "Is it a deliberate mix — some cloud-specific, some portable, decided per service? → mixed."
    - "Does every service bind a portable, host-neutral interface (the deployment is re-homeable)? → cross-host."
    - "Is the project on k8s/EKS? That does NOT set this tier — ask separately whether its services bind cloud APIs (orthogonality)."
    - "Must the deployment be portable across providers / runnable on-prem unchanged? → cross-host (forces portable/CNCF components)."
composes_with:
  - "(render) cross-host tier → recommend portable CNCF components; host-bound → cloud services allowed"
applies_when: []
tiers:
  - tier: host-bound
    commitment_delta:
      surface: interface-wire-contract
      delta: "services bind cloud-provider-specific managed APIs directly; the wire contract is the provider's SDK/API surface."
    admin_tool: "the cloud provider's console + SDK for each bound service."
    enforcement:
      - "each cloud-specific binding is recorded; the service's contract is that provider's API, not a portable one."
    tests:
      - "the provider SDK calls are exercised (mocked at the provider boundary); no portability claim is tested."
    forecloses: "re-homing to another provider / on-prem without re-coding every bound call site."
    migration_cost_to_next: "medium — introduce a portability seam for the services you want to un-bind (a mix)."
  - tier: mixed
    commitment_delta:
      surface: interface-wire-contract
      delta: "a deliberate per-service split: some services bind cloud-specific APIs, others a portable interface. Each binding is an explicit, recorded decision."
    admin_tool: "a per-service binding registry (which services are portable vs provider-bound)."
    enforcement:
      - "every service declares its binding (portable | provider-bound); a new cloud-specific binding is a recorded tier decision, not a default."
    tests:
      - "the portable services run against the portable interface; the bound services mock the provider boundary."
    forecloses: "claiming whole-deployment portability while provider-bound services remain on the critical path."
    migration_cost_to_next: "high — un-bind the remaining provider-specific services onto portable interfaces + migrate their managed data."
  - tier: cross-host
    commitment_delta:
      surface: interface-wire-contract
      delta: "every service binds a portable, host-neutral interface (CNCF / open standard); the deployment is provider-agnostic and re-homeable."
    admin_tool: "the portable component set (CNCF catalog) + a conformance check that no provider-specific API leaks in."
    enforcement:
      - "no service binds a cloud-specific managed API on the critical path; portability is a tested property."
      - "render recommends portable CNCF components for new services at this tier."
    tests:
      - "the deployment runs unchanged on a second provider / on-prem; a leaked provider-specific call fails the conformance test."
    forecloses: "leaning on any one provider's bespoke managed service (the cost re-enters as re-binding)."
    migration_cost_to_next: "n/a — top of the ladder (maximally portable)."
examples:
  - "A `host-bound` web app on AWS uses Cognito (auth) + DynamoDB (store) + SQS (queue) directly — fast to build, hard to leave. A `cross-host` distributed system on the SAME EKS cluster instead runs Dex/Keycloak (auth), a portable store, and a CNCF queue, so it re-homes to GKE or on-prem unchanged. The two differ ONLY on host-binding, not orchestration — both are kubernetes. The skill's own deployment is cross-host by design (a per-project daemon + local docs store + multi-backend forge adapters behind a Protocol — no cloud-specific API on any path), which is why it publishes to PyPI and runs identically on any operator's machine."
```

## Selection procedure (§8)

Bidirectional check, run INDEPENDENTLY of the orchestration/hosting tiers (the
orthogonality discipline): de-escalate ("does anything actually require a
provider-specific managed service, or can it be portable?") and escalate ("does a
portability / on-prem / multi-provider requirement force `cross-host`?"). Recorded
as the project's default host-binding tier in the `DeploymentRecord`; a single
service may deviate, recorded on its own `ConfigValue`/sidecar. The drift phase
flags a service binding a cloud-specific API under a declared `cross-host` tier (a
portability leak).

## Composition (§5)

Host-binding drives the **render-phase component recommendation** (not a derived
`interactions.yaml` product but a direct conditioning): `cross-host` →
portable CNCF components from `<docs>/cncf/catalog.yaml`; `host-bound` →
cloud-specific managed services allowed. The orthogonality to orchestration is the
reason the recommendation reads THIS axis and never infers cloud-coupling from the
deployment topology.
