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
I don't have a particular guide to reocmmend, but assuming you have a VPS already, you'll basically need just a few components:
That should basically do what you need. The reverse proxy will see the domain (https://whatever.example.com) and pass it on to the machine on your local network (e.g. 192.168.1.111:8888) via a VPN connection (which will push the routes so the VPS knows how to get to your local network).
So here is a question: does it need to be a sub domain? Can't I redirect all traffic to the VPS? If I wanted to host a HTML website at my root domain and have it served by nginx for example, couldn't I do that?
I just see subdomain mentioned in the guides / tools I see but I don't understand why exactly.
Doesn’t have to be a subdomain, but just good practice for hostnames to be a subdomain because hostnames generally represents a named server (subdomain) within an organization (domain). Also it makes things easier if you add additional servers in the future to just assign another hostname to the new server.
I usually do:
domain.ext
- leave open, not used.servername.domain.ext
- A records in DNS pointing to servers’ public addresses; (i.e.servera.domain.ext. A 10.0.0.123
;serverb.domain.ext. A 10.0.0.234
; etc.)service.domain.ext
- CNAME to the server it is on (i.e.auth.domain.ext. CNAME servera.domain.ext
This way it is super quick for me to move entire server to different provider (update A record) or move service to another server (update CNAME record) when I need to shuffle things around.
If you’re running a public facing website, you could always CNAME your
www
and@
(or whatever your DNS provider uses to represent root domain) to your server specific A record entry.It's funny, when you explain it, my IT hat goes on and I totally get it lol. I guess the context felt different enough that I didn't get it. But I work with Windows domains all day and that's exactly how DNS operates in that environment.
Ultimately I think for a tunnel you'll end up with your records pointing to your VPS. So you'll have a
*.domain.tld
CNAME record and maybe a @ CNAME record and your nginx server on the other end of the tunnel would handle the routing.