What self-hosting taught me about data protection

Self-hosting your own infrastructure is one of the more direct ways a data protection professional can close the gap between what they preach and what they actually understand. Running your own servers forces you to get your hands dirty. You’ll engage with data flows, attack surfaces, and accountability in a way that writing policy documents alone never will. It’s been a little over a year since I started my homelab journey and 7 years since I began to migrate away from bigtech by self-hosting with a European hosting partner. Things have significantly moved on since then and now it’s time for an update of why I built it, what I learned, and why I think it matters professionally.

Why I built it #

As a one-person consultancy I assist companies through managing or supporting their projects, educating and training their teams - ultimately, on how to handle data responsibly. That means (in simple terms) knowing where data lives, how it moves between systems, who can access it, and what happens when something goes wrong.

I think the truth is that if you are doing that work, you need to understand what it looks like from the inside, and not theoretically.

So a year ago, I made a decision to build something that’s fit for my purpose. Everything runs on European infrastructure. There is virtually no dependency on US bigtech platforms. All my services are now self-hosted, self-managed, and under my direct personal control.

What the infrastructure looks like #

The setup has four layers, each with a distinct role.

Compute and storage is the primary server. It handles the bulk of self-hosted services such as media, analytics, automation, a course platform, archiving, and more. Local backups go to an attached external drive. Every night a scheduled sync pushes critical data to offsite cloud storage. All my devices sit behind a UPS (Uninterruptible Power Supply), because uptime is not just a technical preference, it is a critical professional requirement.

Secondary services run on a separate, lighter server. newsletter, scheduling, uptime monitoring, productivity utilities. Keeping these on a distinct machine means they do not compete for resources with the primary and can be maintained independently. A separate failure domain and a separate concern.

Security and intelligence is a dedicated machine with no public-facing role at all. It watches everything else. It runs centralised log analysis and threat detection, a coordinated blocking system that all machines in the network report into, and a local AI model for on-premise inference. No data leaves the network to answer a question.

All three machines are joined by a private encrypted mesh. They communicate securely with each other and with the primary workstation regardless of physical location.

The hardened public endpoint sits in a European cloud and is deliberately thin. A reverse proxy routes traffic to my three hosted websites and public-facing services, hardened with layered firewall rules and automated threat response at the edge. No significant data lives there. It is a secure gateway and nothing more.

Taken together: compute and storage, secondary services, security and intelligence, and a hardened public endpoint - all connected privately, all on European infrastructure, with little dependency on US bigtech platforms.

When the infrastructure was tested #

Over the past month, my monitoring tool notified me of a hardware fault in the primary server. After diagnosis and dialogue with the supplier, I had to replace the server. This was a major lesson learned about hardware choices and supplier selection. Fortunately it was covered by warranty and the impact was minor.

It was minor because I had designed such eventualities into my setup - because separation of concerns had been built in from the beginning. Services were distributed across machines with distinct roles, so the failure of one did not cascade into the others. It was minor because the offsite backup and restore process had been tested long before the failure occurred — not as a theoretical exercise, but as a real rehearsal that had already worked. When the incident occurred, I already knew the process I had designed and tested. So recovery was methodical. A hardware swap, not a crisis.

The lesson is straightforward: resilience is not what you have in place when something goes wrong. It is what you verified before anything went wrong.

What running this actually teaches you #

As mentioned earlier, I’m a one-man band so this is a one-person setup.

Every monitoring tool, every dashboard, every alert threshold was configured by the same pair of hands, i.e. mine, that configured the servers. That creates a particular kind of obligation. You cannot just install something that produces pretty charts and columns of numbers. You have to understand what the numbers mean. You have to know what a healthy reading looks like, what a warning looks like, and — most critically — how to respond.

This has been a massive learning exercise for me and coupled with my current masters studies in Advanced Digital Technologies for Business, in particular the module ‘Cloud Computing’ I really have a greater understanding of the complexities global companies need to deal with - and I’m just scratching the surface with my setup.

Having a local AI model within the infrastructure changes what is achievable alone. Complex diagnostics, unfamiliar log patterns, trade-offs without obvious right answers — these can be worked through without relying on external services and without data leaving the network. For a one-person operation, that changes what is practically possible.

This matters a lot beyond the technical. Dashboards and monitoring tools give you a continuous stream of signals. Learning to read those signals — and to respond proportionately — is directly transferable to how I work with companies on incident detection, response planning, and security posture.

About 10 years ago I published the following animation in a LinkedIn post to illustrate the different phases of the data life-cycle and the kinds of questions to ask yourself at each phase.

These days, with modern integrated architectures, the life-cycle is inherently more complex and you need to ask yourself many more questions. The following diagram is a simple representation of this. Fortunately my setup is not this complex but what I have in my setup is an ongoing learning experience.

The professional case #

Data protection as a discipline is not just about knowing the rules. It is about understanding what the rules are actually asking for in practice.

Where is data held? How does it move between systems? What does the real attack surface look like? What does it mean to be genuinely responsible for infrastructure, rather than simply dependent on someone else’s?

These are questions the rules ask. Self-hosting answers them directly.

I have seen other data protection professionals (including the larger consultancies and especially law firms) struggle to bring their own websites and online presence into line with the requirements they advise clients on. Often because they are dependent on hosting providers over whom they have limited practical control — and because the gap between knowing the requirement and understanding its implications is wider than it looks from the outside.

Self-hosting removes many of those dependencies. Individually you must take ownership and demonstrate accountability.

If my one-person setup were scaled to a global company, the complexity would be enormous — multiple jurisdictions, teams, vendors, regulatory frameworks, decisions made by people who may no longer be in the company. I am fully aware that this kind of complexity is the reality many companies face. But the underlying principles are the same. Having worked through them at this scale makes the larger picture considerably easier to read.

The infrastructure described here is, in that sense, both the practice and the education. It is a working system — and a continuing argument for understanding, from the inside, what you are asking others to do.

To conclude, in this this past year I have reduced my dependency on bigtech, reduced personal data protection risk, reduced costs (my business case for hardware investment versus reduced licence fees) and have significantly increased my knowledge. It’s also given me the competences and confidence to launch Field Talk - more on that to come.

Frequently asked questions #

What is self-hosted infrastructure in a data protection context? Self-hosted infrastructure means running your own servers rather than relying on third-party cloud platforms. From a data protection perspective, it gives you direct control over where data is stored, how it is processed, and who can access it — rather than delegating those decisions to a vendor whose practices you may have limited visibility over.

Why does self-hosting matter for data protection professionals? GDPR places primary accountability on the controller, not the processor. Understanding what that accountability means in practice requires understanding how infrastructure actually works: data flows, access controls, backup and recovery, incident detection. Self-hosting provides hands-on experience of all of these. It also removes dependencies on US-based cloud providers — a live compliance issue and hot topic with all the ongoing regulatory scrutiny of global data transfers.

How do you maintain security on a self-hosted setup without a dedicated IT team? Layered architecture is the key. Separating services across machines with distinct roles means no single failure point brings everything down. Centralised log analysis, coordinated threat blocking across all machines, automated alerting, and regularly tested backups create a proportionate posture for a small operation. The critical discipline is verifying your recovery process before you need it, not after.

What does European infrastructure sovereignty mean in practice? It means hosting on infrastructure physically located within the EU, with providers subject to EU law, and avoiding dependencies on platforms based in jurisdictions that may compel data access under their own national laws. In practice: EU-based hosting providers, open-source software where possible, and direct control over encryption keys and data flows.