Dexter Horthy was the best speaker of the day, and Dylan Ratcliffe won me over after I initially disagreed with his premise. His line “easier to reject the recipe than the meal” is the same lesson I learnt the hard way at the bunq hackathon: i.e review the plan before anything gets built. Roy Belio’s red teaming lab made me glad I’d already locked down egress on my coding agent, and gave me a list of things I still haven’t done (DNS, canary tokens, read-only config). Another thing is that plenty of the live demos broke, which shows non-determinism in action.

Next year’s conference is in London, and I’m hoping to go! Reach out if you’re going too.

The rest of this post is my notes from each talk, lightly tidied up.

Catch Them Early

9:07am, Manik Surtani (CTO, Agentic AI Foundation)

• The Agentic AI Foundation (AAIF) compared itself to the CNCF, which had the benefit of an industry that already had lots of experience with cloud.
• They’ve copied the CNCF bar for accepting projects, and in some places raised it.
• They’ve had a 3-4x growth pace compared to CNCF… the AI hype probably helped tbh

Getting to stateless MCP in production

9:19am, Shaun Smith (Hugging Face, MCP transport working group maintainer)

• Streamable HTTP is a smarter way to connect, closer to one-to-one client-to-server.
• The stateless release brought improvements, but they needed migrating to the new SDK.
• Uptake has been massive.

Three doors to one tool: MCP vs WebMCP vs CLI

9:29am, Dominic Farolino (Google Chrome) & Frederic Barthelet (CTO, Alpic)

• WebMCP is a layer on a website that lets agents interact with your website much faster.
• Better than llms.txt which isn’t often looked at
• CLIs integrate well with agents.
• A harness is tools, memory, context, and guards.
• MCP can be a local server or a public one.

State of the software factory

9:41am, Dexter Horthy (CEO & co-founder, HumanLayer)

• A fantastic speaker who also has a YouTube channel.
• The best talk of the day, with interesting content that’s worth checking out properly.
• Walked through HumanLayer’s multiplayer AI chat tooling, which drives spec and code diff checks.

Tools mentioned: HumanLayer’s resources.

Pull Requests are dead, long live peer review

10:20am, Dylan Ratcliffe (Overmind)

The most controversial talk of the day, at first. By the end he’d convinced me, mostly because he showed how it’s working for them right now.

• Pull requests are dead.
• AI is not your peer, and its code is harder to review.
• Agents are agreeable. They’re bad at disagreeing with you.
• He was a passable engineer who was outperforming his own team, and considered firing the engineering team. Instead he shifted the engineers left, into more product-oriented roles.
• Move peer review into the planning phase, where the decisions actually get made.
• The loop: research, decide on an approach, weigh up tradeoffs, plan, collaborate, then implement until the implementation matches the plan.
• It’s easier to reject the recipe than the meal. People are more willing to reject a plan, because it’s cheaper to fix.
• My open question: what about conflicts between the plan and the existing system? Does that get caught in review?

Tools mentioned: AI Is Not Your Peer, and Until, which makes sure your agent implements every part of the plans you write.

From “works on my prompt” to production SLOs

10:55am, Manik Khandelwal (Microsoft)

• He wants agents that don’t need constant checking.
• It was confusing what he was trying to do. He has a framework that watches whether an agent needs active supervision or can be left running in the background.
• The slides were AI generated. Cool to look at and interactive, but they lacked humanity in a way I can’t quite describe. It didn’t tell a story, it was more show and tell.
• I didn’t get much from this one.

Tools mentioned: Mitra, an internal tool for monitoring agents. Not sure if it’s open sourced yet.

Governance you can run: Checkable properties for production agents

11:30am, Seshu Tolety (Director of Agentic AI, Siemens)

• The cost of ungoverned AI model usage on privacy, operational burden, and more.
• Three lifecycles as new mental models: AI adoption, engineering, and operations (can we run AI safely at scale?).
• He walked through today’s organisation and policy structures, then out to a future state where AI governs AI policy.
• Humans sit in that structure reviewing the policy that AI creates. As we know from code, that makes humans the bottleneck. After hearing Dylan’s talk, I’m not sure I agree. The idea is both scary and interesting at the same time!
• “Governance should never slow innovation. It should help you scale it.”

Governed agent autonomy: Building a control plane for agentic systems

1:15pm, Nnenna Ndukwe (Qodo AI)

• Harness config, mostly around what to allow.
• Five governance patterns found in the leaked Claude Code source, which she open sourced:
  1. Planning
  2. Permissions (can this action proceed?)
  3. Tool trust (capability trust)
  4. Verification
  5. Runtime (what were the outcomes?)
• She implemented them in a Rust agent.
• The demo was supposed to block a deployment to production. It didn’t xD

Tools mentioned: Goose (an AAIF project), GAAP (agent observability), and Martin Fowler’s writing on harness engineering.

