Latest Hosting News on Reddit

I’m looking for an affordable EU‑based hosting provider for a small project. I’ll be running WordPress and phpBB, but the site will have very low traffic (maybe a couple hundred users at most; niche topic). I’m open to shared hosting or a VPS… Honestly, whichever gives the best value. My main requirement is high storage capacity, due to uploaded images and documents. If you have recommendations for storage‑heavy, low‑traffic hosting in the EU (shared or VPS), I’d appreciate your suggestions! PS: yeah, I know I’m asking a 2005 question in 2025… niche topic. submitted by /u/clioopen [link] [comments]

I’ve been running a few client sites on HostGator shared hosting for about three years. it was fine at first. then i had more than 4-5 wordpress sites on the same plan and everything started crawling. kept tripping their cpu limit and they’d throttle the account, sometimes serving a stale cached copy of the site. page load times went from 2 seconds to 8-10 on busy days. support kept telling me to “optimize my plugins” which yeah sure but the underlying issue was clearly resource limits on shared hosting Finally pulled the trigger on a VPS back in november. no idea why i waited. looked at a bunch of options, digitalocean, hetzner, vultr, ishosting. ended up going with ishosting mostly because they had a US node close to where most of my clients’ customers are. picked their NY location among Tampa, Chicago, Dallas and LA in the US. $21.24/mo on annual for Medium plan, 3 cores, 4 gigs of ram, 40 gig nvme. the flat bandwidth, no surprise overage the migration was honestly the hardest part. took all weekend. moving everything over, setting up nginx, getting SSL sorted, configuring wordpress on the new stack. if youre used to cpanel this is a real learning curve. nobody talks about how much time the initial setup takes when they recommend “just get a VPS” would not recommend doing this on a friday night. seven months in though, page loads are consistently under 1.5 seconds across all sites. haven’t had a single downtime incident that I noticed. control panel is bare bones. does the job. my one real complaint is the docs are pretty thin if youre new to server stuff, I had to figure out a lot of config from random digitalocean tutorials instead, which works but isnt ideal afterall the move made sense the second the client sites started pulling real traffic. spent way too long second-guessing which was the best VPS provider for my case. for US-east stuff the node location ended up mattering way more than the brand for me. anyone pick based on something other than location? submitted by /u/Jaevir [link] [comments]

submitted by /u/nisha_n05 [link] [comments]

https://preview.redd.it/7tun4xn1um9h1.png?width=566&format=png&auto=webp&s=a837f7f048dd8970a5a159aa633ba3066b85a41c this is stupid spend half of day making new ways to block your vuls submitted by /u/McKheeper [link] [comments]

