80, 443 for HTTP/S, and 587 for a VPN service. Reason being that I travel frequently, and often have to connect through a bunch of different networks, Airport WiFi, mobile roaming, hotel WiFi, etc. and you never know the kinds of network restrictions they impose on their pipes.
80 and 443 is least likely to be dropped, while 587 is a common SMTP port that could make it through most networks.
I’m running all my microservices on a couple of repurposed NUC5i5RYKs, running Ubuntu Server 22.04 (I know I know) and Docker. They’ve been absolutely rock steady thus far, though not quite as overkill as I like all my computers to be. But I got them in 2015 and they’ve held up more than admirably.
I have found my kin here I see.
Greek god names, Mission code names, uncommon colors, famous mountains, depending on the type of devices. I must have a hundred different ones by now.
Thanks for that! Reading through the Lemmy docs gave me some head-scratching moments too. However, I’m more than grateful to the creators and its a monumental undertaking, so I give them a huge deal of credit.
If you have any tips or suggestions on how to host it better on Docker, let me know too, always happy to tweak and improve my setup and learn as I go along.
Cheers, took me a few attempts (gave up a couple of times early on, but came back determined to finish this) to get it up and running. Let me know how it goes and if this works.
+1 for this, I have an active subscription with Bitwarden, for US$10 a year it’s worth many times that in the value and utility it provides me. I considered self-hosting the service but I decided to just stick with the cloud version since they likely have better resilience than my homelab. It’d suck if my home network is down for whatever reason and I need urgent access to my vault without a local copy within reach.
I haven’t had the deployment use case to get into k8s, but it is always something on my bucket list to pick up. I’d try my hand at it when the opportunity arises. There’s not much to go on but some google-fu turned out this guide: https://codeberg.org/jlh/lemmy-k8s, seems to be fairly digestable on first look.
See the Problem Statement section.
Thanks for asking! I think this is more or less an architectural choice, and I was vaguely adhering to the microservice design philosophy. While spinning up duplicate services for each container that requires it has its advantages in terms of isolation and what not, I wanted to:
Hence, all of my docker containers are deduped and reused whenever possible, and follow my own notations and conventions, as well as static and opiniated networking. It has been a really fun journey so far, but I’m also a glutton for punishment and sleep-less nights ;p
Interesting! I didn’t quite see that line about the postgres password and pictrs API key having to match. So far, I haven’t had issues with my instance with them being different values.
If Lemmy really assume by convention that the postgres password and the pictrs key must be the same, it sounds like a huge architectural WTF and massive security risk, so I assume it shouldn’t be.
For postgres versions, my solution would be to host different postgres versions in their own containers if there’s no other elegant way to avoid it. Then the URI should point to the respective postgres containers as necessary.
Hey buddy, happy to help! You certainly can, you’ll just have to generate an app password for your Google account, it’s pretty simple and guide here (https://support.google.com/accounts/answer/185833?hl=en) is easy to follow.
A quick note if you haven’t done it before, the app password is generated in place of your actual Google account password. It is intended for single-app use, and bypasses multi-factor authentication on your Google account.