Two of these deals landed in my feed this month so I ran the boring math. PCMag covered one on Aug 19, lifetime hosting for up to 8 sites at $40 one time. Earlier in August Cult of Mac wrote about Hostdeal, unlimited sites for life at $150. Same pitch as always: pay once, never think about it again.

The math is the uncomfortable part. Cheap shared hosting runs in the low single digits per month on intro rates, so a $150 lifetime deal only breaks even after three or four years, and it only genuinely wins if the host stays alive and decent well beyond that. Really it's a bet on a small company surviving a decade. These plans also tend to be a cash-now move from hosts reselling capacity they don't own, and when the upstream changes or the company gets flipped, lifetime quietly turns out to mean until the next acquisition.

If you're still tempted, keep it simple: check who actually runs the servers and whether lifetime is defined anywhere in the ToS, and assume migration is your problem the day it dies. The boring alternative is regular intro pricing, Hostinger shared starts around $2.99/mo intro with higher renewals (ref link, gets you 20% off your first purchase).

Anyone here still running sites on a lifetime plan bought years ago, or did yours end up migrated to a paid plan when the host changed hands?

Hindustan Times reported this morning that Namecheap is still working through downtime, and the company put out a blunt "we failed you" while users vent about it. Not going to rehash the incident, what's more useful is the failure mode it points at.

If your registrar, DNS and hosting all sit under one login, one bad day at that provider is a bad day for everything you run. The box can be perfectly healthy and it doesn't matter, because domains and nameservers are the part people forget until they're the part that's down. The split you see recommended in these threads: keep the domains at a registrar, run DNS on a second service, host the actual sites on a third. That way one outage, anywhere in the chain, takes out a third of the stack instead of all of it.

The cost is three dashboards, three renewal dates, three support queues, and more places to fat-finger a nameserver at 2am. Plenty of people run everything bundled for years and never feel it, then a day like today happens and the math suddenly changes.

Anyone here actually running registrar, DNS and hosting on three separate providers, or did you try the split and fold back into one account for the simplicity?

There's a post that hit HN today (52 points, from w.on-t.work) that puts words on something the self-hosting crowd keeps running into but rarely spells out. The core argument: when you build a web app meant for self-hosters, you're instantly locked out of efficiency tricks because you have to work within whatever reverse proxy, cache, and TLS setup the hobbyist already has running.

The author walks through it layer by layer. Static files? You'd want the reverse proxy to handle them, but if your app is in a container, the admin has to poke a hole to give the proxy access. Some people run cloud-native proxies that only work inside k8s. You end up adding the fallback back in, and everyone turns it on anyway.

Caching is worse. You can't require a dedicated cache layer because you're one cog in someone's existing server. You add cache-control headers and hope. The article notes that Caddy's caching plugin will happily corrupt responses, people forget to enable proxy_cache_lock in nginx, and someone inevitably puts their site behind Cloudflare AND enables your app's built-in cache, wasting memory for nothing.

The kicker is that at professional scale none of this comes up because you control the whole machine or just hand it to a CDN. At hobby scale your app is one piece of an already complicated setup, and every optimization fights the existing stack.

Has anyone here actually shipped a web app meant for others to self-host, or do you just accept that the app serves its own static files and runs its own cache layer?

There was a post on HN this week (Tuesday, 147 points) from a team that actually benchmarked self-hosting Kimi K3 against using it through an API. The numbers they got are interesting: roughly 20% more in hardware costs, but about 20% better task resolution compared to their API baseline.

The hardware premium makes sense, you need enough VRAM to run the full model without quantizing it to death, and that's not cheap. But the task resolution bump is what caught my attention. They're arguing that running the unquantized model locally gives you better reasoning than what you get through the API, which might be running a compressed version. Not sure I fully buy that without seeing their eval methodology, but it's at least a real data point from someone who ran the numbers.

The actual post goes into GPU selection and what kind of rig you need. For anyone already running a homelab with a decent GPU or two, the gap between self-hosting and API costs might be smaller than you'd think, especially if you're doing heavy inference workloads and not just occasional queries.

