Latest Hosting News on Reddit

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]

Hello, I need a free server that I can deploy one of my projects to. Not like vercel and netlify, but rather cloud server for backend and db. submitted by /u/SiteExpensive7743 [link] [comments]

Just curious on what’s your take on this. I am planning out a new side project and I keep seeing a ton of noise about how easy it is to spin up a site using an AI website builder. Part of me loves the idea of saving weeks of development time, but the skeptical side of me is worried about what happens under the hood. If you are trying to launch a business that actually needs to compete in search results and handle decent traffic, are these automated builders genuinely reliable? I am worried that the code they output might be completely bloated, heavy, and terrible for technical SEO, or that they lack the deep customization you need when your brand starts growing. For anyone who has actually launched a live business site using one of these platforms, what has your experience been? submitted by /u/MontfortTeryn_22 [link] [comments]

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

I’ve been managing websites for many years and currently operate more than 180 websites, including 5-proxy.com, vpsrated.com, and many other WordPress projects. Over the last few days, I experienced repeated Cloudflare 522 errors. At first, support told me the issue was related to my account reaching CPU limits and even suggested optimizing my websites or upgrading my hosting plan. After checking my cPanel Resource Usage, I found that my average CPU usage was only around 2–5%, memory usage was very low, and there were almost no CPU faults. When I pointed this out, support changed their explanation and said the CPU event and the missing website files were actually two separate issues. Then things became much worse. Some of my websites suddenly started showing “Index of /” because website files had disappeared. Shortly afterward, all of my websites went completely offline. Only after all of my websites were down did support finally acknowledge that there was an ongoing issue affecting the shared server and that their infrastructure team was investigating. What frustrated me the most was that, while my websites were offline and my business was being affected, I was repeatedly asked to wait, and I was even encouraged to consider upgrading to a Virtual Machine instead of receiving answers about what had happened to my websites and files. I’m not posting this to attack the company. I’m posting because this incident has affected my business, visitors, and SEO, and I still don’t have a technical explanation for: Why my website files disappeared. Why all of my websites went offline. Whether this was a server-side incident. What safeguards exist to prevent this from happening again. Has anyone else experienced a similar incident with Spaceship Hosting? If so, how was it resolved, and did they provide you with a proper root cause analysis afterward? submitted by /u/logodisgne [link] [comments]