If you’re reading this, you might have arrived here via owencampbell.me.uk, or perhaps through owencampbell.eth.limo, or maybe even owencampbell.bzz.link. The same website, accessible through multiple different addresses. Why? It’s all about resilience.
We’ve all experienced it: a website goes down because the hosting company had an outage. A service you rely on shuts down with little notice. GitHub goes offline and suddenly half the internet’s documentation is inaccessible. Twitter decides to rebrand and change its APIs, breaking countless integrations.
When you host something on a single platform, you’re making a bet that the platform will:
That’s a lot of trust to place in one organisation.
This website takes a different approach. Instead of choosing one platform and hoping for the best, it’s deployed to multiple platforms simultaneously:
Traditional hosting:
owencampbell.me.uk.Decentralised networks:
owencampbell.eth.limo or owencampbell.bzz.link.If GitHub has an outage, the Swarm version remains accessible. If Swarm gateways have issues, the GitHub version is still there. No single point of failure.
The website’s source code follows the same philosophy. It lives in two places:
Centralised:
Decentralised:
Radicle is particularly interesting because it means the code isn’t dependent on any single company or server. Any Radicle node can host and serve the repository. Even if GitHub disappeared tomorrow, the code would remain accessible through the Radicle network.
I’m also using Radicle CI , a continuous integration system designed for Radicle repositories, to automatically deploy the site to swarm when changes are pushed to the Radicle network.
You might have noticed I keep using the word “decentralised.” If you’re not familiar with the concept, here’s the simple version:
Centralised (traditional): Your content lives on one company’s servers. If that company has problems, your content has problems.
Decentralised: Your content is distributed across many independent computers. No single entity controls it. If some nodes go offline, others keep serving your content.
Think of it like the difference between:
You might be thinking: “GitHub is huge and reliable. Why bother with alternatives?”
That’s fair. But consider:
No company is immune to outages - Even the biggest tech companies have downtime.
Policies change - Platforms can change their terms of service, pricing, or even shut down entirely. Remember Google Reader? Or the countless services that have disappeared over the years?
Accessibility varies - Some countries or networks might block access to certain platforms. Having multiple access points means more people can reach your content.
Control matters - When you depend on a single platform, you’re subject to their rules and decisions. Diversification gives you more independence.
The technology is ready - Decentralised alternatives have matured to the point where they’re practical to use, not just theoretical.
I won’t pretend this approach is zero-effort. Setting up deployment to multiple platforms takes more initial work than choosing one. Maintaining multiple deployment pipelines requires some ongoing attention.
But the actual deployment is automated. Push to the repository at Github, and GitHub Actions handles the GitHub Pages deployment; Push to radicle and separate process uploads the built site to Swarm. The incremental effort for each update is minimal.
The Swarm deployment does have a real cost - you need to pay for “postage stamps” to store content on the network. Currently this costs a small amount of BZZ tokens (Swarm’s native cryptocurrency). For a personal website, we’re talking about the cost of a few cups of coffee per year.
All the gateway URLs should show you the same website:
The fact that you can access the same content through multiple independent routes means that no single organisation can make this website disappear.
This isn’t just about my personal website. It’s about exploring what’s possible when we build with resilience in mind.
The internet was designed to be decentralised - to route around damage and censorship. Over the decades, we’ve gradually centralised more and more onto a few major platforms. Projects like Radicle and Swarm are part of a movement to remember those original ideals and build tools that embody them.
Whether these specific technologies become mainstream or fade away, the principle remains valuable: important content deserves to be accessible through multiple independent channels.
You don’t need to use blockchain or Web3 buzzwords to appreciate the value of not putting all your eggs in one basket.
If you’re interested in exploring these technologies:
The source code for this website is available on both GitHub and Radicle . Feel free to explore how it’s all set up.