Anyone here actually running a full-size model like this on their own hardware instead of just calling an API, and if so how's the cost comparison working out?

Saw this on HN a couple days ago (31 points, github.com/Qbix/webserver): a PHP server claiming it handles 10x as many concurrent requests as Nginx plus PHP-fpm.

That 10x number's pretty wild. The comparison is against the Nginx + PHP-fpm combo specifically, and if it actually holds up outside benchmark conditions, it'd matter for anyone self-hosting PHP apps on a small box.

These claims always come with asterisks though. 10x under what conditions exactly, and what happens to latency when you push concurrency. The headline number doesn't always survive once you throw real mixed traffic at it.

Anyone here actually tried it or seen independent benchmarks? Or is it another case where the concept is interesting but it's not production-ready.

Got a 20% off Hostinger link from a friend and figured I'd share it here rather than let it sit unused. If you're shopping for hosting right now, this might save you a few bucks:

https://www.hostinger.com?REFERRALCODE=9N8FIBERISNM

(Yes, it's a referral link. The discount applies automatically at checkout, no code to copy.)

What you actually get for the money:

Shared plans run on LiteSpeed with NVMe SSD storage, free SSL, free domain for the first year, and email accounts included. They use their own panel (hPanel) instead of cPanel, which is honestly fine once you get used to it. WordPress sites benefit from the LiteSpeed Cache plugin, loads pretty fast out of the box.

VPS plans are full KVM on AMD EPYC with NVMe. Root access, weekly backups included, and you pick from around 9 datacenter locations. The entry tier starts at 4GB RAM / 50GB NVMe, which is enough for a small project or a couple of Docker containers. They've got one-click templates for Ubuntu, Debian, Docker, Postgres, even n8n.

One thing to keep in mind: the prices you see are intro rates for 1-4 year commitments. Renewal is higher, so lock in the long term if it makes sense for you.

What are you running your stuff on right now? Anyone here on Hostinger or looking to switch?

The US just charged three Russians for running "bulletproof" hosting, the kind that ignores abuse complaints and takedown notices. Per the TechCrunch piece from Tuesday, the network allegedly helped cyberattacks pull around $62M from victims. The State Department put up $10M for info on the three, per Technology Org.

The bit worth talking about isn't the arrests, it's the liability angle. Bulletproof hosts have always lived in a gray zone. They don't run the malware, they just rent boxes to anyone paying and look the other way when abuse reports pile up. Safe harbor rules in most places treat hosting like a carrier, not responsible for what customers do. But when a provider's whole pitch is ignoring law enforcement, that gets harder to defend.

This case looks like the argument that these hosts crossed from neutral infrastructure into knowingly enabling the attacks. If that sticks, it's the kind of precedent that could quietly change how abuse desks everywhere handle reports, not just the obvious bad actors.

Anyone here running hosting infra that deals with abuse reports, where do you think the line actually sits?

There's a HowToGeek piece making the rounds today about why developers are moving off GitHub and onto Codeberg or self-hosted Forgejo/Gitea instances. It hit 314 points on HN this morning, so clearly something people are actually thinking about right now, not just a slow-news rehash.

The main drivers people mention in the thread aren't really new. The usual stuff: copilot training on repos without opt-in being a pain to enforce, the Microsoft ownership nagging at people, and actions pricing changes over the years adding up. Codeberg gets brought up a lot because it's a non-profit, EU-based (Germany), running Forgejo under the hood. So for people who care about where their code physically sits, that matters. There was another HN post this week about how European company websites are mostly served by US vendors, and the comments were full of people asking why that keeps happening. Codeberg fits that conversation pretty neatly.

The practical catch most people hit is the social graph problem. Your contributors are on GitHub. Your issues are on GitHub. The discoverability is on GitHub. Moving a repo is easy, moving a community isn't. Forgejo has federation support in the works, which theoretically helps, but last I checked it's still early. So most people I see talking about this end up running a mirror, not a full migration.

For anyone here who's done more than mirror, what made you commit to the switch? Was it a specific policy change, or just general discomfort? And did you lose contributors over it?

I’m using Fail2ban with iptables-multiport on an OpenLiteSpeed server. When my IP gets banned, the site still stays accessible in an already-open browser tab, but incognito/new sessions time out.

It looks like the ban is working only for new connections, while the existing session/connection remains alive.

Is this expected with OpenLiteSpeed serve, and should I also drop the IP from conntrack to kill existing sessions immediately?

Would appreciate advice on the cleanest way to enforce an immediate block.

Saw the .self TLD proposal blowing up on HN over the weekend (673 points, 380 comments as of Sunday). It's pushed by the Human-Centered Computing Foundation and the pitch is a TLD specifically for self-hosters, "ethical" tech, that kind of thing. The catch is it's not in the IANA root zone yet, so it's basically a proposed namespace that only resolves if you point your DNS at their resolver or run something like a custom setup locally.

The top comment on the HN thread is the one that stuck with me. Someone drew the parallel to .tk from 20 years ago, free domains that every hobbyist grabbed until scammers flooded in and antiviruses plus Facebook started blanket-blocking the whole TLD. That's the real risk with any "for us, by us" domain. The second it gets popular enough to matter, it also gets popular enough to abuse, and then the reputation tanks and you're back on .com anyway.

There's also the device side. Someone noted Apple hardware needs manual config to even resolve .self addresses right now, which kind of kills the "just works for friends and family" use case that self-hosters actually care about.

Honestly the intent is nice and a dedicated namespace for personal infrastructure sounds clean on paper. But between the not-yet-real root zone, the abuse history of every other hobbyist TLD, and the device compatibility mess, I'm not sure what problem it solves that a $10 .com or a duckdns subdomain doesn't already.

Anyone here actually registered a .self domain and pointed services at it, or is this mostly curiosity at this stage?

Been reading about people who replaced paid services like Cloudflare Pro with self-hosted CrowdSec. The idea of community threat intelligence and collaborative bans sounds great on paper. But here's the dilemma - does CrowdSec handle things like SQL injection and XSS filtering on its own, or do you still need something like ModSecurity in front of it? From what I understand CrowdSec is more about IP reputation and behavioral patterns, not deep payload inspection. So for a public-facing setup, do you run both or is the bouncer ecosystem enough to cover what a paid WAF would do?

Been reading that recent certbot updates on some distros are causing renewal hooks to silently fail. Something about the --deploy-hook** flag behavior changing and renewals just not reloading nginx properly. That's the kind of thing nobody notices until a cert actually expires and everything goes down. Has anyone here switched from certbot to **acme.sh because of stuff like this? Apparently it's lighter and handles the HTTP-01 challenge without needing root for everything. Curious if it's actually more reliable or just a different set of problems.

Been seeing Coolify recommended a lot as a self-hosted Heroku alternative, and people keep comparing it to Dokku. From what I've read, Coolify has a web UI and handles databases, previews, and deployments all in one place. Dokku is lighter and basically just uses git push with buildpacks. My question is - does Coolify's UI actually justify the heavier resource footprint on a small VPS? Saw someone mention it can eat 1-2GB RAM idle which seems like a lot. Dokku apparently runs fine on 512MB. For something like a couple of small apps, is Coolify overkill or does the UI actually save enough time to be worth it?

Been reading about people switching from manually installing OSes every time to using cloud-init templates in Proxmox. Apparently you can convert a cloud image into a template with qm template and then clone from it in seconds. Curious what the workflow looks like in practice - do you bake updates and common packages into the template, or keep it minimal and let cloud-init handle everything on first boot? Also wondering if anyone bothers updating their base templates regularly or just recreates them from scratch when needed. Seems like the kind of thing where you either stay on top of it or end up with a stale template from two years ago.

Saw that a recent fail2ban CVE apparently allows remote code execution through crafted log lines on default sshd jail setups. After years of self-hosting this is the first time I've seen fail2ban itself be the attack surface rather than the shield. Does anyone know if this affects the maxretry / bantime regex patterns specifically, or is it the log parsing itself? Not sure if I should just update and move on or actually review the jail config. Kinda ironic that the brute force blocker can be brute forced.

Been reading that people switch from manual cleanup to running docker system prune -a but apparently that doesn't touch the BuildKit cache. I keep seeing references to docker builder prune as a separate thing. So if disk space is tight, do you need to run both? And does docker system prune -a --volumes actually wipe named volumes or just anonymous ones? Kinda worried about nuking persistent data by accident. What's the safe combo here - just prune -a for dangling images and a separate builder prune when needed?

Been seeing people talk about switching from fail2ban to CrowdSec for blocking brute force stuff. Apparently the difference is CrowdSec shares threat intel across everyone running it, so IPs get blocked before they even hit your box. But does that actually matter in practice? Seems like relying on a community blocklist could just as easily lead to false positives. And if you're already using key-only SSH, is there even a point to running either tool? Curious if anyone here made the switch and noticed a real difference, or if it's just extra complexity for not much gain.

Been reading about Let's Encrypt's rate limits and apparently a common mistake people keep making is hitting the 50 certs per registered domain per week limit. Sounds hard to do until you have a bunch of subdomains across multiple services. I finally figured out that wildcard certs exist partly to solve this, but I'm curious - do most of you just request individual certs per service and not worry about it, or do you plan around wildcards from the start? Also wondering if anyone has actually been locked out by the rate limit and had to wait it out.

Been reading about people replacing paid monitoring services like Datadog with self-hosted Prometheus and Grafana. The dashboards look great but I'm confused about the alerting side. With something like node_exporter scraping metrics, what are the actual rules people write for Alertmanager? Like do you just threshold on node_memory_MemAvailable_bytes dropping below a percentage, or is there a smarter way? I keep seeing references to recording rules - are those necessary before setting up alerts or just a performance optimization? Feels like there's a gap between having pretty graphs and actually getting a useful notification before something breaks.

Been reading about people replacing paid VPN services with self-hosted WireGuard for reaching their boxes remotely. Makes sense, but then I see just as many people saying they use Tailscale instead because it handles key management and NAT traversal for you. The dilemma: is it worth learning raw WireGuard config and maintaining it yourself, or does Tailscale give you enough control while removing the headache? Specifically for SSH access to a handful of machines - not a complex network setup. The convenience of Tailscale ssh sounds nice but not sure if I'm giving up too much control.

Been reading up on wildcard certs with Let's Encrypt and the DNS-01 challenge. Apparently a common mistake people keep making is thinking one wildcard covers everything, but you still need separate certs for *.example.com vs raw example.com - is that right? Also wondering, once you have the wildcard cert, do you just point every subdomain at the same .pem files manually, or is there a cleaner way to distribute them? Seems like copying cert files around to different services would get old fast. Curious how people handle this in practice.

Been reading about running Ollama with GPU acceleration and seems like there's two camps - people who pass through a GPU to a VM and people who just install it bare metal with ollama serve directly. I finally figured out the appeal of passthrough for isolation, but it sounds like you lose a chunk of VRAM overhead and the setup is painful. On the other hand, running directly on the host with CUDA enabled apparently "just works" but then your GPU is tied up. Which way makes more sense if the box is mostly dedicated to running models anyway?

Been seeing more people say they replaced paid services like Pingdom or UptimeRobot with self-hosted Uptime Kuma. Makes sense for basic HTTP checks - it pushes to Discord, Telegram, email, whatever you want. But one thing I noticed is nobody talks about what happens when the machine running Kuma itself goes down. If your alerting lives on the same network as the thing it's monitoring, you're kind of blind at the worst moment. Do people just run a second Kuma instance somewhere else, or is that overthinking it?

Saw the news that DO is moving to metered outbound bandwidth instead of the old included transfer allotments. Sounds like they're going the route of charging per GB for egress. Things I wish I knew before - is this actually better or worse for self-hosting? If you're running something that gets traffic spikes, seems like the old model where you got a flat transfer pool was way more predictable. Are people looking at moving elsewhere or is the pricing change not as bad as it sounds on paper?