[abound]

This looks truly excellent, nice work! I've been using RideWithGPS, which is a great tool, but doesn't scratch my "self-host everything, own my own data" itch, so I'll definitely be checking this out. I've built (and use daily) my own barebones workout tracker [1], but it's for non-distance-based workouts (i.e. rep-based stuff/lifts), so this compliments that nicely.

[1] https://github.com/bcspragu/stronk

[juiiiced]

How many things do you self host and how do you manage them all?

[abound]

  $ kubectl get deployments.apps | wc -l
  25

Minus the header, looks like ~24. I use a single-node Kubernetes cluster running Talos [1]. Running a single-node cluster is kinda dumb architecturally, but adding a new service takes <10 minutes most of the time, which is nice. I've standardized on Cuelang [2] for my configs, so adding a new service is some DNS/Caddy config fiddling, then:

  deployment: <service>: spec: template: spec: {
   containers: [{
    ports: [...]
    command: [...]
    volumeMounts: [...]
   }]
   volumes: [...]
  }

And then running:

  cue export \
    --out yaml \
    --expression 'deployment.<service>' \
    --expression 'service.<service>' \
    kube.cue <service>/<service>.cue | kubectl apply -f -

Where `kube.cue` sets reasonable defaults (e.g. image is <local registry>/<service>). The "cluster" runs on a mini PC in my basement, and I have a small Digital Ocean VM with a static IP acting as an ingress (networking via Tailscale). Backups to cloud storage with restic, alerting/monitoring with Prometheus/Grafana, Caddy/Tailscale for local ingress.

[1] https://www.talos.dev/

[2] https://cuelang.org/

[reidjs]

Interested in how you're using DO as an ingress. I currently run a droplet that's reaching its capacity because I'm running all the services directly on that underpowered machine. I would much rather run them from a local computer. Is it pretty straightforward to set that kind of thing up with tailscale?

[abound]

Indeed! I use Headscale (though hosted Tailscale will work just fine), DO hosts the controlplane, and is also on the tailnet itself. My Caddy config has something like:

  <list of public hosts> {
    reverse_proxy 100.64.0.<mini PC>
  }

The mini PC IP is a Tailscale container in a pod with a second Caddy instance that routes within the cluster. For sensitive/personal services, they're only configured in the cluster-internal Caddy config, and thus only accessible over the tailnet.

One can optionally add other "hardening" at the DO layer, like Crowdsec, to minimize automated/malicious/bot traffic into your home.