I’m not really sure how to ask this because my knowledge is pretty limited. Any basic answers or links will be much appreciated.
I have a number of self hosted services on my home PC. I’d like to be able to access them safely over the public Internet. There are a couple of reasons for this. There is an online calendar scheduling service I would like to have access to my caldav/carddav setup. I’d also like to set up Nextcloud, which seems more or less require https. I am using http connections secured through Tailscale at the moment.
I own a domain through an old Squarespace account that I would like to use. I currently have zero knowledge or understanding of how to route my self hosted services through the domain that I own, or even if that’s the correct way to set it up. Is there a guide that explains step by step for beginners how to access my home setup through the domain that I own? Should I move the domain from Squarespace to another provider that is better equipped for this type of setup?
Is this a bad idea for someone without much experience in networking in general?
You must log in or register to comment.
Exposing services over the public internet is not without risks, you might consider getting more knowledge before doing it
Every service you expose should require authentication and may need to handle bots
To gain knowledge about reverse proxies and dns without much risk exposure, you could start by setting up your custom domain name on your private tailscale network, here is an example of how you could do it
Now if you really want to expose services on the internet because you have devices that you don’t want to connect to your tailscale network, you could use tailscale funnel, but only with your ts.net custom subdomain that they provide you, not with your own domain
There is an open issue to support custom domains https://github.com/tailscale/tailscale/issues/11563
I’m waiting for this to get resolved, in the meantime I have a vps with a reverse proxy connected to a tailscale container, that serves my services from my home network, so that I dont need a static IP or open a port in my home router
- Consider getting a VPS to play around with to learn how this stuff works before you expose your data to the internet.
- Learn about how DNS works. You will create an A record (and possibly also an AAAA recordy) for your domain pointing to your home IP (or VPS).
- If SquareSpace does not let you set records (and will only allow you to use Squarespace-hosted services) you will need to migrate your domain to another provider. I like gandi.net.
- Learn how your router does port forwarding. You will forward port(s) for the calendar service from your router to your home PC. (Or learn how to do firewalls on your VPS.)
- Before you actually connect to it with credentials over the internet, set up SSL/TLS certificates with LetsEncrypt.
The educational route I took was Hurricane Electric’s free IPv6 online course. It taught me a bunch of networking principles. When you finish the course (and get “sage” status), you get free lifetime DNS access. This includes dynamic DNS that automatically updates when your IP address changes.
Because of this, I can self-host on a basic residential plan without paying for any additional services.
Oooo this might be the path I take to finally get off IPv4. Cheers. I’ve already set up reverse proxies, but finally updating to 1999 technology seems like a good plan.
The easiest way to do this is through Tailscale. It is a super easy to set up Wireguard VPN Mesh that allows you to access your self-hosted services without exposing them to the public internet.
Here is a great article to get you started: https://tailscale.com/kb/1017/install
They also have an awesome YouTube channel with great tutorials to help you get started. https://www.youtube.com/@Tailscale
Note: while this way not directly answer OP’s specific question, I believe they will get the outcome they are looking for: external access to self-hosted services
Caddy with caddyfile is very easy although it lacks a gui. Use nginx proxy manager if you want a gui, but it is more work than a caddyfile.
Seconding Caddy – It’s as close to it gets for “Just works”. It handles all the certs, it’s easy to refresh and add a subdomain instantly, handles wildcard domains, and the config file is dead simple to understand.
You can use https://xcaddy.tech/ to build Caddy with various plugins, I use mine with transform-encoder so that logs can be made compatible with fail2ban.
I wish I would understand how to use xcaddy but I failed the last two times setting it up 😅 it was something about another language (go?) that was needed iirc
https://caddyserver.com/download
Use this if xcaddy is too much.
Select your platform, then just click the little boxes next to the modules you want included, then hit the download button
Tailscale the end.
We all got to learn somewhere!
Lot of good advice here, but sometimes people forget what it’s like to be a beginner. Since you don’t know what you’re doing, I would recommend not trying to host things on your home server and access it from the outside world. That usually involves port forwarding on your router, and that comes with a lot of risks, especially if you don’t know what you’re doing. Others have mentioned it, but a better option when you’re starting off is to rent a vps and host your software there.
Squarespace might work, but my guess is it’ll be easier to transfer your domain elsewhere. You can follow guides for that online and it’s pretty straightforward.
Having a vps, a domain name, you’re most of the way there. On your vps, you’ll want to install a reverse proxy, which is what routes incoming urls to the right place (nextcloud.domain.tld goes here, calendar.domain.tld goes there).
Docker is another thing I’d recommend learning as a lot of what you’ll self host will likely be in a Docker container. I’d watch a few YouTube videos to see how it’s done. This channel has some great videos, and there are others out there.
It seems like a lot, but learn a little here and there and don’t expect to have this all working overnight. You’ll get there!
Love docker. Updating has never been easier.
I actually wanted to ask about that… Is it considered best practice to run a bunch of different compose files, and update them all separately? Or do you just throw all of them into a single compose file, and refresh the entire stack when updating?
The latter definitely seems like it would be more streamlined in terms of updating, but could potentially run into issues as images change. It also feels like it would result in a bunch of excess pulls. Maybe only two images out of a dozen need to be updated, but you just pulled your entire stack. Maybe you want to stay on a specific version of one container, while updating all the others. Sure you could go edit the version number in the compose, but that means actually remembering to edit the compose before you update.
