I actually just updated it slightly, and may continue to do so if I think of things. So you may simply want to check back here instead of printing it.

On Cloudflare, you’ll want to set a DNS record to point any relevant subdomains to your current WAN IP address. IPv4 will be an A Name record. IPv6 would be an AAAA Name record, but I’m not going to deal with IPv6 for this… Here is an example of mine, with info blocked out:

So for instance, maybe you have a peepee.example.com subdomain, a poopoo.example.com subdomain, etc which all point to your WAN IP address. That will basically tell Cloudflare’s DNS to forward any traffic for those subdomains to your WAN IP. Each subdomain can also choose whether or not to proxy the content, or just directly send it to your WAN with DNS. Basically, when Cloudflare propagates the DNS records to the various DNS servers, you can choose whether that record has your WAN IP (DNS Only) or one of Cloudflare’s (Proxied). Proxy support means you can take advantage of some additional CF protections, but it also means passing all of the data through CF’s server. In most cases, you’ll want DNS Only. Proxy support will depend on the individual service. Some will work fine with it, some won’t. And it’s also possible that you don’t want services proxied through CF for privacy reasons.

Next, you’ll want to set up a reverse proxy service. This will be something like Nginx Proxy Manager, Caddy, etc that you run on a device on your LAN. It can even be on the same machine running your various services. The big reverse proxies all offer Docker images, so you can incorporate it directly into an existing Docker stack if you already have one. Personally I use NPM, but Caddy is also very popular.

You’ll tell this reverse proxy “when you receive valid traffic addressed to {subdomain}, forward it to {relevant service on your LAN}.” You can also set some additional options for each subdomain, like automatically upgrading to https. For instance, maybe peepee.example.com forwards to 192.168.1.100:42069 on your LAN, and is configured to automatically upgrade any http traffic to https, and to require https.

You can also set up automatic TLS certificate renewal, so https traffic can be properly encrypted. The reverse proxy will need an API key, and it will allow the service to automatically check expiration dates and pull a fresh TLS cert for your domain if the date is coming up soon.

You’ll probably want to use a wildcard certificate, (basically *.example.com) because the TLS certificates are open to the public. So if you do individual certs for all of your various services, bots will scrape the public records and you’ll inevitably get a lot of bot traffic probing your various subdomains. A wildcard domain usually means the bots hit the standard example.com and www.example.com first, which makes them super easy to detect and block. I even have rules set up to automatically block anything that tries to access my www subdomain, because I specifically don’t host a landing page and don’t have anything available there. So I know that any traffic hitting that www subdomain is a bot trying to access common subdomains.

Next, you’ll want to forward ports 80 and 443 to your reverse proxy. Port 80 is the standard port for http traffic, and 443 is the standard port for https traffic. These will be the ports that your reverse proxy actually receives the traffic on, before forwarding it to the various services. Note that lots of lazy devs default to using 80 and 443 for lots of things, so you may want to configure your router to use a different port (like 81 or 444) for its config page if you’re able. Otherwise, you may end up accidentally locking yourself out of your router’s config page, because it will attempt to use 80 to reach the page, then get automatically forwarded to the reverse proxy instead.

Finally, for some ease-of-maintenance, you may want to consider adding a DDNS service (like Cloudflare-DDNS) to your docker stack. This will occasionally check your current WAN IP, and update it with Cloudflare if necessary. For example, if you have an outage and your router gets a new WAN IP when it boots back up again. Normally you would need to manually go to Cloudflare and update the IP info to point at your new address. But DDNS does that automatically.

The way traffic flows when it is all set up is along these lines:

