The backbone your cloud is built on.
Production-grade, secure-by-default Azure infrastructure — as code you can ship, with the reasoning that makes it defensible.
Most tools give you one half: naked Terraform modules with no explanation, or a wall of best-practice prose with no code. Keel is both, on purpose — the thing you deploy (the Kit) and the reasoning that makes it yours (the Doctrine). It covers everyday cloud infrastructure and AI-workload infrastructure, and the secure defaults are the defaults — not an appendix you have to remember to turn on.
Keel is the framework the CAMPUX Cloud Engineering Bootcamp teaches, productized.
Everyone agrees on what a safe Azure estate looks like. Almost nobody has it written down as something you can run. The knowledge lives in people's heads, half-remembered from the last incident — spread across docs, a blog post, a GitHub gist, and a Slack thread from eight months ago. Most quickstarts optimise for a green checkmark, not a safe estate: public endpoints, over-broad roles, no budget, no logging. Fine for a demo, a liability in production. AI workloads add new failure modes on top — quota you did not plan for, cost that blows up overnight, model endpoints on the open internet.
Keel is the paved road: an opinionated implementation where every default is the secure one, and every default is explained.
| What it is | Where it lives | |
|---|---|---|
| The Kit | Opinionated, deployable IaC — Bicep and Terraform modules + reference architectures + guardrails. | bicep/, terraform/, policies/ |
| The Doctrine | The methodology behind every default — why it exists, what it protects against, the trade-off, how to change it safely. | doctrine/ |
Two reference builds, each shipped in both languages, each with its doctrine docs:
- Secure Azure landing zone — management-group hierarchy, least-privilege RBAC (no standing Owner), Azure Policy guardrails that deny by default, hub-and-spoke networking with no public exposure, tagging + budgets + alerts, Log Analytics wired in, CI/CD with OIDC (no long-lived secrets).
- AI-workload reference — Azure OpenAI / inference behind private endpoints, quota-aware capacity, cost controls sized for tokens, data kept inside the boundary by default.
v0 status. The landing zone is the flagship. It ships in both Bicep and Terraform, built to the same spec and run through the same tests. See the parity matrix below for exactly what is ready.
Keel is Bicep-first, Terraform fast-follow — but Terraform is never an afterthought. The heavy, language-neutral parts (policies/, reference-architectures/) are shared, so a Terraform port re-implements only the thin IaC wiring, and it runs through the same tests/policy and tests/security gates before it counts as done. Live status: doctrine/parity.md.
| Module | Spec | Policy | Bicep | Terraform |
|---|---|---|---|---|
| Landing zone | done | done | done | done |
| AI-workload | planned | planned | planned | tracked |
| Application | done | — | ext | ext |
Status words: done · building · draft · planned · tracked · ext (external repo) · — (not applicable).
The application's worked example is campux-retail —
a standalone workload that lands on the landing zone. See reference-architectures/application.
git clone https://github.com/kloudcaptain/keel && cd keel
# 1. one-time: create the OIDC app + federated credential (no long-lived secrets)
./scripts/bootstrap/bootstrap-oidc.sh
# 2. copy and edit a parameter file (the defaults are the safe ones)
cp examples/minimal/landing-zone.bicepparam my.bicepparam # Bicep
# or, for Terraform: cp examples/minimal/landing-zone.tfvars my.tfvars
# 3. deploy the landing zone (Bicep shown; Terraform is the mirror)
./scripts/deploy/deploy.sh landing-zone --params my.bicepparam
# Terraform: ./scripts/deploy/deploy.sh landing-zone --engine terraform --params my.tfvars
# 4. when you are done, leave nothing running and nothing billing
./scripts/teardown/teardown.sh landing-zoneRead the reasoning behind any default in doctrine/ — every module links to it.
doctrine/ # the "why" — methodology, one doc per concern
reference-architectures/ # language-neutral specs + diagrams + decision records
bicep/ # Bicep implementation (modules + reference builds)
terraform/ # Terraform implementation (parity target)
policies/ # Azure Policy defs/initiatives — shared by both stacks
examples/ # ready-to-edit parameter files (minimal / production / ai)
tests/ # guardrail tests — both stacks pass the same policy+security checks
scripts/ # bootstrap (OIDC) · deploy · teardown
.github/ # CI (plan-on-PR, apply-on-main) + issue templates
It is v0. The defaults are the ones we would put in production, but read the doctrine, run it in a non-critical subscription first, and treat it as a foundation you own and adapt — not a black box. Nothing here is gated; the core stays open and free. Where paid fits later (pro modules, support, a hosted option) it will be said out loud, not slipped in.
Pull requests welcome from day one — especially Terraform parity and doctrine edits. See CONTRIBUTING.md. By contributing you agree to the Code of Conduct. Found a weak default? That is a security bug — see SECURITY.md.
Keel productizes what the CAMPUX Cloud Engineering Bootcamp teaches. If a default here raises a question, these go deeper:
- What is Infrastructure as Code? — the model Keel is built on
- NSG vs Azure Firewall and Azure Firewall vs WAF — the network controls Keel wires by default
- Azure landing zones, explained — the estate shape Keel deploys
- Free security exam practice — drill the SC-500 concepts hands-on
MIT © CAMPUX LLC.
