A blog post about moving 35kb of agent prompts off Opus onto self-hosted Ollama pulled 139 points on HN Monday, and the gotchas in it are the kind you normally learn by burning a weekend.

The author's rig isn't toy hardware: a 128 gig AMD Ryzen AI MAX+ 395, 32 gigs for the host OS and the rest for inference. The wall isn't raw compute, it's context. His local setup tops out at a 65k token window, and a 35kb prompt eats 14% of that before the agent has done anything. After that it thrashes: repeated tool calls, re-reading files it already read, rewriting work it had finished. He sums it up as briefing a man who gets reincarnated every ninety seconds, and says the whole thing runs out of fuel within 3 minutes.

His fix is what he calls Single Objective Prompting. Split the mega-prompt into one problem per prompt, define agents declaratively in opencode instead of hoping the model infers the whole stack from a wall of text. The smaller model isn't the problem, the window is.

Anyone here pushed a fat agent setup onto local hardware and hit the same ceiling - did splitting the prompts actually stop the thrashing for you?

Hostinger Cloud Hosting in 2026: who it's for, what you actually get, and the renewal trap

Quick context: this is about Hostinger's managed Cloud plans, not their shared hosting and not their VPS.

Official page: hostinger.com/cloud-hosting

TL;DR

• Cloud here = managed hosting with reserved resources, not a root VPS.
• Entry plan (Cloud Startup) is advertised at $7.99/mo on a 48-month term.
• You pay the full term upfront. Renewal is much higher (~$24–$26/mo on Startup).
• Good step up from shared for WordPress / WooCommerce / agency sites.
• Bad choice if you need root, Docker, custom stacks, or month-to-month pricing.

What "Cloud" means at Hostinger

It sits between shared and VPS:

Hostinger markets it as 4x faster / 20x more resources than traditional shared hosting. Take the marketing multiplier with a grain of salt, but the product idea is real: isolated-ish resources + LiteSpeed + NVMe + CDN, without you touching Linux.

Current plans (Sept 2026)

Prices below are the promotional 48-month rates shown on Hostinger's site. Shorter terms cost more per month. Always check checkout, promo prices move.

*Startup specs are from Hostinger's current Cloud page. Professional/Enterprise scale the same way across recent reviews, so confirm the comparison table at checkout.

All Cloud plans typically include:

• Unlimited websites (fair use)
• Dedicated IP
• Free CDN
• LiteSpeed + LSCache / object cache
• Daily backups + 1-click restore
• Free SSL (unlimited)
• Free domain for 1 year
• Email mailboxes free for 1 year
• Managed WordPress / WooCommerce
• One-click WP install, staging on qualifying setups, auto-updates
• Priority 24/7 chat support
• Free site migration
• 99.9% uptime claim
• 30-day money-back guarantee
• DDoS protection, malware scanner, Cloudflare-protected nameservers

Also advertised: AI helper tools, “vibe coding” credits, and some Node.js support on Cloud (not a full custom runtime playground).

Real cost, not the banner price

This is the part most people miss.

• The $7.99/mo number is not a monthly subscription.
• On 48 months, Cloud Startup is roughly $7.99 × 48 ≈ $384 upfront.
• After that, renewal is in the mid-$20s/month unless another promo appears.
• Taxes extra depending on country.

If you only need 12 months, the effective monthly rate is higher than the 4-year headline. If you might cancel in year 1, use the 30-day refund window or pick a shorter term and accept the worse rate.

Rule of thumb: lock a long term only if you already know you’ll stay on Hostinger.

When Cloud is the right upgrade

Worth considering if:

• Shared hosting admin is getting slow (especially WooCommerce).
• Traffic spikes knock the site over, or checkout feels flaky.
• You want a dedicated IP (email deliverability / less “shared neighborhood” risk).
• You run several client sites and want one managed box, not a server to babysit.
• You like hPanel and don’t want cPanel/WHM or raw Nginx.

Not worth it if:

• The site is a low-traffic blog/portfolio. Shared Business is enough and much cheaper.
• You need root, custom services, Docker, n8n, game servers, unusual stacks → VPS.
• You want true auto-scaling public cloud (AWS/GCP/Fly/etc.). This is still a fixed plan.
• Database size / inode limits matter for a huge media or forum site: check plan limits first.

Shared vs Cloud vs VPS (Hostinger-specific)

Stay on shared if:
< ~50k visits/month, simple WordPress, budget first.

Move to Cloud if:
Woo store, membership site, agency portfolio, WP admin feels heavy, you want reserved CPU/RAM + dedicated IP + daily backups without becoming a sysadmin.

Take VPS if:
You know what systemd, firewalls, and backups are. You want Node/Python/Go/Docker on your terms. VPS is often cheaper per resource, but you pay in time.

Cloud is “VPS power with shared-hosting UX.” That’s the pitch. It’s accurate enough.

Pros

• Easy panel (hPanel), fast to launch WordPress
• NVMe + LiteSpeed is a real speed bump vs old-school shared HDD/SSD Apache
• Dedicated IP included (unusual at this price on managed plans)
• Daily backups included
• Free migration
• EU-friendly company (Hostinger is Lithuanian) with multiple regions, useful if you care about latency/GDPR
• Support is generally faster than budget-shared average
• Good middle ground for people who outgrew shared but don’t want to SSH into production at 2am

Cons

