← Back to blog
open-source docker self-hosting sovereignty privacy ai

From Snipe-IT to Onyx: How Open Source Taught Me AI Sovereignty (and Docker)

From a zero-budget inventory stack at L'Idem to a Mini PC running Docker: how open source forced me to learn infrastructure, privacy, and data sovereignty — all the way to the AI layer.

There’s a comfortable lie in tech: that information sovereignty is a topic for “big companies” or regulators in Brussels. Here’s the thing — it usually starts smaller. The day you can’t afford the license, you still need the tool, and you discover open source doesn’t just save money: it forces you to understand the system. That happened to me about four years ago in Barcelona, and that trade-off — discomfort for control — turned out to be the best school of my career.

This isn’t a tutorial. It’s the path from Snipe-IT to Onyx: from managing IT assets without expensive SaaS, to deciding where my prompts live. And along the way, why Docker stopped being “that DevOps thing” and became the language I use to ship almost everything.

1. Zero budget: L’Idem and the start of the journey

I was IT Manager at L’Idem Barcelona, an animation and digital arts school with physical servers under my watch. Real infrastructure existed. Budget for advanced inventory or password-management licenses did not. This wasn’t ideological open-source cosplay. It was simpler: either we improvised, or we had no tool.

Two pieces showed up that still frame this story:

  • Snipe-IT — IT asset management (hardware, licenses, who has what). Open source, self-hostable.
  • Vaultwarden — a server compatible with official Bitwarden clients (not Bitwarden’s official server; a lightweight, unofficial implementation built for self-hosting).

At first I understood nothing about containers. I followed YouTube guides — an Indian engineer with an endless library of IT walkthroughs — and installed Snipe-IT straight on Ubuntu, no Docker, bare metal. Beginner mistake. It worked… until dependencies, upgrades, and “why did this break?” sent me the invoice.

2. Publishing it on a URL: proxies, HTTPS, and the network toll

Getting the app running on a server is only half the problem. The other half: how do you reach it on a proper URL, with TLS, without hanging a raw port on the internet?

That’s where I learned, the hard way, what tutorials often skip:

  • Reverse proxy — the front door that terminates HTTPS and routes to the internal service.
  • CDN — edge distribution, sometimes caching.
  • WAF — perimeter filters against obvious junk and attacks.
  • HTTPS / cURL — not certification theory, but “why is this a 502?” and “what header am I actually sending?”.

We ran virtual machines on aging VMware at the company. VMs are useful: they isolate, emulate a full machine, bring their own OS. But if you’re deploying many small apps, the weight shows. Each VM is basically a whole PC. When you only need an application and its dependencies, that’s a steep toll.

3. Glovo, a 20 kg HP, and the MinisForum HM80

I landed a role at Glovo: better pay, more basic responsibilities than what I was already doing. Right before closing the chapter at L’Idem, they gifted me an old HP server — over 20 kg, about 16 GB of RAM and 10 cores — which was, affectionately, more mass than capability for what 2023 software demanded. I took it home, experimented, and not long after gave it to a colleague.

Then I bought my first Mini PC: a MinisForum HM80, around €550, 32 GB of RAM, 8 cores and 16 threads. A machine the size of a palm. That’s when the lab stopped being “inherited server that groans” and became infrastructure I chose.

4. A glossary I learned by breaking things

Before Docker, name the pieces without theater:

  • Virtual machine (VM) — abstracts hardware. Each VM typically brings its own OS and kernel. Strong isolation; more disk, RAM, and boot cost.
  • Container — isolates processes while sharing the host kernel. Lighter, starts in seconds, portable across environments.
  • Docker — the runtime and image format most of us use to package and run those containers reproducibly.
  • Docker Compose — a YAML file that defines multiple services (app, database, proxy…), networks, and volumes, and brings them up as one stack.
  • Open source — not just “free.” Per the Open Source Initiative, it implies real rights: use, study, modify, and redistribute with source available. That transparency is the base of sovereignty: you can inspect what runs with your data.

Note: VMs and containers aren’t enemies. In production you often run containers inside VMs. What does get obsolete, for dense lab and SME workloads, is treating every app like a full server.

5. The magic (without the magic) of Docker

With the HM80, the jump clicked: deploying every tool as its own VM was the long road. Docker + Compose gave me the same outcome — reasonable isolation, reproducibility — without spending weeks fighting system libraries.

It isn’t magic. It’s a contract: the image carries what the app needs; the YAML describes how it connects to the rest; the host provides kernel, disk, and network. The same pattern that would have spared me the bare-metal Snipe-IT install.

Since then, Docker has been the center of my lab. And Portainer — a clear UI for managing containers — is what I recommend as a starting base if you don’t want to live on the CLI… while you slowly learn when you’ll need something stronger (Kubernetes / K3s: that’s another post).

6. From inventory to AI sovereignty

The pattern repeats one layer up. First it was inventories and passwords. Now it’s prompts, context, and model policy.

In my public repo docker-compose-portainer I collect stacks ready for Portainer or the CLI: from the same Snipe-IT and Vaultwarden where this started, to AI-sovereignty pieces like LiteLLM (a gateway/proxy to many providers and models behind a compatible API) and Onyx (a self-hosted chat/RAG layer). I’m not selling the fantasy that this magically matches frontier ChatGPT or Gemini quality. What does change is control: where the data lives, which model you use (API or local with Ollama), and what stays inside your network.

That’s the point: information sovereignty isn’t a poster on the wall. It’s choosing the perimeter. And privacy isn’t a marketing checkbox — it’s architecture.

7. The comfort toll

Self-hosting has a real cost: backups, updates, TLS, not exposing services recklessly, documentation. SaaS sells comfort. You trade that comfort for technical judgment and for not handing inventories, secrets, or AI conversations to a third party by default.

In 2026, even the European Union frames open source as part of technological sovereignty — not merely license savings. I hit that lesson earlier, out of necessity, in a school with physical servers and little budget. The rest was consistency: Linux, protocols, Docker, and the discipline of sharing what’s reusable without leaking secrets.

If you’re starting, look at the repo. There are Compose files for tools I’ve been testing, with Portainer as the on-ramp. Start small. Break things at home, not in someone else’s production. And ask yourself, seriously, one question:

How much comfort are you willing to pay for — with your data?