DEV Community: VPSPioneer

How to Move a Website to a New Host Without Downtime

VPSPioneer — Sat, 10 Oct 2026 08:57:59 +0000

Most migrations go wrong at one of two points: the site is copied while it is still changing, or DNS is switched before anyone has checked the copy. This sequence avoids both. It works for any PHP site — WordPress, Laravel, a plain HTML site — and takes an hour for a typical site, most of it waiting.

1. Lower the DNS TTL a day ahead

The TTL tells resolvers how long to remember your old IP. If it is 24 hours, some visitors keep hitting the old server for a day after you switch. Find the current value:

dig example.com A +noall +answer
# example.com.  86400  IN  A  203.0.113.10

That 86400 is the TTL in seconds. Set it to 300 at your DNS provider now, and wait at least the old TTL before doing the switch. This step is why the migration starts a day before it happens.

2. Copy the files

From the new server, pull the files over SSH. rsync only transfers what changed, so you can run it again later to catch anything modified in between:

rsync -avz --progress \
  --exclude='wp-content/cache/' \
  --exclude='*.log' \
  user@old-server:/var/www/example.com/ \
  /var/www/vhosts/example.com/httpdocs/

No SSH on the old host? Download a backup from its control panel and unpack it:

cd /var/www/vhosts/example.com/httpdocs/
tar -xzf ~/backup-example.com.tar.gz --strip-components=1

Fix ownership afterwards so PHP can write to uploads:

chown -R example_user:psacln /var/www/vhosts/example.com/httpdocs/

3. Copy the database

Dump on the old server, import on the new one. --single-transaction takes a consistent snapshot without locking tables, so the live site keeps working during the dump:

# on the old server
mysqldump --single-transaction --quick --routines \
  -u dbuser -p example_db | gzip > example_db.sql.gz

# on the new server
gunzip < example_db.sql.gz | mysql -u newuser -p new_example_db

Then update the site's config with the new credentials — for WordPress that is wp-config.php:

define('DB_NAME', 'new_example_db');
define('DB_USER', 'newuser');
define('DB_PASSWORD', 'the-new-password');
define('DB_HOST', 'localhost');

4. Test the copy before touching DNS

This is the step people skip. Tell your own computer that example.com lives at the new IP, without changing DNS for anyone else. Edit the hosts file:

# macOS / Linux
sudo nano /etc/hosts

# Windows (as Administrator)
notepad C:\Windows\System32\drivers\etc\hosts

Add a line with the new server's IP:

203.0.113.55  example.com www.example.com

Now open the site in a browser. You are looking at the new server; everyone else still sees the old one. Click through the pages, log in to the admin, upload a file, place a test order. If SSL complains, that is expected — the certificate is issued in step 5.

Remove the hosts line when you are done testing.

5. Issue the certificate on the new server

Let's Encrypt needs DNS to point at the new server to validate over HTTP — which it does not yet. Two ways round it:

DNS validation (wildcard flow in Plesk) works before the switch.
Or issue it immediately after the switch; with a 300-second TTL, that is a two-minute window of browser warnings.

We use the first. See Install a free SSL certificate in Plesk.

6. Freeze, re-sync, switch

Right before the switch, put the old site into maintenance mode or just avoid publishing for ten minutes. Run the file and database copy again so nothing written in the meantime is lost:

rsync -avz user@old-server:/var/www/example.com/ /var/www/vhosts/example.com/httpdocs/

Then change the A record (and www) to the new IP. With the TTL at 300, the world follows within five minutes. Watch it happen:

watch -n 10 'dig +short example.com A @1.1.1.1'

7. Move email and the small things

Email is what people forget. If mailboxes live on the old host, create them on the new server first, then move the messages with imapsync:

imapsync --host1 old.example.com --user1 you@example.com --password1 'old-pass' \
         --host2 mail.example.com --user2 you@example.com --password2 'new-pass'

Also check: cron jobs, .htaccess redirects, any API keys tied to the old IP, and the SPF record — it must list the new mail server or your mail lands in spam.

Keep the old server for a week

Do not cancel the old hosting the same day. Leave it running for a week so a forgotten cron or a missed mailbox can still be recovered.

Or skip all of this: every VPSPioneer plan includes free migration. Send us the old login and we run exactly this sequence for you.

Originally published at vpspioneer.com. More guides on hosting, Linux and servers: vpspioneer.com/blog.

How to Speed Up WordPress on Plesk in 20 Minutes

VPSPioneer — Thu, 08 Oct 2026 13:28:12 +0000

A slow WordPress site is almost never slow because of the server. It is slow because PHP is running on defaults, nothing is cached, and the images are the size they came off the camera. Here is the order we fix these in, from biggest win to smallest.

1. Switch to PHP-FPM and the newest PHP

In Plesk, go to Websites & Domains → PHP Settings for the domain. Set:

PHP version: the newest your plugins support. 8.3 runs typical WordPress ~30% faster than 7.4.
Run PHP as: FPM application served by nginx.