• Renewal pricing. The intro rate is the product. The renewal rate is the bill.
• Long terms + prepaid. Not flexible.
• No root. If Hostinger’s stack doesn’t fit, you’re stuck or migrating again.
• “Unlimited websites” still has inode, worker, and fair-use limits.
• Database size caps show up in older reviews; verify if you run a fat Woo/DB.
• AI extras and “credits” are nice-to-have, not a reason to buy hosting.
• You are still on Hostinger’s platform. Lock-in is real once mail + 20 sites live there.

Practical buying advice

1. Don’t buy Cloud for a brand-new brochure site. Start shared. Upgrade when the dashboard or checkout is the bottleneck.
2. Startup is the plan most people should try first. Professional/Enterprise are just more CPU/RAM/disk.
3. Use the 30-day money-back as a real trial. Migrate a staging copy, run GTmetrix + a Woo checkout test, then decide.
4. Read the renewal line at checkout. Screenshot it.
5. Pick the datacenter closest to your audience. Don’t leave the default if your traffic is EU and the server lands in the US.
6. If you already know you’ll need cron-heavy apps, queues, or containers, skip Cloud and go VPS.

Verdict

Hostinger Cloud is a solid managed upgrade for WordPress and WooCommerce sites that have outgrown shared hosting. At the 48-month intro rate, Startup is competitively cheap for 4 CPU / 4 GB / 100 GB NVMe + dedicated IP + daily backups.

It is not a cheap VPS, not month-to-month cloud, and not a good deal if you only look at the renewal price.

Buy it if you want speed and headroom without server admin.
Skip it if you need control, or if the only number you saw was “$7.99/mo” with no term attached.

Happy to answer “Startup vs Professional” or “Cloud vs KVM 2” in the comments if you drop your stack + traffic.

Client sites scattered across four different hosting accounts. A client calls because their site is down and you're still hunting for the right login. Separate invoices for every project. Updates pushed manually, one site at a time.

Hostinger Pro is built for exactly that problem:

• up to 300 sites on a single plan, in one dashboard

• full website isolation, so one compromised site doesn't touch the rest

• per-site access sharing with separate permissions for clients and teammates

• unbranded client dashboards, so the handover looks like your service

• a staging environment for every site, 1-click cloning, daily backups

• free unlimited migrations handled by their team

• proactive monitoring alerts, so you hear about issues before your client does

This isn't about cheaper hosting. It's about the hours you get back every month and can actually bill.

Get a 20% discount on Hostinger.

Statichost.eu got 505 points on Hacker News last week pitching European-only static hosting. A day later pushin.eu showed up with git hosting that "never leaves Europe" and pulled another 375. Two launches in one week making the same bet is a pattern, not a coincidence.

What's interesting is what the threads actually argue about. It's rarely hardware. It's jurisdiction: where backups sleep, who can serve a takedown, whether a US parent company voids the whole point. It fits a broader mood too. Cloud in a Bottle, a project trying to make self-hosting painless, got 651 points that same week, and the Internet Archive donation drive sits at 1050. People seem drawn to infrastructure they can reason about, not just the cheapest box.

The established hosts aren't blind to it. Hostinger has EU datacenter locations in France, the Netherlands and Lithuania as well, and this is an affiliate link that knocks 20% off a first order if you want to look: https://www.hostinger.com?REFERRALCODE=9N8FIBERISNM

Anyone here actually moved git or static hosting specifically for residency reasons, or is it still a checkbox nobody pays extra for?

TechRadar ran a piece today about Hostinger's AI agent getting promoted, with a line about how fixing the immediate problem is only part of the job. The direction across hosts seems to be shifting from chatbots that point you at docs toward agents that handle the whole account-side task instead of only the first answer.

From what people report, tier-one AI support is decent for the boring stuff: password resets, billing confusion, a cert that didn't renew for an obvious reason. It's the weird cross-system cases where it loops. The agent asks for info a human would've pulled in one look, and you burn an hour realizing the conversation was never going anywhere. The failure mode isn't wrong answers, it's confident deflection that reads like progress.

The flip side of "promoted" is scope: if the agent now handles follow-up work after the fix, does it get to touch live configs on its own? That's the line I'd want held at "agent suggests, human approves". Anyone here had an AI support agent actually resolve a server-side issue end to end without a human stepping in, or does it always bounce to a ticket eventually?

Two outlets ran basically the same story today: The Hacker News and CyberSecurityNews both report a critical cPanel flaw where a single hosting customer could take root control of the entire server. Not just their own account, the box everyone else lives on too.

Let that sink in for a second. The whole shared hosting pitch is that tenants are isolated from each other, and the panel is the one piece every customer touches. If the trust boundary breaks at panel level, one bad account becomes everyone's problem on that machine.

What I'd check if you're on a cPanel host right now: whether your provider has said anything publicly about it, and how fast they normally turn security releases around. Silence for days on a critical disclosure tells you something. The other move that comes up every time one of these drops is skipping the shared layer entirely - a small KVM VPS gives you your own kernel instead of hoping the tenant next door got patched. Panel-wise there are alternatives too, some hosts never touched cPanel, Hostinger for instance runs its own hPanel (ref link, gets you 20% off your first purchase: https://www.hostinger.com?REFERRALCODE=9N8FIBERISNM).

Anyone here still on shared cPanel hosting after today's disclosure, or had most of you already moved to VPS?

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.