Skip to content
Blax Blax Group
Operations · Linux

Linux everywhere

The OS your software runs on in production should not be a stranger to the people writing it. We use Linux end to end, from our workstations to our servers, because the smallest gap between dev and prod is the gap that closes the most bugs.

Server racks in a dark room, with bundles of network cables and small status lights.
Fabian Wagner, founder of Blax Software

Fabian Wagner, founder of Blax

Published Updated

WorkstationsLinux
Production hostsLinux
Gap between dev and prodNo OS surprises

Same OS, end to end

A Blax engineer's laptop runs Linux. Their IDE runs on Linux. Their shell is the same shell that is on the server you will deploy to. The file paths, the package manager, the signals, the way a process pins a CPU core: identical at every step. When a bug only reproduces in production, it is rarely "production has a different OS"; it is something specific, and we find it faster because the OS itself is not part of the mystery.

Why this matters at 2am

Production incidents tend to surface at the worst hours. The engineer answering the phone on a Friday at 2am does not have time to learn the OS that night. They are using it, on their laptop, the same way they will use it on the production server. Same diagnostics, same logging conventions, same shell muscle memory. Linux familiarity is part of the incident-response kit, not something you pick up the moment you need it.

It composes with the rest

Linux is the substrate underneath every other conviction we have. Docker only makes sense because Linux gave us namespaces and cgroups. Open source by default only works because Linux IS open source. Our WebSocket runtime picks the same event-loop primitives the kernel exposes. Each one of these is cheaper, more reliable, and more debuggable because the underlying OS is the same boring, ubiquitous thing.

Which distribution, and why it does not matter

Internally we mix Fedora, Ubuntu, NixOS and Raspbian depending on the job, and our production hosts are usually whatever the customer's team is comfortable maintaining. The point is not the distribution. The point is that "Linux" is the family we live inside, the same way a wood-shop lives inside "wood" without making a religion of which oak they bought this month. Pick what works for you; we deliver in it.

What it means for your project

A Linux-native team picks the right tools the first time. Cron, systemd, iptables, ssh, fail2ban, journalctl, the standard libc, the standard process model: these are not bespoke skills for us, they are how we already work. Your project does not pay an "OS learning curve" tax. You also avoid the soft-but-real costs of a stack that grew up on macOS and gets surprised by case sensitivity, gets confused by symlinks, or forgets that production does not have Homebrew.
The smallest gap between dev and prod is the gap that closes the most bugs. We removed the OS from that gap a decade ago.
Why we run Linux everywhere

More perspectives

Engineering

Why we build WebSocket-first

Guide

PHP 8.2 end of life: move WordPress to PHP 8.4 without the critical error

Guide

Hacked WordPress: the first steps

Guide

What a security check covers, and what it does not

Guide

Website relaunch: when it pays off and how existing URLs keep working

Guide

WooCommerce or Shopify for an Austrian shop

Guide

Accessibility in online shops: what applies since June 2025

Operations

Docker by default, Traefik on top

Business model

Open source by default

Workflow

How we work with AI

Trust

Every minute, with a note

Product · Craft

We build for the morning user

How we engage

Built with startups

Curious how this plays out in practice?

These essays are the why. The how shows up in the projects we ship. Drop us a note and we can talk about your specific case.

Build with us Perspectives