1. A device wants to access your service at peepee.example.com. It doesn’t know where to find that site, so it asks a DNS server.
2. Cloudflare has told all of the various DNS servers “hey, peepee.example.com can be found at {your IPv4 WAN address}”.
3. The device follows that DNS record, and attempts to connect to your IPv4 WAN address, on port 80 or 443. For this example, let’s say it tries to connect on port 80 for standard http traffic. The device knocks on port 80’s door and says “hey, I’m here to access http://peepee.example.com/.”
4. Your reverse proxy checks the configured list, finds the valid peepee.example.com subdomain, finds it has a valid TLS cert, finds it is configured to automatically upgrade to https, and responds “Yes, please upgrade to https. Http traffic is not allowed.”
5. The external device knocks again, this time on port 443’s door. It goes “hey, I’m here to access https://peepee.example.com/. Your reverse proxy goes “thank you, here is the TLS cert and my half of the TLS security handshake.”
6. Your external device uses the data in the TLS cert to validate and complete the TLS handshake with the reverse proxy, and the traffic between the reverse proxy and your external device is now encrypted with https. Your device gets the nice little “secured” padlock icon in your browser. Because the traffic is encrypted, a malicious actor may be able to tell what kind of info you are passing (for example, a video stream will likely have a pretty obvious pattern) but they won’t be able to see what specific data you are passing. They may be able to tell that you’re streaming a video, but they won’t know which video specifically.
7. The reverse proxy forwards the traffic to the service, configured at 192.168.1.100:42069.
8. Your service does not ever know the device is being accessed via WAN, because (as far as the service can tell) the traffic is coming from your reverse proxy (also a LAN device). So any “pay to use WAN” services will continue to work for free.
9. The external device never gets access to info like the specific LAN IP or port number, because it only has access to the reverse proxy. All of the traffic is passing back and forth between the reverse proxy.

But notably, keep in mind that the reverse proxy didn’t do any actual user authentication. If your service has a weak password, a reverse proxy will act as a gateway for any potential hackers to gain access to the service. The same way an open port is a gateway directly to the service, the reverse proxy is now a gateway that simply requires an attacker to use a subdomain instead of an IP and port number. And if you make your subdomain something like jellyfin.example.com it will probably be dead simple for a bot to guess. And any vulnerabilities in the service will still be exploitable via the reverse proxy, because the reverse proxy is simply making sure the request is valid, and then passing the traffic back and forth. It isn’t actually inspecting the content of that traffic, so it’s not going to stop things like attackers. When you hear digital security folks talk about things like attack vectors, this is what they’re referring to. Your reverse proxy is a potential vector of attack for your configured services. Use strong passwords, keep your services updated, etc…

You can technically add authentication to a reverse proxy. So for instance, maybe a service doesn’t have any built-in way to add a password. You can have the reverse proxy act as an authentication gate, so it will prompt the user for a username+password before they can even reach the service. This will make the services more secure (yes, even the ones that already have passwords, as long as you use a different password for your reverse proxy authentication) but it will break most apps that are designed to work with a service. For instance, Jellyfin has several apps that work, but those apps won’t have any way to get past the reverse proxy’s password gate. So those apps will simply break if you add a second layer of authentication with your reverse proxy.

There are also some security options you’ll likely want to enable on Cloudflare’s side, but this comment is already long enough.

Was going to comment something along the lines of “Inb4 someone posts that obscurity will keep you secure” but here you are. No, you won’t be secure just because it’s on IPv6. And TLS certs are open to the public, (they literally have to be, since any device attempting to access your server needs to be able to validate the cert) so bots will scrape them and instantly have whatever you made it for. So it wouldn’t even keep you obscure.

I’m honestly shocked that nobody has corrected my incorrect usage of Poe’s Law.

I think this is a very well thought out approach to handling it. I can’t personally think of any better solutions, at least. I probably would have chosen some different phrasing for the tags, (CBH feels… Disconnected? I’d probably go with something like “No AI” or “AI-Free” instead), but that’s just a matter of personal diction. Outright banning posts about projects that use AI likely isn’t going to be feasible in the long run, and I think that simple declaration requirements will go a long way towards encouraging people to actually disclose their usage.

If you outright ban it, people will simply hide their usage. It feels like it’s akin to the US War On Drugs^TM in that way. If you allow it and simply require responsible disclosure, more people will be inclined to be upfront about it. And that allows projects to be more accurately audited and vetted. The same way the war on drugs consolidated power to organized gangs (by making them the only ones capable of producing and transporting illegal drugs at scale), an outright ban on AI would only encourage people to hide their usage.

One potential way I see people trying to skirt the rules regarding self-promos is via proxy/strawman accounts. It would be trivial for me to spin up a dummy account and post my own project as an “I found this cool project but don’t have to disclose my AI use because I didn’t make it” post. I don’t personally have any projects in the works to post about, but I can easily see someone using it to try and skirt the disclosure requirements. Especially when we have seen situations like the (now infamous) Huntarr debacle, where the vibe-coder dev was actively avoiding AI disclosures. Because they knew it would tank the project’s popularity if people knew it was vibe coded.

