Keel
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.
Free · MIT-licensed core · Bicep and Terraform
Secure infra is scattered tribal knowledge
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.
Best practices in 40 tabs
The right answer exists — spread across docs, blog posts, a GitHub gist, and a Slack thread from eight months ago. You reassemble it by hand, every project.
Starters are insecure by default
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 adds new failure modes
Quota you did not plan for, cost that blows up overnight, model endpoints exposed to the open internet, data leaving where it should not. The old checklist does not cover any of it.
You cannot defend what you copied
Lifting a module you do not understand gets you a running deployment and nothing to say when someone asks why it is built that way.
The Kit and the Doctrine
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, and the reasoning that makes it yours.
The Kit
Opinionated, deployable Infrastructure-as-Code. The paved road, not a pile of parts.
- Bicep and Terraform modules, side by side
- Reference architectures you can stand up as-is
- Guardrails baked in, not bolted on later
The Doctrine
The methodology behind every default — the CAMPUX Way, written down.
- Why each secure default exists, in plain English
- What it protects against, and the trade-off it makes
- How to change it safely when your case is different
Real modules, not a promise
Two reference builds, each shipped in both languages, each with its doctrine docs. Concrete enough to deploy this week.
Secure Azure landing zone
- Management groups and subscription layout
- Least-privilege RBAC, no standing owner roles
- Azure Policy guardrails that deny by default
- Private networking — hub and spoke, no public exposure
- Tagging, budgets, and cost alerts from day one
- Monitoring and Log Analytics wired in
- CI/CD with OIDC — no long-lived secrets
AI-workload reference
- Azure OpenAI and inference behind private endpoints
- Quota-aware capacity — plan it, do not discover it
- Cost controls sized for tokens, not just VMs
- Data kept inside the boundary by default
- The same doctrine docs as everything else
A secure foundation in an afternoon
Same ethos as the CAMPUX labs — run it in your own subscription, at low cost, and tear it down clean when you are done.
Clone
Pull the repo. Pick Bicep or Terraform — both are there, no conversion needed.
Configure
Fill in a small parameters file: names, regions, budget ceilings. The defaults are the safe ones.
Deploy
One pipeline run. Management groups, network, policy, monitoring, and budgets come up together.
Read the doctrine
Each module links to the reasoning behind it, so you can explain and adapt every choice — not just run it.
Tear down
A safe teardown path leaves nothing running and nothing billing. Same as every lab we ship.
The framework we teach, productized
Keel is not a side project bolted onto a course. It is the same secure-by-default thinking that runs through the bootcamp, the labs, and the capstones — packaged so you can deploy it. The teaching is the unfair advantage.
Learn the ground
Forty-two free classes that teach the concepts Keel encodes — start at the beginning.
The labs
Real Azure labs, run at low cost and torn down after. Keel deploys the same way.
The capstones
Portfolio-grade builds you defend in interviews. Keel is one you can put your name on.
100 Days of Azure
The whole path, sequenced. Keel is where the secure-infra chapters land in practice.
Two lanes, one framework
Proof you can defend
- Deploy a real, secure Azure estate and screenshot it
- Put it on your résumé as portfolio-grade work
- Read the doctrine, then defend every choice in an interview
- Understand why it is safe — not just that it ran
Stop reinventing the wheel
- Adopt one secure baseline instead of arguing it out again
- Ship new subscriptions from a paved, opinionated road
- Onboard engineers against a documented standard
- Fork it, own it, adapt it — it is your code
Free core, honestly
The landing zone, the AI-workload reference, and the doctrine are open and free. No signup wall, no feature held back, no "contact sales" to see the code. Clone it and go.
Where paid fits, later and stated plainly: pro modules, support, and maybe a hosted option — for teams who want them. None of that gates what is here now, and the secure core stays free. If that ever changes, it will be said out loud, not slipped in.
Where this goes
It is early. Here is the honest arc — and the parts you can push on.
The page
You are reading it. The pitch, the shape, the first modules described.
The repo
Landing zone and AI reference in Bicep and Terraform, with doctrine docs.
Community
Contributors, issues, more references. Pull requests welcome from day one.
Paid tier
Pro modules, support, hosted — for teams, without gating the core.
Star it. Get a note when modules ship.
The fastest way to follow along is a GitHub star — it tells us this is worth building faster. Leave an email and you will hear once, each time a real module lands. Nothing else.
Straight answers
Is Keel really free?
Yes. The core is open-source under the MIT license. Nothing is gated. Clone it, deploy it, fork it, ship it in production. Later there may be paid pro modules, support, or a hosted option — but the landing zone, the AI-workload reference, and the doctrine that comes with them stay free and stay open.
Bicep or Terraform?
Both. Every module ships in Bicep and in Terraform, and both come with the same doctrine docs. Use whichever your team already runs. You are not forced to pick a side to get the secure defaults.
Is it production-ready?
It is early. This is v0. The landing zone and AI-workload reference are real and deployable, and the defaults are the ones we would put in production — least-privilege RBAC, private networking, policy guardrails, budgets and alerts. 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.
How is Keel different from Microsoft's Cloud Adoption Framework and landing zones?
The Cloud Adoption Framework is a 400-tab document — guidance you still have to translate into code and decisions. Keel is the paved road: an opinionated, secure-by-default implementation you can actually deploy, plus the reasoning for every choice so you can defend it and change it. CAF tells you what good looks like. Keel hands you the code and tells you why it is built that way.
Does it cover AI workloads?
Yes. Alongside the everyday landing zone there is an AI-workload reference: secure Azure OpenAI and inference behind private endpoints, quota-aware capacity, and cost controls — the failure modes that are specific to AI infra, handled by default.
Do I need to be an expert to use it?
No. It is learner-first. Deploy it as portfolio-grade proof, read the doctrine to understand why it is safe, and you will be able to defend every decision in an interview. Teams running Azure at work can adopt the same baseline instead of reinventing the secure-landing-zone wheel.