Hey, I’m Anthony.

Start here You already know Terraform. So the fastest way to explain Crossplane is to tell you what it is not: it is not Terraform running inside a cluster. It is a different model, and the difference is the entire reason to care. Terraform is something you run. You point it at some config, it builds a plan, you apply, it exits. Crossplane is something that runs. You install it into Kubernetes, tell it what infrastructure you want, and a controller keeps reality matching that want forever. Nobody types apply. The loop never stops. ...

Why bother Every team eventually hits the moment where a developer needs a project, account, sub, or a bucket, or a pubsub, and the options are: file a ticket and wait three days, or DM the one person who knows the Terraform. Neither scales. So the developer does what developers do, which is find a way around you. They write a shell script. Then someone copies the shell script. Six months later you’ve got fourteen “projects” with no consistent IAM, no state backend anyone can find, and a bucket named test-final-real that’s somehow in production. ...

I kept guessing at how much context my agent prompts were eating. Not a great way to run things. The obvious fix is a token counter. The less obvious part is that you don’t need an API to build one. If you’re already running models locally, the tokenizer is right there. So I wrote a tiny CLI. Point it at a file, name a model, get a count. That’s the whole thing. ...

Filed under: Cloud Engineering · AI Infrastructure · Local Lab Where Part 1 left off In Part 1 we got Bifrost running locally, wired up Ollama with qwen3.5, and confirmed the stack end to end. Requests through the gateway, streaming, tool calling. This post adds MCP, the Model Context Protocol. Part 1 gave the model a reliable connection. This part gives it tools. By the end you’ll have a local MCP server exposing real capabilities (system info, allowlisted shell commands, math) connected through Bifrost so qwen3.5 can run them. Still no cloud. ...

Filed under: Cloud Engineering · AI Infrastructure · Local Lab The problem You wire an Ollama model into an app and it works. A couple months later you’ve got five apps, a few models, and no idea what’s calling what, how often, or what it’s doing to your GPU. That’s the gap an LLM gateway fills. This is Part 1 of a two-part series. Here we cover what a gateway does, why it’s worth running, and how to get Bifrost talking to Ollama qwen3.5 on your Mac. Fully local. ...