I’m not sure if there is a good solution for this potential issue, except maybe to limit posts by new users. But even that is trivial to bypass. If you limit them based on account age, simply making a few strawman accounts and waiting for them to age is easy. Hell, I already have a few old throwaway accounts that I could swap over to whenever I want, and I’m not even planning anything nefarious.

There are similar problems with restricting users based on post/comment count, as that will likely stifle discussion from new users who are trying to be active in the community. One of the more frustrating parts about Reddit was that many of the most popular subs banned posts from users who were below a certain post karma threshold or who didn’t have enough previous posts. It created a catch-22 where you needed to have a few popular posts before you were allowed to make any posts. So there were people posting on random niche subs, simply for karma farming before they could then post on the larger subs. And if I was a vibe coder without scruples who is already looking to skirt the rules, it would be trivial for me to spin up an LLM and let it make a few comments before I start using it as a dummy account.

This may end up being a non-issue in the grand scheme of things. But I figured I’d mention it, because I genuinely don’t see a good solution for patching the big glaring hole in the self-promo rule. You’re absolutely correct that requiring disclosure for every post is unrealistic, because lots of users who post projects here aren’t the devs. They just stumbled across a cool project and wanted to share it, and they have no realistic way of knowing if the project uses AI. And if you restrict promo posts to only devs, you’ll only get posts from the people who fall into the (likely very small) overlapping section on the “is a Lemmy user” and “makes projects” Venn diagram. Lemmy is already a small community in the grand scheme of things. And restricting promo posts to only the people actively developing the projects would make it feel even smaller.

If I do use mine, I’ll put it up on codeberg so everyone can see exactly what its doing… and then get mad and tell me there is a better way.

Poe’s Law is always in effect. The best way to get an answer on the internet is not to ask a question; it is to post an incorrect answer, because people will go out of their way to correct you.

I block all of my smart TVs at the DNS level with my pi-holes. All of the benefits (native streaming apps, easy casting, a functional remote without any fuss, etc) without any of the ads or tracking.

Yes, but not everything does. But luckily, Docker exists on Windows. So anything that runs on Docker can be run on Windows.

Given, Docker’s implementation on Windows is… Uhh… Not Great^TM. Because it’s basically using WSL to trick Windows into supporting a Linux file system. So it has some quirks. But it does technically work.

You have trouble getting Docker to auto-start on Windows? I thought that was the default behavior… Hell, even if it’s not, you can just add a Docker shortcut to the Startup folder.

Yeah, I keep a “Kids” profile on my Plex/Jellyfin server, specifically so I can throw Bluey, Mr Rogers Neighborhood, Miss Rachel, etc on and not worry about it. Elsagate (which is still a big problem) means you can’t just put on YouTube Kids and expect auto-played content to stay safe. But with my server, running solely on content I have curated, I know that everything in that “Kids” profile is going to be safe.

Usenet will likely still be around, and torrents are like playing whack-a-mole.

My only complaint is that lots of my streaming devices don’t natively support newer codecs. So if I convert everything to AV1, my server will end up transcoding basically everything. Smart TVs are particularly bad about supporting anything past h264.

Yeah, the *Arr stack has effectively eliminated the need to permanently retain media. I want to watch something? I just request it, and 10-20 minutes later it is available on my server. I tend to treat *Arr requests the same way I used to treat Blockbuster trips. It takes a few minutes to get what you want to watch, but that’s also a chance to make some popcorn, grab a beer, and settle in.

I only (“only”) keep ~25-30TB of media available at any one moment. And even that is plenty. It’s literally hundreds of movies and TV shows. And if I want to purge old content, that’s easy to do too. Hell, I can even sort by the last time it was watched, and start with the shit that hasn’t been touched in like 18 months.

Yeah, WordPress is an extremely common vector for automated attacks. It’s highly expandable, but those plugins often aren’t secure. Even my tiny site (it isn’t running WordPress, and doesn’t even have a landing page because I only use it for my own stuff) sees a ton of attempted Wordpress attacks.

You’ll need to do some config on the actual services as well. Mostly in regards to telling it how you want to add things to your wanted list, how it should search for files, how you want it to download files, how it should handle downloaded files to be compatible with your media server, etc… Docker-compose can do a lot, but the *arr services are too granular to define everything directly in the compose file. You’ll need to actually configure the services after they are booted up via docker.

