HTTP Virtual Host

Coming from a freelance web developer background, the HTTP Virtual Host feature of the rXg was the first thing that really floored me. A lot of my prior work had do do with getting my clients' sites working on docker -based platforms like Heroku, and eventually hosting environments of my own creation and specification.

This feature allows any number of distinct domains to be hosted behind the rXg. Setting up one domain is as simple as configuring one record. This helps keep things simple for me: 1 vhost = 1 service = 1 domain = 1 certificate.

As usual, if you want to scale up, there are complications. I believe that if you leveraged both the Lets Encrypt and ZeroSSL integrations then you would be able to maintain certificates for at least n > 100 domains which is more than most people will ever need.

Please note these important attributes:

Name

It's good to give it a descriptive name. I usually use the same string as the hostname.

Hostname for remote access

This is the hostname you will give to other people EG "check out my site ____".

Target Server IP

Your service's actual IP that's reachable from the rXg

Target Listening Port

Your service's actual listening port that's reachable from the rXg

HTTPS

Yes if your service is listening for HTTPS, no if your service is listening for HTTP. If you choose wrong, you will likely get a "bad gateway" error.

Certificate

This is the certificate that is going to be used in conjunction with serving this blog.

Allowed WAN Targets

You can use this to restrict who can access this Virtual Host. This is great for when you have certain Domains that you want to keep private.

Note

Note is just there to help you remember why you configured this the way you did. I highly recommend that you use it.

Certificate Manager

Since the dawn of the internet, getting a working SSL/TLS certificate has been a challenge for many. Stay tuned to find out how easy the rXg makes this!