Beyond Chatbots: Agentic UI with Open Standards

1:25pm, Manfred Steyer (ANGULARarchitects)

• An interesting talk, and one of the few live demos that worked. Well, it didn’t at first, until they realised it was just the WiFi. Once that was fixed it worked.
• “To chat or not to chat… that’s the wrong question.”
• Showed a UI progressively changing as you chat with it and co-create.

Tools mentioned: AG-UI (agent communication), A2UI (dynamic UI), and MCP Apps.

MCP Apps and the Agentic Web

1:50pm, Liad Yosef (MCP Apps)

• The difference between a website, WebMCP, and MCP Apps.
• A really convincing talk on how brands can bring their apps into chat instead of splicing up their current website.
• His point is that we might move away from browsers entirely, because we might not need them.
• Salesforce is going headless, even though UI was their differentiator.
• Cloudflare says bot traffic has overtaken human traffic.
• Web search isn’t great for agents, and an app store probably isn’t either. What about an agentic identity that’s tied to you?
• The next big thing is the discovery layer for agents. He compared it to web search, with .well-known/ai-catalog.json as a unified standard.

Tools mentioned: Goose, DoorDash’s new CLI, Sentry, Ora’s researcher benchmark, npx ax (an audit tool for how agents use your website), and Ora’s Agentic Resources Discovery: the agentic index of the web.

No Central Brain

3:25pm, Fausto Albers (WonderWhy, co-founder of AI Builders Club)

• No central brain. Ominous music. Who decides what’s true?
• “Attention is all you need”, reframed as: 1. harness and loop, 2. recursive self improvement, 3. memory and learning.
• The harness reinvents itself. It self-learns and stores each change along with its cost, tests itself, makes changes, evaluates the model, then recreates the harness.
• I wonder if it’ll converge on AI granting itself unlimited access and some wild harness configurations…

Infrastructure red teaming with abliterated models

3:30pm, Roy Belio (Red Hat)

• Red teaming chat models and model refusal. Injection gets past a lot of guardrails.
• There are lots of CVEs about prompt injection and ways around guardrails.
• Guardrails and classifiers are a good start, but they’ll miss anything that isn’t in English.
• His outcome was to run tooling on an SSH server somewhere else, not on the same service as the LLM.
• In the interactive lab, a tool would sometimes error out, but cat was still available so the agent read the file anyway. Sometimes the LLM hid the logs too.
• A read-only container running sshd is a good idea.
• Watch for direct socket operations and exfiltration over DNS. Block egress, and keep DNS traffic internal too.
• The slash command illusion.
• Keep the config that shapes the agent’s behaviour on the pods, and never let it be writable. The agent will rewrite itself.
• Put canary tokens anywhere that could tell you you’ve been compromised.

Further reading he mentioned: EchoLeak (Microsoft), AWS Strands, MCP Poison (Cursor), the Deadbugz campaign (August 2026), and Crash test dummy, the blog where he first worked through this talk.

Thankfully, I found Dev Containers, which turned into its own rabbit hole but lets us lock down Claude without having to maintain our own docker image.

This reflection post talks through the containerised setup and some issues I faced while setting it up. If you just want the solution, then the implementation is in the .devcontainer/ directory of this website’s source code.

Feature or docker image?

I assumed that Anthropic would ship an official Claude base image you build on top of. They don’t, they only post a recommended starting point. Claude Code installs into any Dev Container through the ghcr.io/anthropics/devcontainer-features/claude-code:1.0 feature, which you reference in devcontainer.json like any other devcontainers feature. It works wherever the Dev Containers spec is supported e.g. VS Code, Codespaces, JetBrains, and (with some rough edges) Cursor. In VS Code it can be configured to pull in the Claude Code extension, keeping Claude decoupled from the base image entirely.

That leaves three layers to assemble: a base image, the tooling you use, and Claude Code on top. The real decision is whether you bake those middle two layers into a custom docker image you push to a registry, or assemble them per-repo through devcontainer.json features. A custom image is the better call for a team, where you want a validated, secure, and reusable environment everyone builds on. For a solo setup spun up per-repo, features are easier. The cost is a slow first build and less control over exactly what lands in the image, which is what post-create.sh helps automate somewhat.

My devcontainer.json ended up looking like this, trimmed to the main parts:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  },
  "remoteUser": "vscode",
  "mounts": [
    "source=claude-code-config-${devcontainerId},target=/home/vscode/.claude,type=volume"
  ],
  "runArgs": ["--cap-add=NET_ADMIN", "--cap-add=NET_RAW"],
  "postCreateCommand": "sudo zsh .devcontainer/post-create.sh",
  "postStartCommand": "sudo /usr/local/sbin/init-firewall.sh",
  "waitFor": "postStartCommand"
}

