• 0 Posts
  • 39 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle



  • Any chance you’ve defined the new networks as “internal”? (using docker network create --internal on the CLI or internal: true in your docker-compose.yaml).

    Because the symptoms you’re describing (no connectivity to stuff outside the new network, including the wider Internet) sound exactly like you did, but didn’t realize what that option does…


  • It also means that ALL traffic incoming on a specific port of that VPS can only go to exactly ONE private wireguard peer. You could avoid both of these issues by having the reverse proxy on the VPS (which is why cloudflare works the way it does), but I prefer my https endpoint to be on my own trusted hardware.

    For TLS-based protocols like HTTPS you can run a reverse proxy on the VPS that only looks at the SNI (server name indication) which does not require the private key to be present on the VPS. That way you can run all your HTTPS endpoints on the same port without issue even if the backend server depends on the host name.

    This StackOverflow thread shows how to set that up for a few different reverse proxies.


  • They’ve checked in my code in their own repository, using an automated tool that keeps track of its origin so they can still check for updates. (The build tool knows to check this directory before trying to pull in dependencies from elsewhere)

    One benefit to them is that their build won’t break if I decide to delete that specific repository (see also: the left-pad incident) or do silly things with version tags (deleting versions, or re-tagging a different commit with the same version number, that sort of thing).

    But more relevantly for this thread, it also means that if I release a new version and they upgrade to it, the PR on their repository won’t just be incrementing a version number in go.mod and adding an unreadable hash to go.sum: the diff will show all the changes I’ve made since the version they previously used.