Then check the version from the command line, if you have shell access:

plesk bin domain --info example.com | grep -i php
/opt/plesk/php/8.3/bin/php -v

2. Turn on OPcache

OPcache keeps compiled PHP in memory so every request does not re-read every file. Under PHP Settings → Performance settings, or in the Additional directives box:

opcache.enable=1
opcache.memory_consumption=192
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
memory_limit=256M

revalidate_freq=60 means a file edit shows within a minute; set it to 0 on a staging site where you change code constantly.

3. Let Nginx serve static files and cache pages

Under Apache & nginx Settings, tick Serve static files directly by nginx and enable nginx caching with a 5-minute timeout. Nginx then answers the vast majority of hits without PHP starting at all.

If the site has a login area, exclude it so users never see each other's pages. In Additional nginx directives:

# Never cache logged-in users or the cart
if ($http_cookie ~* "wordpress_logged_in|woocommerce_items_in_cart") {
    set $no_cache 1;
}

Check a page is coming from cache by looking at the response headers:

curl -sI https://example.com/ | grep -i "x-cache\|cache-control"

4. Compress the images that are already uploaded

New uploads can be handled by a plugin, but the existing library is where the weight is. From a shell, convert everything to WebP alongside the originals:

cd ~/httpdocs/wp-content/uploads
find . -type f \( -iname '*.jpg' -o -iname '*.png' \) -size +100k \
  -exec sh -c 'cwebp -quiet -q 82 "$1" -o "${1%.*}.webp"' _ {} \;
du -sh .

Then let Nginx hand out the .webp when the browser accepts it:

location ~* ^/wp-content/uploads/.+\.(png|jpe?g)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
}

5. Clean the database

Post revisions, transients and spam comments accumulate for years. Once, from Databases → phpMyAdmin, or with WP-CLI:

wp post delete $(wp post list --post_type='revision' --format=ids) --force
wp transient delete --all
wp comment delete $(wp comment list --status=spam --format=ids)
wp db optimize

Then limit future revisions in wp-config.php:

define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 120);

6. Put a CDN in front

Cloudflare's free plan is enough for most sites. Point the nameservers at Cloudflare, set SSL mode to Full (strict), and turn on Auto Minify and Brotli. Static files then come from a node near the visitor rather than from London every time.

Measure before and after

Do not guess. Run the site through PageSpeed Insights before you start and after each step, and keep the numbers. The metric that matters is Largest Contentful Paint; under 2.5 seconds is the target.

Step	Typical LCP gain
PHP-FPM + PHP 8.3	0.3–0.6 s
OPcache	0.2–0.4 s
Nginx page cache	0.5–1.5 s
WebP images	0.5–2 s on image-heavy pages
Database cleanup	small, but stops slow admin pages
CDN	0.2–0.8 s for visitors far from the server

Every VPSPioneer shared plan already runs PHP-FPM with OPcache and Nginx caching on; steps 1–3 are done for you. On a managed VPS we tune all six as part of setup.

Originally published at vpspioneer.com. More guides on hosting, Linux and servers: vpspioneer.com/blog.