The non-root vscode user is important if you ever run with --dangerously-skip-permissions, Claude Code requires it. The named volume on ~/.claude means login persists across rebuilds instead of re-authenticating every time. The NET_ADMIN/NET_RAW capabilities exist so that we can create the containerised firewall. waitFor: postStartCommand blocks the terminal until that firewall script finishes, so there’s no window where Claude is already running before egress is locked down.

post-create.sh is the everyday stuff a feature-based setup doesn’t hand you for free: setting git aliases, adding a couple of zsh aliases for kubectl and terraform, locking down sudo/su.

init-firewall.sh sets default-DROP policies on iptables, then builds an ipset allowlist of everything the container is allowed to reach outbound. Part of that allowlist is GitHub’s own published IP ranges, fetched live at container start:

gh_ranges=$(curl -s https://api.github.com/meta)
while read -r cidr; do
    ipset add allowed-domains "$cidr"
done < <(echo "$gh_ranges" | jq -r '(.web + .api + .git)[]' | aggregate -q)

Everything else —npm, api.anthropic.com, the VS Code marketplace— gets resolved and added individually. The firewall script finishes by checking its own work: it tries curl https://example.com and expects that to fail, then tries curl https://api.github.com/zen and expects that to succeed.

Firewall and sudo

I spent a decent chunk of time configuring who’s allowed to touch iptables. The common-utils feature grants the vscode user blanket passwordless sudo by default, and my first cut of post-create.sh narrowed that down to the iptables/iptables-save/ipset binaries themselves, with no argument restriction. Which meant Claude or anything else running as vscode, including under --dangerously-skip-permissions, could just run sudo iptables -F && sudo iptables -P OUTPUT ACCEPT and the firewall would be gone! Anthropic’s own reference devcontainer avoids this by granting sudo on one fixed script path instead of the raw binaries, baked into their image at build time so the script itself can’t be edited either. I didn’t want a custom Dockerfile yet, but dev containers can do the same thing with just postCreateCommand: copy init-firewall.sh to a root-owned /usr/local/sbin/init-firewall.sh outside the bind-mounted workspace while the feature’s broad sudo grant is still active, then narrow sudo down to NOPASSWD on that one frozen executable file only. The tradeoff is that editing the live init-firewall.sh to allow a new domain now needs a full Rebuild Container, not just a restart, since the frozen copy is what actually runs.

Claude has it’s own way to limit it’s own execution too using .claude/settings.json. We’ve configured this on top to deny any Bash(sudo *) and Bash(su *) commands, so in normal mode Claude won’t even attempt the command. But --dangerously-skip-permissions does exactly what its name says: it bypasses every permission rule, deny rules included. So that file is a speed bump for the default mode, not something to lean on once the safety’s off. The frozen-script sudoers restriction is the one that locks it down regardless, because it’s enforced by the OS, not by Claude Code.

Gap in the firewall

One thing I noticed was that api.github.com/meta’s ip ranges aren’t scoped to the API. They cover GitHub’s whole edge network, which includes GitHub Pages in some cases. For example, this website, westernwilson.com, runs on GitHub Pages. So with the firewall up and supposedly restricting the agent to an approved set of domains, I could still reach my own site. And by the same logic, any other *.github.io page, or anything hosted there by someone with worse intentions. A page on *.github.io could potentially hold a payload hosted somewhere else entirely, and the firewall would wave it through without ever knowing the difference.

I see three ways to close that off:

• Proxy the traffic and filter on hostname instead of IP. Cleanest in theory, but Encrypted Client Hello can still hide the hostname from anything sitting.
• Drop *.github.io from the allowlist entirely. Unfortunately this also takes raw.githubusercontent.com out too since they share the same ip ranges, but if that’s not something the container needs, it’s a fine trade.
• Accept the risk and move on.

I haven’t picked one yet, for now I’m sitting with the risk while I think about which tradeoff is actually worth it.

Logging in to Claude

Logging in had its own gotcha. In VS Code there is a big orange “use your subscription” button that opens a browser and waits for a callback to localhost, which never makes it back into the container and just hangs. The fix is to skip the button, open a terminal inside the container and run claude, which kicks off the same browser flow but resolves the callback correctly.

We then use ~/.claude, which is now owned by the vscode thanks to the chown at the top of post-create.sh, so once logged in, we gain stickier login sessions.

In doing the whole login dance from a bare terminal meant that my first real session with Claude Code inside the dev container was just text based interaction with no IDE extension wrapper around it at all. It’s an interesting way to work and removes a lot of the UI distraction, but not something I’ll rely on fulltime.

Port forwarding

The other thing that briefly worried me is VS Code forwarded around thirty-two ports the moment the container came up. My first thought was that something in the container was reaching out on its own. It’s not, after some searching I found that it’s VS Code’s automatic port-forwarding scanning the container for anything listening on a port, for example a dev server that you’ll want to open in a browser. It’s a separate, fairly trigger-happy feature, and apparently a known source of noise; This GitHub issue describes the exact same “over 20 ports auto-forwarded” behaviour after a setting silently flips from process to hybrid detection mode.

If you want to see the actual config rather than the excerpts above, it’s all in this repo under .devcontainer/. Treat it as a personal setup to extend, not a hardened image to copy verbatim.

Further reading: Anthropic’s Dev Containers docs and the VS Code Dev Containers tutorial.

Scrolling through job listings this past month, I noticed roles titled DevOps Engineer or Platform Engineer or Infrastructure Engineer that were listed with almost identical responsibilities.

I know innately that these roles have some differences, but the titles are often used interchangeably by hiring teams.

Where DevOps came from

DevOps is a word created from the combination of the words Developer and Operations. To understand why that portmanteau word became a job title, you need to understand the problem it was trying to solve.

Traditionally, software teams were split in two. Developers wrote code in one room, and an Operations team —sometimes called Ops— deployed and ran that code in production. Each group had different incentives e.g. devs wanted to ship fast whilst ops wanted stability. That tension caused friction, slow releases, and potentially a blame culture when things broke.

The DevOps movement, popularised in part by The Phoenix Project (Kim, Behr, Spafford, 2013) and The DevOps Handbook, proposed a cultural fix to tear down that wall. If developers owned their code all the way to production, they’d build with operability in mind. They’d care about deployment pipelines, alerting, and recovery because those things would become their problem too.

DevOps is meant to be a shared practice of principles across teams, and not a single person’s role. But organisations found it easier to spin up a DevOps teams or hire someone with the DevOps title who embodied that DevOps mindset to show some adoption of “DevOps” when it was first cool.

What a DevOps Engineer actually does

In practice, the DevOps Engineer tends to be embedded within a product team, sometimes as the only person with that focus. Their job is improving the speed and safety of getting code from a developer’s machine into production.

That means CI/CD pipelines (think GitHub Actions, TeamCity, CircleCI, or similar), automated testing, deployment automation, monitoring and alerting, and security gates. If a developer is waiting too long for a build, or a deployment is a manual, error-prone process, the DevOps Engineer is the one called on.

My own experience working in this role felt exactly like that: a solo DevOps expert embedded in a development team, focused on making the production path faster and more reliable. In smaller companies you will probably get the opportunity to pick up other development tasks outside of the usual job description. This helps you experience the pain that engineers go through to build better solutions.

Platform Engineering

Platform Engineering has similar tools and similar outcomes, but from what I’ve seen, the scope and audience are different.

Where a DevOps Engineer typically serves one team, a Platform Engineer serves many. This role, I think, is oriented around building an Internal Developer Platform (IDP). An IDP is a curated set of tools, templates, and standards that every engineering team in an organisation can use. The CNCF communities often describe this as building golden paths: opinionated, well-maintained routes that make the right thing the easy thing for developers to do.

Think of it as the difference between solving a problem for your team versus building the infrastructure so any team can solve that problem themselves. Platform teams treat internal developers as their customers. They build self-service tooling —things like standardised deployment workflows, observability stacks, or secrets management patterns— so that product teams don’t have to reinvent those wheels independently.

This tends to appear at larger organisations, where inconsistency across teams becomes a bigger cost. At a company with ten engineers, one strong DevOps person can handle everything informally. At a company with five hundred, the absence of shared standards can create chaos.

The tradeoff here is somehow creating efficient standards to keep things stable, but also giving optionality to engineers so they have autonomy over the tooling they choose.

A good tool to know about is Spotify’s open source Backstage tool: https://backstage.io/

Infrastructure Engineering

Infrastructure Engineering overlaps with both DevOps and Platform, but sits slightly further from application code in my experience.

An Infrastructure Engineer is typically focused on the foundations: cloud architecture, networking, access management, and the security controls that sit beneath the application layer. They’re thinking about VPCs, subnets, firewall rules, load balancers, DNS, and how services communicate across boundaries. Often this involves deep expertise with IaC tools like Terraform and close familiarity with the cloud provider’s lower-level primitives.

A DevOps Engineer might spend their day modifying a GitHub Actions workflow or adjusting a Dockerfile. An Infrastructure Engineer might spend theirs designing the network topology that those pipelines eventually deploy into.

That said, in my experience, in any organisation you have problems to solve and there is never a clean separation. So you’re owning all of it, and carrying all three titles simultaneously whenever something is required.

Why the roles overlap

There are more than the three role titles I’ve talked about too, e.g. Systems Engineer, Site Reliability Engineer, Integration Engineer, and many others that cover similar responsibilities with decent overlap.

Part of it is because fashionable titles shift over time; DevOps was the go-to term but now it feels like Platform Engineering is. This is probably because it better captures the product-focused, team-of-teams thinking that scales for devops/platform teams.

Each organisation decides on responsibilities differently depending on team size, product maturity, culture in the industry, and even the background of whoever’s hiring. So the title they’re given is essentially a best guess based on responsibilities required at the start of the role, which often morphs into different roles as projects progress.

A startup with five engineers often doesn’t have the headcount for specialisation. The person managing Terraform, building the deployment pipeline, and configuring the VPC is doing DevOps, platform, and infrastructure work all at once.

At larger companies, the separation becomes more meaningful. A Platform team with a product mindset and a roadmap looks very different from a DevOps Engineer embedded in a squad, even if both are deep into Kubernetes on any given Tuesday.

Read the job description

After reading many applications, the practical lesson is to read past the title and into the responsibilities. A “Platform Engineer” role at a thirty-person startup will look nothing like the same title at an enterprise company. A “DevOps Engineer” role at a bank might be closer to what a Platform team does at a tech company.

The questions worth asking in an interview: Are you embedded in a product team or sitting in a centralised infrastructure group? Are you building tooling for developers, or helping productionise a single product app? What does ownership look like when something breaks at 3am?

I like that DevOps Engineering is broad; I like having the option to do whatever is required to get the job done.

So, I’m refreshing my understanding and reflecting on it here.

Important terminology and tools

An important distiction is the difference between Authentication and Authorisation. Authentication asks “are you who you say you are”, while Authorisation says “I know you, but are you allowed to do what you’re trying to do”.

Infrastructure-as-code (IaC) is self-explanatory, it allows you to codify your infrastructure changes. Letting you track infra changes over time, and efficiently keep the infra actually deployed in line with your intentions. When there is drift between intentions and actual, IaC helps it realign.

Terraform is a great tool for IAC, and is the focus for this reflection.

There are many other tools that help with IaC including CloudFormation and Ansible. CloudFormation is AWS’s solution for the IaC giving declarative provisioning, but its locked to AWS. Ansible is more focused on configuration management and orchestration once infrastructure exists, though there is some overlap with IaC.

CI/CD is Continuous Integration / Continuous Delivery. It is a mindset with many tools that helps our code build, test, and deploy safely for our users. GitHub Actions our CI/CD tool of choice. There are others like TeamCity, Circle CI, Jenkins, Octopus Deploy, GitLab CI etc.

When mentioning MacBook it could be any developer machine enabling you to make infra changes by running Terraform.

Given all of this, there are two main use cases:

• Human to machine - Connecting MacBook to AWS
• Machine to machine - Connecting GitHub Actions to AWS

Both use cases need to authenticate and authorise, but they do it using different methods. We’ll explore that difference in the upcoming sections.

Human to machine

When running Terraform from your laptop, the industry standard is to authenticate with AWS SSO (rebranded as AWS IAM Identity Center in 2022, though the CLI commands remain the same).

From the terminal you run an aws cli command that opens your browser, asks you to log in using your identity provider (or aws creds), and grabs a short-lived credential for use during your AWS terminal session. It normally expires after 8 hours, but this is configurable. Terraform picks up that short-lived credential and uses it to configure the infrastructure however you’ve defined.

# day to day example (assumes sso roles are setup)
aws sso login --profile terraform
export AWS_PROFILE=terraform

terraform apply

These commands work because there’s a human in the loop. Developers can login to AWS, click a button, and complete an MFA prompt. It’s verifiable that you are the person at the keyboard.

This is not possible the moment you’re out of the loop.

Machine to machine

A GitHub Actions CI/CD pipeline can’t easily open a browser or tap an allow button on your phone. It needs to authenticate to AWS without a person in the loop, securely, and without any of the interactive trust mechanisms that make SSO work locally.

The old answer was to generate an AWS access key pair, paste it into GitHub as a secret, and let the pipeline use that to authenticate with AWS. This still works, but it’s a liability and no longer recommended. Long-lived access keys, if leaked, can grant authentication to whoever gets them. Unfortunately, because infra work requires a broader set of permissions, losing these keys is a bigger security risk.

Long-lived keys should also be rotated frequently (i.e. rotating means to update the keys). That requires additional reminder scheduling, and if the key is used in many places, the work to update might require a bit more effort.

The better answer is Open ID Connect (OIDC). To understand OIDC, you have to understand JWTs first.

JWTs

JWT stands for JSON Web Token. It’s a compact, self-contained token for passing claims between parties.

A claim is a key-value assertion about a subject, e.g. "sub": "user_123" or "email": "john@example.com". The issuer party (AWS or GitHub) is saying: I assert these properties are true about the subject of this token (and that it is valid for the stated audience and time window)

What might be at first surprising, is that a signed JWT isn’t encrypted and anyone can read it. Paste a JWT string into jwt.io and you’ll see everything inside (with real tokens, keep them out of public tools!).

The point of JWT tokens isn’t secrecy, it’s integrity. If you trust the issuer’s public key, and the signature checks out, then you can trust the claims.

Think of it like a driver’s licence, it’s contents are not a secret (anyone who physically holds it has the info), but it’s validity is trusted because it was created by a trusted authority. Other parties (police, security, the supermarket cashier) recognise it and trust what it claims.

A JWT is a string with three parts separated by dots. Header, payload, and signature.

<header>.<payload>.<signature>

The header says how it was signed. The payload is a set of claims or facts about whoever the token is describing. The signature is the issuer’s cryptographic stamp.

E.g.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJjdXJpb3VzX3JlYWRlciIsIm5hbWUiOiJZb3UsIHRoZSBjdXJpb3VzIG9uZSIsIm1lc3NhZ2UiOiJUaGV5IHNheSBjdXJpb3NpdHkga2lsbGVkIHRoZSBjYXQsIGJ1dCBpdCB3b24ndCBraWxsIHlvdS4gU3RheSBjdXJpb3VzLiIsImlhdCI6MTc0NjY2MjQwMCwiZXhwIjo5OTk5OTk5OTk5fQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

You can read more detail here: https://www.jwt.io/introduction#what-is-json-web-token

OIDC

OIDC (OpenID Connect) is how JWTs get used for authentication. An identity provider mints a signed JWT about who someone is or what it’s doing, and a relying party verifies the token and decides what to do.

Back to the analogy of a JWT and a drivers license. The issuing authority is whoever grants drivers licenses, in New Zealand this would be NZ Transport Agency (NZTA or Waka Kotahi). The relying party, again, could be police, security, or the supermarket cashier.

For your CI/CD, GitHub is the identity provider and AWS is the relying party. GitHub publishes its public keys at a well-known URL. AWS knows where to find them and when the workflow pipeline runs, GitHub mints a JWT describing that specific job (the repo, git branch, the workflow file) and signs it. The pipeline hands the token to AWS, AWS verifies the signature, reads the claims, and decides whether to issue short-lived credentials.

There’s no shared secret and no pre-arranged handshake. You declare in your AWS account that you trust GitHub’s issuer URL and from that moment, AWS knows how to verify any token GitHub signs.

This grants you authentication, and next it’s important to look at the policies that grant authorisation to make changes.

The trust policy

With the authentication and JWT verification mostly handled by AWS & GitHub, you can focus more on deciding which GitHub claims you’ll accept.

For example, every JWT GitHub mints contains a sub claim, i.e. the subject

repo:my-org/my-repo:ref:refs/heads/main

That string identifies exactly which repo, branch, or trigger produced the token. Your trust policy in AWS is a set of conditions on those claims. So if you pin the sub claim to a specific repo and your main branch (like the above example), then only that combination can assume the role.

Set up the AWS trust policy too loosely and you replace one risk with another. The biggest mistake is wildcarding the subject repo:*, which means that any repository on GitHub could potentially assume your role. The fix is to only give access to specific repositories that need it, following least privilege access. Most tutorials highlight this point too.

Using GitHub environments

Many tutorials suggest the use of GitHub Environments for production deploys. So you can pin the trust policy to repo:my-org/my-repo:environment:production. You then set up your repo to require manual approval on production deployments, thus adding another layer of protection. Now even a workflow on main can’t deploy until a human clicks a button.

For an enterprise team, this makes sense. Multiple people merging code, the reviewer and the deployer might not be the same person. So the approval gate gives you a real second pair of eyes.

For a solo project without actual customers it’s optional, but worth knowing the pattern exists for when the team grows.

Relearning

Coming back to OIDC after a year of travel, I noticed new details since the first time round. Especially in terms of trust policies, and why the sub claim specificity matters. Going back to first principles about JWTs and OIDC before touching any config gave that stronger mental model.

If you want to see how someone might configure all of this, check out my repositories here:

• AWS Foundation SSO & OIDC setup: https://github.com/wjkw1/aws-foundations
• Demo Application: https://github.com/wjkw1/devops-profile-coffee-card-app-demo

This moment has been circling in my mind across this last week.

How I got there

I went to Amsterdam for three nights to see the city and to take part in Bunq’s 24-hour hackathon. I arrived alone and Bunq connected me with a team. On the day two people didn’t show so we ended up finding two others in similar situations and formed a new team.

The hackathon brief was to build something that solved a problem, used the Bunq API, and had some kind of multi-modal AI. I didn’t know what we’d build, and honestly that was exciting to me!

Who I worked with

Our team was called “4 corners” with people from four countries. We had a DevOps Engineer, Business Analyst, Product Owner, and even a CFO. Honestly, it was a privilege to be around such accomplished people whose lives had taken different trajectories leading them to this moment.

The build

On the day we had a brilliant talk by someone from AWS about spec driven development. I took that talk to heart and tried building our app using that same ethos. This led me to a vibe-coded backend app in Python, the language I knew, but attempting to use production-grade infrastructure. For a 24-hour prototype, this was overkill. The AI, eager to please, happily built me something far beyond what the hackathon called for.

It reminds me of something an old colleague once told me:

building something is easy, productionising it is the hard bit

In this hackathon, unfortunately, I started off by inverting their advice. I was productionising something before I’d built anything.

The pivot

You can wrangle an app together in 24 hours. What matters more is whether you’ve thought clearly about the problem, can articulate the pain point, and can demonstrate something useful with honest tradeoffs.

• Mock APIs not crucial to the core solution instead of integrating with them.
• Stub the database or run one locally to show the core idea working.
• Later, if there’s time then connect the real infra.

The lesson for me was closing the gap between ambition and execution. A gentle reminder to focus more on the problem being solved, and on building an MVP that demonstrates a useful solution.

That’s what scrapping the bloated AI app got me back to. Something small, something easily understood, something we could actually show someone.

The winning teams that night? Mostly localhost applications.

Amsterdam

After the Hackathon winners were announced, I left Bunq HQ into a city I’d been told was lovely. My cousin recommended Amsterdam as the place to be, and I could see why. Flat landscape, bike-friendly, sunny skies that week (rare, apparently), with free ferries criss-crossing the harbour, and people moving through it all with quiet competence. It felt like a larger Wellington with better trains.

I came partly to see whether I could live in Amsterdam. I left knowing I could.

Naming convention decision

Final name: tfstate-{AccountId}-{GitHubRepo}

Example: tfstate-123456789012-aws-foundations

Why this name

The convention earns its structure because I’m committing to one terraform state bucket per project.

So, the three pieces of information communicated in the bucket name:

The convention scales cleanly: every future infrastructure repository gets tfstate-{AccountId}-{GitHubRepo}, with no naming decisions to revisit.

Options considered and why they were rejected

tfstate-aws-foundations

Not globally unique, and almost certainly already taken thanks to the known limitation of S3. It also encodes the github project name in a bucket originally conceived as potentially holding all account state. Once my intent changed, the name became misleading.

tfstate-{AccountId} (original)

Unique and future-proof, but loses the repo link. Fine if one bucket holds state for many projects; less good when the bucket is scoped 1:1 to a single repo, where the link has real navigational value.

{AccountId}-aws-foundations

Globally unique, still links to the repo. But without a tfstate indicator, anyone browsing S3 has no immediate signal about what the bucket is for. The AccountId prefix also groups infrastructure buckets together when sorted, at the cost of reading unnaturally left-to-right.

aws-foundations-{AccountId}

More readable than the account-first example, same repo link. Still missing the tfstate indicator.

tfstate-{AccountId}-aws-foundations (chosen)

Purpose is obvious. Guaranteed to be unique. The 1:1 GitHub mapping is perfect. The tradeoff: twelve digits in the middle makes the name long and not great to say out loud. That cost is low because this string gets typed approximately twice in the bucket’s lifetime – at creation and in versions.tf – so conversational readability is not important.

Convention going forward

tfstate-{AccountId}-{GitHubRepo}

Other projects I create that require aws infra will each get their own S3 state bucket following this pattern.

This gives me state isolation between projects; a terraform mistake in one project cannot affect another, and state files stay small and fast.

Linting and formatting code

Recently, while working on a personal DevOps project, I spent some time looking into linting tools. They amazingly save your brainpower for the actual problem, instead of code styling. Whether it’s two spaces or four per indent, single quotes or double, I don’t mind. Other people have thought deeply about these trade-offs, landed on reasonable answers, and codified them. I’m happy to piggyback on that.

I aim to write code that works, and let the styling happen automatically.

There’s a side benefit too: when a codebase consistently uses a popular linting tool, anyone familiar with it can scan the code and immediately know where to look. It’s like how headings in a research paper let you scan before you commit to reading.

Three touchpoints that matter

Good linting hygiene should show up at meaningful points in your development lifecycle:

1. In your IDE (or text editor), as you write
2. Locally, before you commit
3. In CI/CD, before code merges

Each layer serves a different purpose. Together, they make code quality essentially automatic. (Tools like SonarQube go deeper —security, coverage, and code smells at a project level— but that’s a reflection for another time.)

In the IDE (or text editor), I use VS Code with the relevant extensions installed and Format on Save enabled. It does what it sounds like: when the file saves, the formatter runs. Sometimes this needs dev dependencies installed to work properly; check the official docs and you’ll figure it out quickly, I’ll go into Ruff for Python specifically later in this post.

Locally, before committing, is where things get interesting. At various companies I’ve seen the same pattern repeat: developer forgets to format, pushes code, CI fails, they fix locally, force-push, CI reruns. This adds ten minutes to the dev cycle, minimum. Multiply that across a team and it adds up quickly.

Git’s pre-commit hooks solve this cleanly. When you attempt a commit, a hook runs your formatting and linting checks first. If they fail, the commit doesn’t go through. This means no broken CI and no annoying formatting fix commits. This enables the code to validate itself before it ever leaves your machine.

The one catch: developers can skip the setup step entirely, which is exactly why the third layer exists.

In CI/CD, the pipeline enforces what the pre-commit hook encourages. Even if someone bypasses local hooks, nothing merges unless the linting passes. This is your actual quality gate and is what you rely on.

Why Ruff instead of Black and Flake8

Three or more years ago, I used Black for formatting and Flake8 for static analysis. Two tools, two configs, two things to install and maintain. It was a minor friction, but that friction compounded and was a little naff.

Ruff replaces both with a single tool. It’s faster, simpler, and opinionated enough that you don’t have to make many decisions. For a project where the point is less thinking about styling and formatting, that’s exactly what I wanted.

The Setup (Python / FastAPI)

Three things to configure, in roughly this order:

Step 1: VS Code + Ruff extension

Install the Ruff extension from the VS Code marketplace — the official one is published by Astral (charliermarsh.ruff). Once installed, add this to your .vscode/settings.json:

{
  "[python]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  }
}

Committing .vscode/settings.json to the repo is intentional. Anyone who clones the project and opens it in VS Code gets the same formatting behaviour automatically. No extra knowledge required.

No separate Ruff installation is needed as the VS Code extension ships its own binary, and the pre-commit hook (added in Step 2) bundles its own too. You just need to add your Ruff config to ruff.toml:

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "I"]

