Open systems, European infrastructure and the quiet pleasure of building on your own terms

One of the more curious developments in modern software is that many organizations now build critical systems on foundations they do not fully understand, cannot meaningfully inspect and, in some cases, cannot realistically move away from. The arrangement works well enough until it does not.

Costs rise. Terms change. APIs disappear. Product roadmaps drift in directions no one inside the organization has any influence over. What initially appeared convenient gradually becomes structural dependency. This is not always catastrophic. Often it is simply expensive, limiting and faintly absurd. There is another way to build. It is less fashionable, occasionally less polished and often considerably more satisfying. Build on open systems. Use technologies you can inspect. Prefer infrastructure providers that are geographically and politically close to the environments in which you operate. Accept a few constraints in exchange for substantially greater understanding and control. In short: know what your software stands on.

Open source is not ideology. It is operational common sense.

Open-source software is sometimes discussed in moral or philosophical terms. Those arguments have merit, but the practical case is even stronger. When the source code is available: you can understand how the system works, you can diagnose problems directly, you can modify behavior, you can move between providers, and you are not entirely dependent on the commercial priorities of another company. This is not romanticism. It is risk management. For individuals and organizations alike, open systems reduce long-term dependency and increase the number of strategic options available in the future. That alone is usually worth a great deal.

Constraints are useful design tools

There is a common assumption that software design improves as constraints disappear. The opposite is often true. Interesting systems emerge when technology choices impose discipline. A lightweight SQLite database encourages careful schema design. A Django template system rewards clarity. Docker forces one to think explicitly about environments and dependencies. Linux insists that problems be understood rather than merely clicked away. These are not inconveniences. They are productive boundaries. Good constraints narrow the field of possibilities just enough to make architecture more deliberate. Like meter in poetry or load-bearing walls in architecture, limitations can sharpen rather than diminish creativity.

Cost matters

Open systems are often substantially cheaper than heavily managed proprietary alternatives. But the more important saving is conceptual. When the tools are understandable, one spends less time negotiating opaque abstractions and more time solving the actual problem. The resulting systems are often: simpler, easier to maintain, less expensive to operate, and more adaptable over time. This is not austerity. It is engineering.

The European option

For European developers and organizations, infrastructure choices are increasingly strategic. Where systems run matters. Who controls the infrastructure matters. Which legal and regulatory environments apply matters. Using European providers does not solve every problem, but it introduces a healthier degree of alignment between technical infrastructure, business interests and jurisdiction. It also supports a broader and, in my view, worthwhile objective: maintaining a technologically capable and economically resilient European ecosystem. Not every server needs to be an act of geopolitical significance. But when two options are technically comparable, there is something sensible about choosing the one closer to home.

The stack we have been using

The projects documented here are built primarily with open-source tools and European infrastructure.

Each technology was selected less for novelty than for clarity and reliability.

Ubuntu

A remarkably stable and practical Linux distribution.

Ubuntu is opinionated enough to be coherent and open enough to remain genuinely useful. It serves equally well as a development workstation and production server.

Python

Readable, expressive and supported by an extraordinary ecosystem.

Python remains one of the most effective languages for combining data processing, automation, APIs and application development.

Django

An unusually mature web framework.

Django includes an ORM, authentication, templating, administration and a disciplined project structure. It rewards developers who appreciate systems that arrive with their own architectural vocabulary.

FastAPI

A modern framework for APIs that is both fast and pleasant to work with.

It pairs especially well with analytical and data-driven applications.

SQLite

Perhaps the most underestimated database in software.

For many applications, SQLite is not a compromise but an elegant and highly capable default.

Docker and Docker Compose

A disciplined way to package software and its dependencies.

Containers reduce ambiguity and make deployments reproducible.

Caddy

A reverse proxy with a refreshingly civilized approach to HTTPS.

Few pieces of software feel as though they genuinely want to be helpful.

Codeberg

A community-driven Git hosting platform based in Europe.

Thoughtful, reliable and refreshingly free of unnecessary ornament.

Hetzner Cloud

One of Europe’s great infrastructure success stories.

Technically excellent, cost-effective and reassuringly straightforward.

Why this stack is appealing

There is a certain aesthetic pleasure in systems that remain understandable from top to bottom. A request enters through Caddy, reaches a Docker container, is served by Django or FastAPI, reads from SQLite and returns a response. Every layer can be inspected. Every component can be replaced. Nothing feels magical in the pejorative sense. The system behaves like a machine rather than a mystery. For anyone who enjoys architecture, this is deeply satisfying.