This thing started with an email from Google. “You’ve used 90% of storage,” it said. Now, it was not the first time receiving a similar email. I was using Google’s free tier (15GB) for my Gmail data and Google Photos¹, which fills up pretty quickly. When that happened, I would normally sieve through my data and remove the chunkiest videos and files to free up some space. However, that was not a great solution long term.

The cheapest Google One plan costs around £2 a month and gives you 100GB, which should have been enough at least for a couple of years. However, apart from the limited storage, depending on Google for my personal photos made me uneasy. Since they pulled the rug on the free storage, they could easily increase prices at will or stop the service altogether if they wanted to. And then there was privacy.

The solution I chose was to build a personal server I could use to host my photos.

Hardware setup

A personal server is nothing more than a computer you can access remotely. So the first thing you need is a computer.

Luckily, I had recently got my hands on a Raspberry Pi 5 with 8GB of memory. I had used Raspberry Pis in the past, and they are great. I used the Raspberry Pi because I already had it, and I knew I could repurpose it for something else if I wanted.

That said, if I did not have one, I might have considered buying a second-hand mini PC instead. Overall, it’s a more cost-effective solution in this case. You can buy a decent second-hand mini PC very cheap on eBay and get a computer with better specs than the Pi, including NVMe storage. If you opt for the Pi, you will need to buy a case and storage separately.

To be fair, I have taken the server with me multiple times while travelling, and the small size and weight are great for that. I also splurged on a fancy aluminium case and SSD storage. All in, the value of my setup is a whopping £177.

Setup

Orchestration: Docker

Before we discuss the networking setup, this section discusses the orchestration setup that the server uses to run multiple micro-services at once.

The architecture of the server is based on Docker containers, which host the individual services. Docker compose is used to orchestrate the containers and provision bridge networks to provide internal communications.

Docker compose is great, and it has the advantage that most open source self-hosted services provide docker compose files that you can copy into your project.

.
├── scripts
│   ├── up.sh // starts all the docker services and bridge network
│   └── down.sh // stops all the services
└──services
    ├── service1
    │   ├── .env
    │   ├── docker-compose.yml
    │   ├── docker-compose.override.yml
    │   └── <service-specific dirs>
    ├── service2
    └── ...

Networking: Cloudflare Tunnel

We use an external docker compose bridge network to manage communications between different micro-services. The next step is to expose the services externally, to the public internet.

To safely expose the services publicly, I use Cloudflare Tunnel. The benefits are:

• Safe architecture, you are not exposing ports to the open internet
• Easy setup and maintenance, leveraging the Cloudflare dashboard.
• No router setup needed; I can take my tiny server to a new place, connect it to the local network, and it will work again.

The drawback is that you need to obtain a domain, which you can also do in the Cloudflare platform. The cost is quite low (you can find domains for less than £7/year), but it does mean that you have to set up a payment method.

Reverse proxy and encryption: SWAG

SWAG is a Docker image that makes the process of serving encrypted docker services very easy. As explained in the documentation, it manages the communications with all your other services and exposes them through a single encrypted port. To do that it uses

• nginx as a reverse proxy, to route each service to its appropriate subdomain/subdirectory.
• Let's Encrypt for generation and renewal of TSL certificates. SWAG also supports ZeroSSL as a certificate provider.

Additionally, SWAG works with Cloudflare Tunnel ; meaning that the SWAG service is capable of managing the full deployment.

Authentication: Authentik

Some services might have built-in user authentication, others might not. In any case, I wanted a way to unify all the services under a single sign-on system. Authentik is an open source service that does just that. You can configure Authentik to manage the authentication to all the micro-services, allowing you to control who uses them. It also allows users to use Google credentials for authentication, so there is no need for new usernames and passwords. The official documentation explains how to install Authentik using docker compose here.

Other Services

After all this, the web server is ready to host fantastic micro-services. Some of the ones I have installed are:

You can discover new self-hosted apps at:

• awesome-selfhosted
• selfh.st

Summary Diagram