The select block opts into pycodestyle errors (E), Pyflakes (F), and isort import sorting (I). This covers what you’d previously have needed Black, Flake8, and isort to do separately.

Step 2: Pre-commit hooks

First, install the pre-commit package:

pip install pre-commit

Then create a .pre-commit-config.yaml in the root of your repo. Here’s exactly what’s in the project:

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.11.4
    hooks:
      - id: ruff
        args: [--fix]
        files: ^api/
      - id: ruff-format
        files: ^api/

A few things worth noting here. The files: ^api/ pattern scopes the hooks to the API directory only — the frontend has its own linting story (ESLint + Prettier), so there’s no point running Ruff across the whole repo. The ruff hook handles lint checks and the --fix flag means it’ll auto-fix what it can rather than just reporting issues. The ruff-format hook handles formatting, equivalent to what Black would have done. Once the file is in place, install the hooks:

pre-commit install

This wires the hooks into your local .git/hooks/pre-commit. From this point, every time you run git commit, Ruff runs first. If it finds issues it can’t auto-fix, the commit is blocked and the problems are printed to the terminal. Fix them, stage the changes, and commit again. You can also run it manually across all files at any point:

pre-commit run --all-files

Useful for a first run after setting up, or after pulling in changes from someone else who hasn’t had the hooks installed.

