Here are mine for another example:
Also at @me@social.k3can.us on Mastodon.
Here are mine for another example:
Python’s webserver is meant to be a quick option for testing, and shouldn’t be used for a publicly accessible website. You’ll want a proper webserver for that.
You would need access to the router for the port forwarding, so if you can’t access it, you’ll need an alternative option. The next best option is a commercial reverse proxy, most commonly that’s Cloudflare’s “tunnel” product. Essentially, Cloudflare acts as a man-in-the-middle, forwarding from a public address directly to your local server. It’s pretty easy to set up and it takes advantage of common router settings to open ports from the inside, where the router’s firewall rules are typically quite lenient. This also works with CGNAT, so no need to figure that out. The downside is that Cloudflare gets access to all the data that passes through them, even passwords. So if your website happens to have a lot of sensitive data, you’ll need to decide whether you trust them with that data. They do not get access to your normal web browsing or anything, just the data passing between the public address and your local server. Another potential downside is that they prohibit media streaming, so if your website serves a lot of videos, you’ll want a different option.
Google Cloudflare tunnels homelab
and cloudflared
for more info. There’s a bunch of YouTube videos and tutorials on setting it up. It’s not perfect, but it’s a free and easy way to selfhost from a limited network environment.
I’m guessing you want to selfhost, rather than use a hosting service?
When you say you have your site already, do you mean it’s hosted on a local webserver, or just that you have the files?
If it’s just the files, you’ll need to choose a webserver. I like NGINX myself, but lighttpd is another option (there’s quite a few options, really, but sticking to a well known option is generally more secure).
Configuration will depend on the server you choose, but then you’ll put the files into three “root folder” used by the webserver. This isn’t the system root ( ‘/’ ), but a different folder specified as the root of your web page, usually ‘/var/www/html or /srv/www/html’.
Once the files are in place, you can test the site by using the web browser on another PC and entering the local IP address of the server. If everything looks good, you can set up port forwarding on your router to forward public port 80 to port 80 on the local server.
Lastly, you will need a DNS provider which will point your domain to the IP address of your router. Assuming you have residential service, you will need to determine whether your IP address is static or dynamic, or if your ISP is utilizing CGNAT. Depending on those factors, you may need to do some additional setup.
Once it is working, your next step will likely be to set up SSL and port forwarding on 443. That will allow your website to be accessed over https, which is the standard for the modern Internet.
I have hosted my own website and a blog for a while, and there are definitely some additional steps I would recommend to take, but the above is your basic starting point.
It’s not. It’s just a GUI for a server.
It’s a modular GUI, though. The base install allows basic server management: system stats, upgrades, and a couple other bits. However, you can install additional modules to expand the GUI to allow for storage management, ZFS management, container management, file sharing (NFS, SMB), a file browser, VM management, user management, and so on.
My go-to “NAS system” is just standard Debian with Cockpit and a handful of supporting modules. It gives a nice GUI like OMV, but with all the flexibility and control of a normal Debian install.
Late to the party, but if you really want a GUI for ZFS, 45drives has a ZFS plug-in for cockpit that works quite well.
That’s called dynamic DNS (it’s the dd in ddclient).
I selfhost my blog without a static IP. You just need Dynamic DNS.
Keep in mind that your outbound bandwidth might be different from your inbound. I get 300mbps in, but only 5mbps out. It’s not noticeable during normal Internet use, but as you start sharing content publicly, limited bandwidth becomes really noticeable.
Using them here to run everything. My whole *arr stack is running in a Quadlet pod. Really convenient, especially the auto update and rollbacks.
I have Xfinity now, so uploads are pretty good (300/80), but I used to have Spectrum, which not only cost more but only got about 8 mbps up. My solution was to restrict clients to low bandwidth streams, like 3mbps. I only had a couple users, though, so obviously there’s a limit to how far that will scale.
If you can’t upgrade or switch providers to increase bandwidth nor throttle clients, I think the only other solution would be time restrictions, but it’s really going to depend on your users whether that’s effective.