How to Migrate a Website Off DreamHost This was a mess of migration notes from moving many, many sites off Dreamhost so I’ve run it through an AI to tidy it up – apologies for the AI speak! Here you go: DreamHost is fine until the day you want to leave — then you discover that “a website” is really five loosely-coupled things (the domain, its DNS, the web files, a database, and email) living in different places that all have to move separately. Miss one and you get a half-broken site or, worse, silently lost mail. This is a repeatable recipe that gets you off DreamHost backups-first, with a clean cutover you can do one site at a time. The one rule that prevents disasters: back up everything before you touch anything, and never flip DNS until the new site is verified working on a temporary URL. Backups make it reversible; DNS is the only hard-to-undo step. 0. Inventory before you migrate You can’t migrate what you haven’t found. For every domain, answer three independent questions — they’re often hosted in three different places: Registration — where is the domain registered? Is it still in date? DNS — where are the nameservers / records hosted (DreamHost? Cloudflare? the registrar)? Hosting — where do the website and email actually get served? The decisive test for “is this live on DreamHost?”: does the live A/AAAA record point at the DreamHost server right now? bash dig +short example.com A dig +short example.com MX # where does mail go? dig +short example.com NS # who runs DNS? Many domains in a panel are already parked, moved to Cloudflare/Vercel, or dead. Those are not migration targets — note and skip them. Only domains whose live DNS still points at DreamHost need work. ⚠️ Don’t trust the panel’s “Disk Usage” column. It’s wildly wrong in both directions — I’ve seen 4 MB reported for a 363 MB site, and 100 MB for a directory that was genuinely ~4 KB. Always du -sh the real dir before planning a transfer. Build a simple inventory table you can work down: Domain Registered DNS On DH? Engine DB Email Decision example.com DreamHost DreamHost ✅ WordPress 22 MB 2 migrate parked.com GoDaddy GoDaddy ❌ — — 0 ignore 1. Pick a destination Anything that runs a container or serves static files works: Static site → a VPS + nginx, Netlify, Cloudflare Pages, S3+CloudFront, or a small box running Dokploy/Coolify. PHP + MySQL app (WordPress and most DreamHost sites) → a VPS with Docker, or a PaaS giving you a PHP container + containerised MySQL. Legacy CMS (ExpressionEngine, concrete5, phpBB) → same as PHP+MySQL, but pin the exact PHP version; these are fussier. The recipe below is the same regardless. The destination just needs to build from a repo, run the right PHP, talk to MySQL, serve HTTP, and get a free Let’s Encrypt cert. Prove the destination once on your smallest, least-important site before touching anything that matters — it shakes out every infra gotcha (DNS, certs, build config) at zero stakes. 2. Get access and scope each site over SSH DreamHost gives every site a shell user. SSH in (use a key) and scope it: bash ssh shelluser@your-server.dreamhost.com du -sh ~/example.com # real size cat ~/example.com/wp-config.php # DB name/user/pass/host + table prefix crontab -l # scheduled jobs to recreate find ~/example.com -name ‘.htaccess’ # redirects/rewrites to port to nginx Note the engine, PHP version, database(s) and real size, uploads/ media on disk (usually the bulk of the transfer), .htaccess rules, and cron jobs — or whether it’s just an empty placeholder you can drop. 3. Back everything up (the irreversible-proofing step) Do this for every site before building anything. Two artifacts each. Files — tar server-side, then pull: “`bash on DreamHost cd ~ && tar czf examplefiles$(date +%Y%m%d).tar.gz example.com/ from your machine (rsync is resumable for big trees) rsync -avz shelluser@your-server.dreamhost.com:~/example.com/ ./example.com/ “` Database — mysqldump (hosts look like mysql.example.com; creds in wp-config.php): bash mysqldump -h mysql.example.com -u dbuser -p dbname | gzip > example_db_$(date +%Y%m%d).sql.gz Verify each backup at capture — an unchecked backup isn’t a backup: bash gzip -t example_files_*.tar.gz && echo files OK zcat example_db_*.sql.gz | tail -1 # should end with “Dump completed” Save a tiny dbinfo.txt per site (DB_NAME, DB_USER, DB_HOST, table_prefix) so you don’t have to SSH back into a server you’re cancelling. Push to S3 so local backups don’t die with your laptop — and for any site you’ll delete from DreamHost, this is the durable copy: bash aws s3 sync ./backups/ s3://my-dreamhost-backups/ –storage-class STANDARD_IA For a site you’re deleting outright, the S3 copy may be the only copy. Verify the upload and enable bucket versioning before you rm anything. 4. Stand the site up on the new host bash zcat example_db_*.sql.gz | mysql newdbname # restore DB tar xzf example_files_*.tar.gz # restore files Fix the config. For WordPress, point wp-config.php at the new DB, then update the site URL so it doesn’t bounce you to the old host while testing: bash wp option update siteurl ‘https://temp-url.example.net’ wp option update home ‘https://temp-url.example.net’ wp search-replace ‘https://example.com’ ‘https://temp-url.example.net’ –skip-columns=guid Reproduce .htaccess redirects in your nginx config. If your destination is Docker, commit a small Dockerfile (php-fpm+nginx, or php:apache+WP) plus the MySQL container, with wp-content/uploads mounted in, so deploys are repeatable. For static rebuilds, export the old content (e.g. WP → Markdown via WP-CLI + pandoc), feed a static generator, preserve the old URL structure (/:slug/) so links don’t break, and drop dead dynamic bits (forms, popups). 5. Verify on a temporary URL — before DNS The safety valve. Bring the site up on a temp hostname (a *.your-paas.app URL, or a local hosts-file override) and click through it: Home, a few deep pages, an image-heavy page (did uploads come across?). Admin login (/wp-admin), search, forms, anything dynamic. View source for hard-coded http://old-host URLs that leak. Only when it genuinely works do you move on. The real domain still serves the old DreamHost site this whole time — users see no change. 6. Migrate email — separately, and most carefully Email is the highest-risk part: mailboxes hold data in no git repo and no file backup. Web files you can re-pull; a deleted inbox is gone. Work out what’s in use (real mailboxes vs. forwarders/aliases vs. autoresponders) and where MX points. Then move mailbox contents before touching MX, via IMAP-to-IMAP sync: bash imapsync \ –host1 imap.dreamhost.com –user1 you@example.com –password1 ‘OLDPASS’ \ –host2 imap.newhost.com –user2 you@example.com –password2 ‘NEWPASS’ Run once to seed, again right before cutover to catch new mail. Recreate every forwarder/alias/autoresponder by hand. Only then repoint MX (lower its TTL a day ahead), and keep the DreamHost mailboxes for a couple of weeks as a safety net while stragglers drain. 7. Cut over DNS (the one hard-to-reverse step) Lower the TTL on the records a few hours/days ahead. In DreamHost, deactivate hosting (or remove the A record) so it stops serving the old copy. Point A/AAAA at the new host’s IP — don’t forget www, subdomains, wildcards. Issue TLS — Certbot/your PaaS gets a fresh Let’s Encrypt cert once DNS resolves to the new IP. bash dig +short example.com # now resolves to the NEW ip curl -I https://example.com # expect HTTP 200 + valid cert 🔐 Cert gotcha: Let’s Encrypt only issues once public DNS actually points at the new box. Request too early and it fails — and ACME clients back off with growing delays, so retrying in a tight loop makes you wait longer. Let DNS propagate, then issue once. No rush between sites — backups protect the data; you control the pace. 8. Decommission DreamHost Work the estate bottom-up: lowest-risk sites first, busiest/email-bearing last. Each migration de-risks the next. Once a site is live elsewhere and stable: Remove the old files and DB (after confirming the offsite backup is intact). Hunt for orphan databases — apps whose website is long gone but whose DB lingers in the panel. Identify or archive them; don’t cancel with mysteries open. When nothing depends on the server — no live site, no MX, no cron — downgrade or cancel the plan. The recipe, condensed For each site: 1. confirm it’s wanted · 2. SSH-scope (size, engine, PHP, DB, .htaccess, cron) · 3. back up files + DB, verify, push to S3 · 4. restore, fix DB config + site URL, reproduce redirects · 5. verify on a temp URL · 6. migrate email (sync → recreate aliases → repoint MX) · 7. issue TLS · 8. flip DNS (the only irreversible step) · 9. confirm live · 10. decommission, then cancel the plan when nothing’s left. Migrating off any host is just inventory → back up → rebuild → verify → cut over → decommission, once per site. Do it patiently, and never flip DNS on a site you haven’t already watched working somewhere else. submitted by /u/Better_Band_2925 [link] [comments]