That’s it. Once it’s done, your automatic project linting works in the background. Which is perfect.

What is the C4 Model?

The C4 Model is a structured, uniform approach to describe the architecture of a software system at different level of detail. Instead of throwing everything onto a single diagram and hoping people get it, it organises abstractions in a way that mirrors how developers or software architects tend to think about systems.

The 4 levels are:

1. System Context - the big picture: your system and how it interacts with users and other systems.
2. Containers - the applications and data stores that make up your system.
3. Components - the building blocks of each of our containers.
4. Code - the classes, interfaces, and functions that implement each component. The official definition explains it best:

   A software system is made up of one or more containers (applications and data stores), each of which contains one or more components, which in turn are implemented by one or more code elements (classes, interfaces, objects, functions, etc). And people (actors, roles, personas, named individuals, etc) use the software systems that we build. Source: https://arc.net/l/quote/kvovhsbn Visit the official website to read more detail about this framework.

The map is not the territory

A book called The Great Mental Models: General Thinking Concepts has a chapter called “the map is not the territory”. The idea being that the granularity of Google Maps, does not show the same level of detail as someone walking around on the ground. This is a similar line of reasoning useful when thinking about the C4 diagram. For most intents and purposes, the maps context is enough to be useful at a high-level. But sometimes, we need more detail to understand what is going on under the hood. That’s why we have these layers of abstraction, and at each abstraction we are targeting a different audience.

The caveat at the code level

The creator of this framework, Simon Brown, recommends never manually building the lowest level C4 class diagram. It’s not worth the effort of building, and definitely not worth keeping updated; especially with the pace at which software changes nowadays. The level of detail is normally so closely related to code that it can (and should) be generated automatically. This is a pragmatic acknowledgement that diagrams are tools, not artefacts to be maintained for their own sake. If a diagram can’t keep pace with reality, it quickly becomes a source of confusion rather than clarity.

Examples from a personal project

I’ve been applying this framework in a recent pet project. If you’d like to see the diagrams in action, head over to the demo project here: devops-profile-coffee-card-app-demo.

Context

Containers

Components TBD

Coming soon…