I Deployed Infrastructure to a Commodore 64

...With Bicep. On real 1982 hardware. And it's fully idempotent.

Most people use Bicep to deploy resources to Azure. I used it to change the border color of a Commodore 64.

Here's the thing: with Bicep's experimental local deploy feature and a custom extension, Bicep can declare the desired state of anything with an API. At Microsoft Build I demoed this with a smart light bulb. But the idea kept nagging at me - how far could it go?

Then I looked at my desk. The reintroduced C64 Ultimate - the classic 1982 breadbin, now shipping with HDMI, WiFi and USB - exposes a REST API on the local network. Read memory, write memory, upload and run programs. All over HTTP.

So I built a custom Bicep extension in .NET, and now this is a real thing that works:

Run bicep local-deploy, and the physical machine converges to that state. Border turns red. Background turns green. Text appears.

And because the C64's hardware registers are readable, the extension implements a genuine desired-state loop: read actual state, compare, converge only when needed. Deploy twice and the second run changes nothing. Idempotency on a 44-year-old computer.

Then it escalated:

🎵 A Music resource that plays real SID chip music (Lazy Jones, 1984 - yes, the Kernkraft 400 melody)

👾 A Program resource that deploys a full 80's-style demo intro - raster bars, scroller, SID soundtrack - written in 6502 machine code and assembled by a tiny assembler I wrote in PowerShell

The takeaway is bigger than the gag: desired state configuration is a universal pattern, not a cloud feature. If a system can tell you its state and lets you change it, you can put a declarative, idempotent management layer on top. Bicep's extension model makes that surprisingly easy.

Want the full story?

📖 Full article with the complete technical deep dive:https://www.linkedin.com/pulse/infrastructure-code-1982-hardware-bicep-meets-commodore-freek-berson-xx1te/