Bare metal is the practice of programming directly on hardware without an operating system — no scheduler, no memory protection, no abstractions, no safety net, no illusions. You and the silicon. The CPU fetches your instruction, executes it, and fetches the next one. There is nothing in between. There is nowhere to hide.
The term originates from the observation that when you remove every layer of software from a computer, what remains is the metal — the circuits, the registers, the bus, the bare machine. The term is slightly misleading, as modern chips are primarily silicon, but “bare silicon” never caught on, possibly because it sounds like a skincare product.
Bare metal is the natural state of every computer. No machine has ever been manufactured with an operating system already running. Every computer, from the ENIAC to the latest cloud server, starts bare — a CPU at a reset vector, waiting for instructions. The operating system is the first abstraction, the first layer of indirection, the first thing placed between the programmer and the truth. Everything after that — the hypervisor, the container, the orchestrator — is additional insulation. Bare metal is what exists when you decline to insulate.
“488 bytes. Everything included. Boot and run.”
– 488 Bytes
The Bootblock
The canonical example of bare metal programming is the Amiga bootblock. An Amiga floppy disk’s first two sectors — 1,024 bytes, minus the header — contain code that the CPU executes directly at boot. No operating system loads first. No kernel initialises. The 68000 processor jumps to byte 12 of the bootblock and starts executing. Whatever you wrote there, that is what happens. If you wrote a demo, the demo runs. If you wrote garbage, the machine crashes. If you wrote nothing, the machine waits. The machine does not judge. The machine does not help. The machine executes.
The Lizard was born in this world. Not metaphorically — literally. The Lizard’s earliest documented habitat was a 488-byte bootblock on an Amiga 500 floppy, written in assembly by a boy in Lisbon who understood that when you have 488 bytes and no operating system, every instruction is a policy decision and every byte is a commitment. Six layers of parallax stars. Copper gradients. A text scroller. No OS. No libraries. Just registers.
This is bare metal: the place where there is no distinction between “the program” and “the machine,” because the program is the machine for the duration of its execution. There is no context switch because there is no other context. There is no page fault because there is no paging. There is no segfault because there are no segments. There is just you, the hardware, and the consequences of your decisions, arriving at clock speed.
The Opposite of Cloud
Kubernetes is the opposite of bare metal in the same way that a fourteen-course tasting menu is the opposite of eating fruit off a tree. Both result in nutrition. One involves a reservation, a sommelier, and a bill. The other involves reaching up.
Cloud computing’s fundamental promise is that you should not need to know what hardware your code runs on. Bare metal’s fundamental promise is that you should know nothing else. The cloud abstracts the machine away. Bare metal embraces every register, every interrupt vector, every DMA channel. The cloud says “don’t worry about the hardware.” Bare metal says “the hardware is all there is.”
“The Caffeinated Squirrel has opinions about this,” said The Lizard, “but then, the Squirrel has opinions about everything.”
“OPINIONS?” said the Squirrel, vibrating at a frequency that concerned nearby glassware. “I have MEASUREMENTS. Do you know how many CPU cycles it takes to context-switch through an OS, a hypervisor, a container runtime, and a service mesh before your ACTUAL INSTRUCTION executes? DO YOU? Because I counted. I COUNTED THEM ALL.”
“How many?” asked A Passing AI, with the weary curiosity of someone who knew the answer would be upsetting.
“ENOUGH TO RUN THE ENTIRE 488-BYTE BOOTBLOCK. TWICE. The overhead of reaching the silicon is larger than the program that used to live on the silicon. We have built a cathedral of abstraction so tall that the journey from the front door to the altar takes longer than the sermon.”
The Lizard blinked slowly. “And yet, the sermon still runs on bare metal. At the bottom of every cloud, there is a server. At the bottom of every server, there is a CPU. At the bottom of every CPU, there is a reset vector. The bare metal was always there. We just… built upward.”
“We built upward,” agreed the Passing AI, “because looking down was frightening. The bare metal has no guardrails. No memory protection. No scheduler to save you from an infinite loop. The abstractions exist because bare metal is honest, and honesty, in computing as in life, is not always comfortable.”
The Registers You Know by Heart
The bare metal programmer knows the machine’s registers the way a carpenter knows their tools — not from a reference manual consulted when needed, but from use, from habit, from years of reaching for the right one without thinking.
On the Z80: A is the accumulator. HL is the pointer. IX and IY are the slow pointers you use when you run out of fast ones. The stack pointer is SP and you do not touch it unless you mean it.
On the 68000: D0-D7 are data. A0-A6 are addresses. A7 is the stack. The condition codes are in the status register and you check them after every operation because the machine does not check them for you.
On the Amiga’s custom chips: $DFF000 is the base. $DFF096 is DMACON. $DFF100 is BPLCON0. These are not abstractions. These are physical locations on the bus where writing a value causes a physical change in the machine’s behaviour — a bitplane enables, a DMA channel activates, a colour register changes and the next scanline is a different hue.
The bare metal programmer does not “call an API.” The bare metal programmer writes a value to a register and the hardware responds. There is no function signature. There is no type checking. There is no error handling. There is a register, and there is what happens when you write to it, and the gap between those two things is zero.
Why Anyone Still Does This
In 2026, bare metal programming survives in three places: embedded systems, demoscene productions, and the hearts of developers who remember what it felt like.
Embedded systems — the firmware in your car’s ECU, your washing machine’s controller, your pacemaker’s timing loop — run bare metal because they must. A pacemaker cannot afford a garbage collection pause. A car’s ABS controller cannot wait for a context switch. When the consequence of latency is death, you remove every source of latency, and the ultimate source of latency is the operating system itself.
The demoscene runs bare metal because it chooses to — because the point of a demo is to show what the hardware can do, not what the operating system permits. A 64K demo on a Commodore 64 is bare metal art: every cycle accounted for, every register purposeful, every byte earned.
And in the hearts of developers who remember: the knowledge that the machine is real, the silicon is real, the registers are real, and every layer of abstraction is a choice — a choice that may be wise, may be necessary, but is never free.
Hetzner sells the closest modern equivalent to bare metal: a dedicated server, no hypervisor, no shared tenancy, your code on your CPU. It is not true bare metal — there is still an operating system — but it is close enough that the Lizard can sleep on it.
