Landing Zone for OVHcloud

An open-source landing zone for OVHcloud Public Cloud, written in OpenTofu. It sets up the shared base that teams deploy onto (state storage, identity, projects, networks, and a runtime placeholder), and checks each piece with tests that run offline before anything touches an account.

Important

Not an OVHcloud product. This is an independent project by PlatformRelay. OVHcloud does not provide, endorse or support it. "OVHcloud" is a trademark of its owner and is used here only to name the target platform. See ADR-0001.

Who it is for

• For platform engineers who want to read, run or compare a tested landing-zone baseline for OVHcloud, and for contributors.
• Not for production use today, nor for anyone who needs vendor support, a finished product, or features listed below as not delivered.

Status

Pre-release. No version has been published.

• Delivered: the first slice (spec 005): the modules, components, stages and generated stacks listed in the repository map, with naming and labels. Its offline checks pass. Its live apply-and-destroy chain passed once in the maintainer's sandbox account (run 20261013T075309Z-443f, evidence).
• Open: bootstrapping a fresh account (task T045) has not run yet. Tenant state isolation is not demonstrated: the sandbox shares one project between tenants and state (see the exit record).
• Not delivered: golden-path profiles, tenant self-service merge requests, per-run deployment credentials, generated installation docs and the guided setup are plans, described in the product direction.

Try it offline (about 5 minutes, no credentials)

Every check runs inside lz-offline, a sandboxed entry with the pinned toolchain (OpenTofu, Terramate, Go, TFLint) and no network. You need Linux on x86-64 with curl, sha256sum, tar, sed and grep. From the root of your clone:

E=$(tools/scripts/fetch-offline-entry.sh)        # fetch, verify and install the entry
"$E" --candidate "$PWD" -- task test:slice         # lint + unit tests of every module, component, stage (~80 s)

The script pulls the entry anonymously from GitHub's container registry, checks every download against the digests pinned in .github/workflows/foundation.yml, and installs it outside your clone (the entry refuses to run from inside it), under ~/.local/share/landingzone-for-ovhcloud/runtime/ unless you pass --dest DIR. Any mismatch stops it with nothing installed. Running it again reuses a verified install.

Prerequisite: the pinned bwrap. The entry sandboxes every check with /usr/bin/bwrap, and only the build shipped with it is accepted. If yours is missing or different, the script prints the one sudo install … command that puts the verified build in place, and exits; it never runs sudo itself; run that command, then the script again. That replaces your distribution's bwrap: prefer a VM or a spare machine. Where AppArmor restricts unprivileged user namespaces (recent Ubuntu), CI also runs sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0; you may need it too.

Other checks run the same way:

"$E" --candidate "$PWD" -- task check -- modules/naming  # after a change: that path and its consumers
"$E" --candidate "$PWD" -- task stacks:check       # generated stacks match stacks/deployments.yaml
"$E" --candidate "$PWD" -- task test:stack-plans   # every stack plans against mocks
"$E" --candidate "$PWD" -- task stacks:order -- all  # the order the stacks would be applied in

A green run ends with SLICE_PASS (test:slice), CHECK_PASS (check), STACKS_CHECK_OK (stacks:check) or pass; stacks:order prints the order. task check runs lint and the unit tests on the changed path and every module, component and stage that uses it, then the dependency and docs checks, and says which test layers ran. task test runs every offline test target in a row; that takes longer than the 240 s the entry gives one target, so through the entry run its targets one at a time. With Task installed, task --list shows every target; CI runs the ones in the LZ_TARGETS lists of the same workflow's jobs. Applying to a real account (task bootstrap:*, task live:*) is maintainer-only today; see the runbook.

Map of the repository

The short version; the repository map has every entry and its subdirectories, and the architecture overview shows how the layers fit together.

The landing zone (what gets deployed)

Path	What it holds
modules/	Layer 1: small building blocks over OVHcloud resources (IAM, storage, network), plus naming.
components/	Layer 2: building blocks composed from modules (state backend, identity, network, runtime).
stages/	Layer 3: one reusable module per deployment step, without state or credentials: bootstrap, tenant state, account governance, project, network, runtime.
stacks/	Deployable instances of the stages, each with its own state, generated from stacks/deployments.yaml.
schemas/	JSON schemas for the deployment manifest, stage outputs and check reports.

How it is verified

Path	What it holds
tools/	Go command-line tools: lz-check (checks), lz-offline (sandboxed entry), lz-stacks (stack generation), lz-live (live runs), lz-pack (runtime packing).
tools/harness/	The check registry (checks.yaml) and what the offline entry may do (capabilities.yaml).
tests/	Check fixtures, captured tool output and the live probe roots.
pipelines/	The CI source the GitHub workflow is rendered from, and recorded CI runs.
Taskfile.yml, mise.toml	Every check as task <target>; the pinned tool versions.

Why it is the way it is, and the delivery record

Path	What it holds
docs/	Architecture decision records (ADRs), how-tos, explanations, references and known issues.
specs/	The delivery record: one folder per feature with its spec, plan, tasks and evidence. You do not need it to use the landing zone.
AGENTS.md, .github/CONTRIBUTING.md	Working rules for contributors, human or automated; how to contribute.

Where to go next

• Documentation index — every page, sorted by what you need from it.
• Glossary — the project's terms and ids (stage, stack, KD-1, T049 …).
• Architecture decisions — start with ADR-0001, 0002, 0004, 0008 and 0009.
• Run the first slice — the maintainer's runbook for a real account.
• Specs and delivery status — what each spec covers and where it stands.
• Known issues — verified findings and accepted limitations.

Licence

Code, policies and schemas: Apache-2.0. Documentation under docs/: CC BY 4.0. Quoted OVHcloud documentation keeps its own terms; see NOTICE.