I don’t know how many times I have to say this: selfhosting is about more than saving money.

In other words, sometimes paying for a service you could selfhost is the right call. In most cases, if you can manage a self-hosting setup, your time is worth more than the cost of cloud services. TBH, I do it for data governance reasons more than cost.

It’s not either/or and it’s not about going “off-grid” for a lot of people.

I mean, snapshotting and piping it to an rclone mount is arguably simpler than trying to do your own ad hoc file syncronization, also does not require 2x the storage space.

TBH, I don’t think Software Engineering, especially just 2 years of experience, is going to really help you understand network architectures/distributed systems. You can probably build some small apps, but designing larger systems is a skill that requires intentional practice.

The best thing you can do is figure out how to containerize the stuff you want to run and store the configurations in source control. Figure out how to isolate your data and back it up, and then experiment with configuration changes to see how they change system behavior.

A few specific things to learn/practice.

• Learn how to break down a larger problem into distinct components with specific responsibilities.
• Learn about docker, what problem it solves.
• Learn how to experiment with the tools to find out what they can do, and how you can configure their behavior (docker is very helpful here, because you can spin up a temporary sandbox to figure things out without risk of breaking a “live” system).

This is basically my config:

wireguard:
    container_name: wireguard
    image: weejewel/wg-easy
    volumes:
      - ./data/wiregaurd:/etc/wireguard
    environment:
      - WG_DEFAULT_DNS=192.168.10.3
      - WG_HOST=public.example.com
    env_file:
      - ./env/wg-easy.secrets
    ports:
      - 51820:51820/udp
      - 51820:51820/tcp
    expose:
      - 51821
    restart: always
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    depends_on:
      - pihole
    sysctls:
      - net.ipv4.ip_forward=1
      - net.ipv4.conf.all.src_valid_mark=1

In my case, I reverse proxy port 51821 through caddy to configure clients (with Authelia in front of it), but you could expose it interally only if you want to prevent that interface from being publicly accessible.

Note that public.example.com needs to be replaced with your connection’s public dns hostname (you can use something like duckdns for this if you want), and that you need to expose 51820 on your firewall/router. In my example above, 192.168.10.3 is the IP for pihole, and resolves some internal hostnames. You should look over the config provided once you set up a client and make sure it uses accessible hostnames, etc.

I don’t think there’s any specific reason to worry about using cloudflare tunnels over any other VPN solution, and if your connection uses NATCG, you might actually need something that tunnels out to a central hub.

Contabo

I just checked because I hadn’t heard of this one, it’s priced at about $11/TB-mo, so it’s about as competitive as B2.

One thing about using Prometheus alerting is that it’s one less link in the chain that can break, and you can also keep your alerting configs in source control. So it’s a little less “click-ops,” but easier to reproduce if you need to rebuild it at a later date.