I found Nginx Proxy Manager to be the easiest to configure when I was starting out my homelab! I think the GUI played a big part in that, but it’s also just pure NGINX under the hood, so when you get more comfortable with the concepts, you could easily transition to that for even lower overhead (welp, I just had a look at my docker stats, NPM is sitting at 3.2 MB of ram with ~10 proxy hosts, not sure how necessary that even is…)

Please correct me if I’m wrong, but here’s what I think the situation is:

• you have two different sevices that you have domains for, e.g. lemmy and bitwarden.
• you have two domains, lets call them lemmy.com and bitwarden.com .
• you have one (public?) IP address. let’s call that 123.123.123.123 .
• you want to use this IP address for both domains (e.g. bitwarden.alpha.com and lemmy.beta.com)

In that case you need both domains to connect to the same computer (because that’s the one with that IP address) which routes it to the correct location (either on the same computer or on a different one).

You basically have two solutions (that you already mentioned)

1. single machine

• You run both services on a single machine, listening on different ports on localhost/127.0.0.1 .
  • lemmy listens on port 1234 and bitwarden on port 8080.
• You use nginx (or caddy/apache) to listen on the web ports (80, 443) and reverse proxy(!) the content.
  • if the domain is lemmy.com it proxies from localhost:1234
  • if the domain is bitwarden.com it proxies from localhost:8080 This is the easiest solution IMO.

2. different machines.

This is essentially the same, but instead of the services running locally, one or both run on different machines.

• you run both services on different machines
  • lemmy on 10.0.0.10:1234
  • bitwarden on 10.0.0.20:8080
• You use nginx again as reverse-proxy(!):
  • if the domain is lemmy.com it proxies from 10.0.0.10:1234
  • if the domain is bitwarden.com it proxies from 10.0.0.20:8080
• be sure to check the firewall settings of the machines, that allow it.

In both cases the IP address points to the machine running nginx.

If you can run both services on the same machine with docker, you should just use this: https://github.com/nginx-proxy/nginx-proxy

Cloudflare tunnel free is pretty good, and I use it for my on-prem (in house) services because it can work through CGNAT, though you are subject to the standard cloudflare terms of use.

On the other hand, what you’re looking for is called a reverse proxy. I’d recommend Caddy or Nginx Proxy Manager for you.

I personally use Traefik, but I’m also running on a kubernetes cluster so…

The setup for my home network is:

• caddy
• tailscale
• PiHole

I have several machines running different services.
Tailscale is in each one of them with the MagicDNS setting pointing to the tail IP of the PiHole.

In the PiHole’s DNS I have my different addresses pointing to the machine running caddy (for jellyfin, for PiHole itself, for each of the projects I sometimes run)
(this will be replaced by your domains pointing to your public IP where you’ll be running caddy).

Now in the CaddyFile you’ll have something like this

jellyfin.pe1uca.local {
    reverse_proxy <service_tail_ip>:<port>
} 

pihole.pe1uca.local {
    reverse_proxy <service_tail_ip>:<port>
} 

And the rest of your services in the same way.

LOL… it’ll be easy, I tell ya!

So I dove in this afternoon, thinking I had all the info I needed to easily get a setup w0rking… I changed my port forwards to the domain2.com machine - the one running apache2 on a webiste; leaving the bitwarden.domain1.com not seeing traffic. Then, I created a new virtual host file on the domain2.com machine;

cat bitwarden.domain1.com.conf

<VirtualHost *:80>

    ServerName bitwarden.domain1.com

    ProxyPass / http://10.0.0.155/ nocanon

    ProxyPassReverse / http://10.0.0.155/

    ServerAdmin paulie420@domain1.com

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

RewriteEngine on

RewriteCond %{SERVER_NAME} =bitwarden.domain1.com

RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

</VirtualHost>

And ran certbot to get https certs - certification would only be on the domain2.com machine; all proxied data would be sent over http, but I figured that was OK as its just me accessing the domain1.com service.

BUT alas, the setup didn’t work; I have some suspicions… bitwarden is running inside a docker container, so… I dunno if that has something to do with how its listening, and its running nginx; what I thought was that apache2 would simply send all traffic from the bitwarden.domain1.com domain over to my local IP 10.0.0.155 machine and that machine would just pick it up simple pimple and display to the user going to that domain. Another thought - maybe its because Docker/Bitwarden HAS https in that container - ohhhh, thats a thought; however it still didn’t function correctly before I ran certbot on the domain2.com setup.

UGH… more to come - I’m trying options. :/ Grrrrrr. :P

PS; posting code in Lemmy doesn’t work so great, does it? I used a backtick but didn’t get the results I’m accustomed to…

Thanks for the three replies so far; BTW, Lemmy is beating out /r/eddit on this thread!!! :P

Yea, I know that I’m needing a reverse proxy - it was just how to implement one since the two sites aren’t using the same host software; apache2 and nginx… so I think I should run a 3rd VM and route the traffic out to the other 2 local IPs; OR condense the two sites into one VM - which I don’t really want to do…

Or, maybe I pick a [free, paid if needed] Cloudflare tunnel for the lesser used site - and only have to forward to one VM from my IP.

I guess one more solution would be switching the apache2 over to nginx - can I route to a separate local IP from nginx reverse proxies??? Will research…

Thanks for thinking this thru with me - and I’ll keep checking back for other suggestions. :P Appreciated!

Alright, I wanted to come back now that my setup is complete… special thanks to those of you who suggested nginx-proxy-manager - its very nicely put together and really makes reverse proxies a breeze…

Long story short, I just created a brand new VM… started with the proxy manager and built on top of that. Next up was my static Hugo website; it was too easy to point change Apache2’s ports.conf to 8097 instead of 80, and use nginx-proxy-manager for the SSL certs… that one was basically plug and play.

The Bitwarden bit was a bit more involved, but not too bad… at first I just redirected traffic to the original (other machine) Bitwarden VM - but no one wants an extra VM to backup and support… so I went with a fork Docker of bitwarden_rs/vaultmaster - it comes w/ e-mail setup in the container, so one less thing to worry about… I had to swap around some docker-compose.yml ports and just point nginx-proxy-manager at it… this time, tho, I used the SSL certs from the docker; I didn’t wanna dig in and remove what they already had running.

In the middle I was still fighting with myself and not taking ya’lls good suggestions - I tried to go the Cloudflared route; which is a cool service… but you can’t tunnel root domains unless you’re a paid user. Cloudflared tunnels would be great for exposing the Plex, TrueNAS, etc’s of the world… but I didn’t NEED/want subnets.

Thanks to the Beehaw community… TechHeart.life is up and running. :P (Don’t worry, the Bitwarden is on a private domain. Phhhbbbbtttt.)

Everyone here is awesome for ALL the replies. :P Thank you!!

I decided to try a Cloudflared tunnel, but that didn’t work out because I can’t get the main domain1.com domain to go thru the tunnel… only ‘apps’, like blog.domain1.com. :P

And, I’m still ironing out how to pass nginx to another local IP on my network; I just haven’t gotten it to click yet. All the info needed is right here - I promise to come back when I iron out the setup and post how I managed to do it…

I can figure out how to pass nginx [or apache2, for that matter] to another PORT on the same local IP - I think I have both domains listening on ports 80/443 - and I’ll have to change that in order to route the data correctly… let alone getting out to another local IP.

Again appreciate all the info - sometimes I just have to learn a bit more since I have all the documents right here. :P