My stack includes the following:
Prowlarr for tracker management. This defines the various search methods, and makes them available for the rest of the stack.
Seerr for media requests. This manages what shows/movies are on the stack’s search list.
Sonarr for TV shows. Seerr tells it what to search for. It takes the relevant trackers from Prowlarr, and uses them to search for wanted media. It grabs media from the search based on quality profiles. For instance, my profiles are set to exclude 3D media, because none of my screens can display 3D. This is synced with my torrent client for automated downloads. When a download is completed, it automatically creates a hardlink in the relevant media folder for my media server to find. It uses the specific naming scheme for the media program, so the program can automatically detect info about the files.
Radarr for movies. Same basic concept as Sonarr.
Cleanuparr for download management (and some basic malware protection). Tracks downloads’ ratios, and automatically removes them from my torrent list when the ratio/time threshold is met. It also tracks “slow” torrents and will automatically retry them if a torrent is stalled/slow for too long. Also does some basic “movie.mp4.exe” torrent checking, to automatically block malicious downloads that get grabbed by the rest of the stack.
Bazarr for subtitle downloads. Automatically analyzes my media, and finds matching subtitle files for my media server to use.

Each of these will require specific config steps. For instance, Prowlarr will need to know which torrent/usenet trackers you want to use. Sonarr will need to know how to interface with your download client, which files to grab based on quality profiles, and how to rename files during import.

I prefer to follow the advice from people who actually set up and maintain email servers: “Fucking don’t. It’s not worth it.”

Just get a custom domain and run it through an existing email provider.

40TB, but that’s way more than I would realistically need if I was better about deleting old content. I have shows saved that I haven’t watched in years. With the *arr stack, there is very little reason to keep a lot of media saved, because reacquiring it again in the future is dead simple.

Pretty sure lots of the “deleted” posts were actually removed by the mods. Rule 3 seems to be a popular justification for post removal in this community, and it basically outlaws all of the “my server is having this issue, anyone got any ideas” types of posts that OP has cited.

While I agree it’s popular for removing posts, maybe it shouldn’t be. If we want users to organically find Lemmy, one of the best ways to do that is the same way users end up at Reddit: By googling an error code, and finding a five year old “Edit: I figured it out. Here is what I did” post.

Or maybe we just need to make (and properly support) a community that is dedicated to those kinds of posts. If a “my server is broken plz help” post isn’t relevant to /c/selfhosted@lemmy.world, maybe we need to make a /c/SelfHostedSupport to redirect the Rule 3 posts to.

My guess was that it’s users who fundamentally misunderstand federation, and think that deleting their comments will prevent them from being scraped or used to ID them later. In reality, if someone was truly concerned about avoiding doxxing, they’d just switch accounts. Because anyone can spin up a single-user instance, federate to scrape content from all the communities they want, and then simply refuse to respect delete requests.

Because when you delete something on a Lemmy instance, the instance simply sends a delete request to all the other instances that federated with it. But those other instances can easily ignore the delete request and retain the deleted content for as long as they want.

That’s also part of why it’s so stupid that AI crawlers are scraping Lemmy and thrashing instance owners’ rate limits. The AI crawler could just set up a new instance and automatically gather the content via federation. But instead, they just send crawler bots. Because fuck the instance owners, I got my content either way and using a crawler bot didn’t require me to learn how federation works.

Yeah, to stretch OP’s definition to the limit, would you consider something self-hosted if it’s running on a Windows machine? Because even if the program is FOSS, Windows is a paid OS. How about Proxmox, an open source OS which is designed to self-host other things? Proxmox is open source, but paid. Where is the line in the sand for what is, and isn’t self-hosted?

I tend to take a more anarchic “if you set it up yourself, it’s self-hosted” approach to it. Even if the program isn’t FOSS. Even if it isn’t OSS. You had to go through the steps to get it to boot up. You had to go through the steps to acquire media for it if it’s a media service. You had to go through the steps of connecting peripherals to it if it’s something like Home Assistant. You had to go through the steps of getting remote access working if it’s on a reverse proxy. You had to go through the steps of getting the VPS configured if it’s running on a VPS. It’s being hosted on something you set up, (even if it’s a VPS that you’re not locally running) so it is self-hosted.

It’s not truly self hosting unless you start by creating the universe.

Edit: Balls, @gedfromgont@piefed.ca beat me to it. That’ll teach me to riff on Sagan quotes before I scroll down in the thread.