How to Install a Free SSL Certificate in Plesk (Let's Encrypt)

VPSPioneer — Wed, 07 Oct 2026 13:29:52 +0000

Every site should load over HTTPS. Browsers mark plain HTTP pages as "Not secure", Google uses HTTPS as a ranking signal, and a certificate from Let's Encrypt costs nothing. Plesk has the whole flow built in, so there is no command line needed for the basic case — but we will cover that too, for when you want to script it.

Before you start

You need two things in place:

The domain's A record (and www if you use it) must already point at your Plesk server. Let's Encrypt validates by fetching a file from your site, so DNS has to resolve first.
Port 80 must be reachable. If you have moved everything to 443 with a firewall rule, open 80 for the validation.

Check DNS from your own machine:

dig +short example.com A
dig +short www.example.com A

Both should print your server's IP. If they don't, wait for propagation before going further — the request will simply fail otherwise.

Issue the certificate from the panel

In Plesk, open Websites & Domains and pick the domain.
Click SSL/TLS Certificates.
Under Install a free basic certificate provided by Let's Encrypt, click Install.
Enter an email address for expiry notices, then tick:
- Secure the domain name — the site itself.
- Include a "www" subdomain — unless you have deliberately never used www.
- Secure webmail and Assign the certificate to mail domain — so your mail client stops warning about mail.example.com.
Click Get it free.

Plesk requests the certificate, installs it, and switches the site's vhost to it. Reload the domain in a browser: you should see the padlock.

Wildcard certificates

If you run many subdomains (shop.example.com, app.example.com), issue a wildcard instead so you never do this again per subdomain. Tick Secure wildcard domain (including www). This uses DNS validation: Plesk shows a _acme-challenge TXT record to add at your DNS provider. Add it, wait a minute, then click Continue. Verify the record is visible before continuing:

dig +short TXT _acme-challenge.example.com

Force HTTPS

A certificate does not redirect anyone by itself. Under Hosting & DNS → Hosting Settings, tick Permanent SEO-safe 301 redirect from HTTP to HTTPS. This is the setting that stops search engines seeing two copies of your site.

If you prefer to control it in the site itself, an .htaccess rule does the same:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

From the command line

The same operation, scriptable — handy when you set up many domains:

plesk bin extension --exec letsencrypt cli.php \
  -d example.com -d www.example.com \
  -m you@example.com --secure-mail

To list every certificate on the server with its expiry:

plesk bin certificate --list -domain example.com

Renewal

Let's Encrypt certificates last 90 days. Plesk's SSL It! extension renews them automatically about 30 days before expiry — there is nothing to schedule. The one thing that breaks renewal is the same thing that breaks issuing: DNS moved away, or port 80 closed. If you get an expiry email, that is where to look.

Common errors

Message	Cause	Fix
`Invalid response from http://example.com/.well-known/acme-challenge/...`	DNS points elsewhere, or a redirect intercepts the path	Check the A record; exclude `/.well-known/` from redirects
`Too many certificates already issued`	Rate limit: 50 per registered domain per week	Wait, or use a wildcard instead of many singles
`DNS problem: NXDOMAIN`	The subdomain has no record	Add the record and retry

On VPSPioneer shared and reseller plans this is already done for every new domain — the certificate is issued at account creation and renewed for you. On a managed VPS we set it up as part of the handover.

Originally published at vpspioneer.com. More guides on hosting, Linux and servers: vpspioneer.com/blog.

How to Set Up SSH Keys and Turn Off Password Login

VPSPioneer — Tue, 06 Oct 2026 16:33:46 +0000

A password can be guessed, phished or reused from a leak. An SSH key cannot: it is a 256-bit secret that never leaves your computer, and the server only ever sees a signature. Setting it up takes five minutes and ends password guessing against your server permanently.

1. Generate a key on your machine

macOS and Linux — in a terminal:

ssh-keygen -t ed25519 -C "you@example.com"

Windows 10/11 — the same command works in PowerShell or Windows Terminal; OpenSSH is built in.

Accept the default file location (~/.ssh/id_ed25519). Set a passphrase — it encrypts the private key on disk, so a stolen laptop does not mean a stolen server. You will be asked for it once per session, and an agent remembers it.

ed25519 is the modern choice: shorter, faster and at least as secure as a 4096-bit RSA key. Use RSA only if a very old server refuses ed25519.

You now have two files: id_ed25519 (private — never share, never copy to a server) and id_ed25519.pub (public — this is what goes on servers).

2. Put the public key on the server

The simplest way:

ssh-copy-id deploy@203.0.113.10

It logs in with your password one last time and appends the public key to ~/.ssh/authorized_keys. On Windows without ssh-copy-id:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

In Plesk, you can also paste the public key under Websites & Domains → Web Hosting Access → SSH keys for the subscription's system user.

3. Test before changing anything

Open a new terminal and connect:

ssh deploy@203.0.113.10

If it logs you in without asking for the account password (only your key passphrase, if you set one), the key works. If it still asks for the password, on the server check the permissions — SSH refuses keys in a directory that is group- or world-writable:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -la ~/.ssh

Do not go further until this works.

4. Disable passwords

On the server:

sudo nano /etc/ssh/sshd_config

Set these three lines (uncomment them if needed):

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Ubuntu may ship a file in /etc/ssh/sshd_config.d/ that re-enables passwords; check:

grep -r PasswordAuthentication /etc/ssh/sshd_config.d/

Validate and restart — keep your current session open while you do:

sudo sshd -t && sudo systemctl restart ssh    # sshd on AlmaLinux / Rocky

From a third terminal, confirm passwords are refused:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10
# Permission denied (publickey).

5. Make it convenient

An SSH config file saves typing and lets you use different keys per server. In ~/.ssh/config on your machine:

Host web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Now ssh web connects. On macOS, add UseKeychain yes under the host and the passphrase is stored in Keychain. On Windows, start the agent once: Get-Service ssh-agent | Set-Service -StartupType Automatic; Start-Service ssh-agent; ssh-add.

Several people, several keys

authorized_keys is one public key per line. Add each person's key on its own line, and remove the line when they leave — that is offboarding done. Keep a comment on each line (the -C you set when generating) so you know whose key is whose.

If you lose the private key

You cannot recover it, by design. Log in through your provider's console (VPSPioneer: the client area, or a ticket on a managed VPS), add a new public key to authorized_keys, and remove the old line. This is also why the console exists: it works without SSH at all.

With keys in place and passwords off, the next two steps in hardening a VPS — a firewall and Fail2ban — turn the ten thousand failed logins a day in your logs into zero.

Originally published at vpspioneer.com. More guides on hosting, Linux and servers: vpspioneer.com/blog.