Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
So a reverse proxy is sort of like a phonebook or directory, it routes outside requests to the appropriate place. So imagine your reverse proxy is a receptionist, someone comes in and says "hey I am looking for plex.mydomain.com" the receptionist would then use the phonebook and say "ok if you are looking for plex.mydomain.com, go to building 192.168.1.10 (the ip), room 9000 (the port)"
Since you are asking about dockerized services, the networking for those can be done in several different ways, but the one thing that really matters is that each service needs to have a unique combination of ip and port, because only 1 service can live at each address. With docker, you could set up multiple services that use the host server's ip, in which case each container will need to be on different ports, or you could have it so each container has its own ip, in which case the port can be anything.
This makes it clearer to my, would you mind helping me to understand all steps for my usecase. I want to run a lemmy instance and a mastodon instance on the same VPS, using the same domain but different subdomains - lmy.my-domain.tld and mstdn.my-domain.tld. I have my VPS IP address and setup the 2 subdomains with my domain provider (both subdomains are resolving the same IP).
I also did setup nginx on my server and can install SSL certificates for both of these domains. I'm now at the step where lmy.my-domain.tld should by directed to the lemmy service and mstdn.my-domain.tld to the mastodon service. As I understand it, both services listen to the ports 80 (http) and 443 (https). Do I now setup a room/building for Lemmy / Mastodon respectively where I tell nginx that lmy.my-domain.tld is at 0.0.0.0:3001 and mstdn.my-domain.tld is at 0.0.0.0:3002 for example. And in the config files for each of these installs I'd specify "0.0.0.0:300x" respectivly? (also have to make sure, that these docker installs don't mess with my nginx config by themselves, right?)
It sounds like what you need to do at this point is find what IP address your lemmy instance and mastodon instance containers are using on your VPS. you can do "docker inspect containername" and look for the IP address in there. it might be something like 172.16.0.1 for lemmy and 172.17.0.1 for mastodon. then you want to set up your reverse proxy to point lmy.my-domain.tld to 172.16.0.1:80 (or whatever port you set lemmy to use) and then mstdn.my-domain.tld to point to 172.17.0.1:80 (again, port might be different, i dont know what the default port is)
-IF- both of the containers are using the same IP, then you will need to make sure that they are using different ports. if they are on the same ip and same port, whichever container loads 2nd will fail to properly load, because when a port is taken on an IP address, it is reserved and nothing else can try to listen on that port.