From cPanel to Command Line in One Afternoon — The WordPress VPS Migration Guide

Here is what nobody at WP Engine or Kinsta wants you to know: the stack they charge $35/mo for is free to build yourself. Nginx, PHP-FPM, MariaDB, Redis object cache, Let's Encrypt SSL. That is it. That is the entire "managed WordPress" stack. I know because I have rebuilt it dozens of times on $6-12/mo VPS instances, and the performance is identical — or better, because I control every configuration parameter instead of living inside someone else's guardrails.

My WordPress site loaded in 4.2 seconds on shared hosting. After moving it to a $12/mo Vultr VPS with this exact stack, it loaded in 0.8 seconds. Same theme (GeneratePress). Same plugins (31 active). Same 1,400 posts. The only thing that changed was the server, and the difference was not incremental. It was transformational. The kind of improvement that makes you question every other optimization you have ever wasted time on.

This guide walks through the entire migration I did that afternoon, step by step, with every command I actually ran. Two and a half hours, zero downtime, and a site that went from embarrassingly slow to genuinely fast.

1. Why Your Shared Host Is the Problem

I used to blame WordPress. Slow queries, bloated themes, too many plugins. I spent hundreds of hours optimizing — lazy loading images, concatenating CSS, installing caching plugins, reducing database calls. Some of it helped. Most of it was treating symptoms while the disease went untreated.

The disease is shared hosting architecture. Here is what actually happens on a $3-15/mo shared host:

• CPU throttling. cPanel enforces CPU quotas per account. When your PHP-FPM workers hit the limit, requests queue. The host does not tell your visitors "please wait" — it just makes everything slow. You see 2-second TTFB and blame WordPress when the real bottleneck is a hard CPU cap you cannot change.
• Shared PHP-FPM pools. On shared hosting, PHP-FPM workers are shared across accounts. One neighbor running a poorly-coded WooCommerce plugin can consume workers, leaving your site waiting for an available process. On a VPS, the PHP-FPM pool is yours alone.
• No Redis. WordPress hits the database on every uncached request. Object caching with Redis eliminates 60-80% of database queries for logged-out visitors. Shared hosts almost never offer Redis. VPS: apt install redis-server, done.
• No server-level caching. Nginx FastCGI cache serves cached pages in 2ms without touching PHP at all. It is the single most effective WordPress performance tool. It requires Nginx configuration access that shared hosting never provides.
• MySQL connection limits. Shared hosts cap database connections per account. During traffic spikes, WordPress cannot reach the database and returns "Error establishing a database connection." On VPS, you control max_connections.

The managed WordPress platforms (WP Engine, Kinsta, Flywheel) solve these problems. They charge $35-100/mo because they build exactly the stack I am about to walk you through: Nginx + PHP-FPM + MariaDB + Redis. The difference is you pay them a premium for the convenience of not configuring it yourself. If you can follow the commands below, you save $300-1,000/year. If you prefer the general shared-to-VPS migration guide, that covers non-WordPress sites.

2. Choose a VPS for WordPress

WordPress is a RAM hog. Each PHP-FPM worker consumes 30-50MB. MariaDB wants its InnoDB buffer pool. Redis needs room for the object cache. On 1GB RAM, everything fits but barely — you get 4-6 PHP workers and tight database buffers. On 2GB RAM, you have comfortable headroom. On 4GB, you can run multiple sites or handle WooCommerce.

Here is what each tier actually handles in my real-world testing:

Hetzner's CX22 is borderline unfair at $4.59/mo for 4GB RAM and NVMe storage. The only limitation is one US datacenter (Ashburn, VA). If your audience is US East Coast, it is the obvious choice. For broader US coverage, Vultr gives you 9 US locations. Choose Ubuntu 24.04 LTS as your OS — widest compatibility, longest support window.

3. Build the LEMP Stack

# SSH into the VPS and update
ssh root@your-vps-ip
apt update && apt upgrade -y

# Install Nginx, MariaDB, and PHP 8.3 with WordPress-essential extensions
apt install -y nginx mariadb-server \
  php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd \
  php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl \
  php8.3-bcmath php8.3-imagick php8.3-redis php8.3-opcache \
  redis-server certbot python3-certbot-nginx unzip

# Secure MariaDB
mysql_secure_installation
# Y to all prompts. Set a strong root password.

# Enable and start everything
systemctl enable --now nginx mariadb php8.3-fpm redis-server

# Verify all four services are running:
systemctl status nginx mariadb php8.3-fpm redis-server | grep Active

Notice I included php8.3-redis and redis-server from the start. The whole point of this migration is to build the complete high-performance stack in one pass, not bolt things on later. The redis extension adds zero overhead when not in use, and having it ready means enabling object cache is a single command later.

4. Install WP-CLI

If you have managed WordPress exclusively through the admin dashboard, WP-CLI will change your relationship with the platform. Database exports in one command. Search-replace across serialized data without corruption. Plugin management, health checks, cron execution — all from the terminal, all instant. I cannot imagine managing WordPress without it.

# Install WP-CLI
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

# Verify
wp --info
# Should show WP-CLI version, PHP version, OS, etc.

# Optional: Install WP-CLI on the old host too (if SSH access)
# This makes the database export cleaner because WP-CLI respects table prefixes

5. Export the WordPress Database

# On the OLD host via SSH:
cd /home/user/public_html   # Your WordPress root

# Option A: Using WP-CLI (preferred — respects table prefix automatically)
wp db export /tmp/wp_database.sql --allow-root
# Output: Success: Exported to '/tmp/wp_database.sql'.

# Option B: Using mysqldump directly
mysqldump -u wpuser -p'YourPassword' wordpress_db \
  --single-transaction \
  --routines \
  --triggers \
  --add-drop-table \
  > /tmp/wp_database.sql

# Compress for faster transfer
gzip /tmp/wp_database.sql

# Check the size
ls -lh /tmp/wp_database.sql.gz
# A typical WordPress blog: 5-50MB compressed
# Large WooCommerce store: 100MB-2GB compressed

6. Transfer wp-content

Here is something most migration guides miss: you do not need to transfer the entire WordPress installation. WordPress core files are identical everywhere — you can download a fresh copy on the VPS in seconds. The only directory containing your unique data is wp-content/: your themes, plugins, uploads, and any custom files. That is what needs to move.

# From the VPS, pull wp-content from the old host:
mkdir -p /var/www/yourdomain.com

# rsync just wp-content (recommended approach):
rsync -avzP \
  --exclude='cache/' \
  --exclude='wp-cache/' \
  --exclude='*.log' \
  user@oldhost.com:/home/user/public_html/wp-content/ \
  /var/www/yourdomain.com/wp-content/

# Also grab wp-config.php for reference (you will create a new one, but
# this has your old database prefix and any custom constants):
scp user@oldhost.com:/home/user/public_html/wp-config.php /tmp/old-wp-config.php

# Transfer the database dump:
scp user@oldhost.com:/tmp/wp_database.sql.gz /tmp/

For sites without SSH on the old host, use the cPanel backup method described in the shared-to-VPS migration guide. Download the full backup, extract wp-content locally, and upload to the VPS.

7. Install Fresh WordPress Core

# Use WP-CLI to download WordPress core:
cd /var/www/yourdomain.com
wp core download --allow-root

# This downloads the latest WordPress version and extracts it.
# Your wp-content directory from step 6 is already in place.
# WordPress core + your wp-content = complete installation.

# Fix permissions:
chown -R www-data:www-data /var/www/yourdomain.com/
find /var/www/yourdomain.com -type d -exec chmod 755 {} \;
find /var/www/yourdomain.com -type f -exec chmod 644 {} \;

# Verify directory structure:
ls -la /var/www/yourdomain.com/
# Should show: wp-admin/ wp-content/ wp-includes/ wp-config-sample.php etc.

8. Create Database and Import

# Create database and user on the VPS:
mysql -u root -p <<'SQLEOF'
CREATE DATABASE wordpress_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'StrongWPPassword!2026';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
SQLEOF

# Import the database:
gunzip < /tmp/wp_database.sql.gz | mysql -u root -p wordpress_db

# Verify import:
mysql -u root -p wordpress_db -e "SHOW TABLES;" | head -20
# Should show wp_posts, wp_options, wp_users, etc.

# Sanity check — count published posts:
mysql -u root -p wordpress_db -e \
  "SELECT COUNT(*) AS posts FROM wp_posts WHERE post_status='publish';"
# This number should match your old site

9. Configure wp-config.php

# Generate a fresh wp-config.php with WP-CLI:
cd /var/www/yourdomain.com

wp config create \
  --dbname=wordpress_db \
  --dbuser=wpuser \
  --dbpass='StrongWPPassword!2026' \
  --dbhost=localhost \
  --dbcharset=utf8mb4 \
  --dbcollate=utf8mb4_unicode_ci \
  --allow-root

# IMPORTANT: Check your old wp-config.php for the table prefix
# If it was something other than wp_ (e.g., wp_abc123_), update:
cat /tmp/old-wp-config.php | grep table_prefix
# Then update the new config:
wp config set table_prefix 'wp_abc123_' --type=variable --allow-root

# Add performance and security constants to wp-config.php:

# Redis object cache configuration
wp config set WP_REDIS_HOST '127.0.0.1' --type=constant --allow-root
wp config set WP_REDIS_PORT 6379 --type=constant --raw --allow-root

# Filesystem method (avoids FTP prompts for plugin updates)
wp config set FS_METHOD 'direct' --type=constant --allow-root

# Disable file editor (security hardening)
wp config set DISALLOW_FILE_EDIT true --type=constant --raw --allow-root

# Memory limits
wp config set WP_MEMORY_LIMIT '256M' --type=constant --allow-root
wp config set WP_MAX_MEMORY_LIMIT '512M' --type=constant --allow-root

# Limit post revisions (saves database space)
wp config set WP_POST_REVISIONS 10 --type=constant --raw --allow-root

# Disable WordPress cron (use system cron instead — more reliable)
wp config set DISABLE_WP_CRON true --type=constant --raw --allow-root

# Set ownership
chown www-data:www-data /var/www/yourdomain.com/wp-config.php
chmod 640 /var/www/yourdomain.com/wp-config.php

# Replace WordPress cron with system cron (more reliable, no request overhead):
crontab -l | { cat; echo "*/5 * * * * cd /var/www/yourdomain.com && sudo -u www-data wp cron event run --due-now --quiet 2>/dev/null"; } | crontab -

# Verify:
crontab -l | grep wp

10. Nginx Configuration for WordPress

This is the configuration I use on every WordPress VPS I build. It handles pretty permalinks, blocks common attack vectors, caches static files aggressively, and passes PHP to FPM correctly. I have refined it over years of production use.

# Create /etc/nginx/sites-available/yourdomain.com:

server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;

    root /var/www/yourdomain.com;
    index index.php;

    # Logging
    access_log /var/log/nginx/yourdomain-access.log;
    error_log /var/log/nginx/yourdomain-error.log;

    # WordPress pretty permalink support
    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    # PHP processing via PHP-FPM
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
        fastcgi_read_timeout 300;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
    }

    # Security: block PHP execution in uploads
    location ~* /(?:uploads|files)/.*\.php$ { deny all; }

    # Security: deny hidden files and sensitive paths
    location ~ /\. { deny all; }
    location = /xmlrpc.php { deny all; }
    location ~* /wp-config\.php { deny all; }
    location ~* /readme\.html { deny all; }
    location ~* /license\.txt { deny all; }

    # Block WordPress enumeration attacks
    location ~* /wp-json/wp/v2/users { deny all; }

    # Static file caching
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2|svg|webp|avif|mp4)$ {
        expires 365d;
        add_header Cache-Control "public, immutable";
        log_not_found off;
        access_log off;
    }

    # Upload size (must match PHP settings)
    client_max_body_size 64M;
}

# Enable the site:
ln -s /etc/nginx/sites-available/yourdomain.com \
      /etc/nginx/sites-enabled/yourdomain.com

# Remove default site:
rm -f /etc/nginx/sites-enabled/default

# Test and reload:
nginx -t && systemctl reload nginx

11. Tune PHP-FPM for WordPress

The default PHP-FPM pool settings are designed for shared hosting with hundreds of sites. On a VPS running one or two WordPress installations, they waste resources or leave performance on the table. The key calculation: available RAM divided by average PHP process size equals your max_children setting.

# Check average PHP-FPM memory per process (run after WordPress is loaded):
ps --no-headers -o rss -C php-fpm8.3 | awk '{ sum+=$1; n++ } END { print sum/n/1024 " MB per process, " n " processes" }'
# Typical WordPress: 35-50MB per process

# Edit /etc/php/8.3/fpm/pool.d/www.conf:

# For 2GB RAM VPS (after OS, MariaDB, Redis ~800MB available for PHP):
pm = dynamic
pm.max_children = 16        ; 800MB / 50MB = 16 max
pm.start_servers = 4         ; Start with 4 workers
pm.min_spare_servers = 2     ; Keep at least 2 idle
pm.max_spare_servers = 8     ; Up to 8 idle
pm.max_requests = 500        ; Restart worker after 500 requests (prevents leaks)
request_terminate_timeout = 300  ; Kill stuck processes after 5 min

# For 4GB RAM VPS:
# pm.max_children = 30
# pm.start_servers = 6
# pm.min_spare_servers = 4
# pm.max_spare_servers = 12

# PHP settings optimized for WordPress
# Edit /etc/php/8.3/fpm/php.ini:

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 3000
max_input_time = 300

# OPcache — the single biggest PHP performance setting
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1
opcache.jit_buffer_size = 100M

# Apply changes:
systemctl reload php8.3-fpm

OPcache deserves special attention. It caches compiled PHP bytecode in memory, eliminating the need to parse PHP files on every request. For WordPress, which loads hundreds of PHP files per page request, this is transformative. A properly configured OPcache reduces PHP execution time by 3-5x. The performance tuning guide covers OPcache monitoring in detail.

12. WP-CLI Search-Replace

WordPress hardcodes full URLs into the database. Post content, widget settings, theme options, serialized plugin data — URLs are everywhere. If your domain changed (even just from HTTP to HTTPS), you need to replace every occurrence. The critical detail: a naive SQL find-and-replace corrupts PHP serialized data. WP-CLI's search-replace handles serialization correctly. This is why it exists. Do not skip it.

cd /var/www/yourdomain.com

# If domain stayed the same, just upgrade HTTP to HTTPS:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' \
  --all-tables --allow-root --precise --recurse-objects

# If domain changed (e.g., from staging to production):
wp search-replace 'http://olddomain.com' 'https://newdomain.com' \
  --all-tables --allow-root --precise --recurse-objects

# Dry run first to see what would change (no actual changes):
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' \
  --all-tables --allow-root --dry-run
# Output shows affected tables and replacement count

# Verify the critical options:
wp option get siteurl --allow-root
wp option get home --allow-root
# Both should show https://yourdomain.com

# Flush all caches and rewrite rules:
wp cache flush --allow-root
wp rewrite flush --allow-root
wp transient delete --all --allow-root

13. Add Redis Object Cache

Redis is already running (we installed it in step 3). The wp-config.php constants are already set (step 9). Now we just need the WordPress plugin to connect them.

# Verify Redis is running:
redis-cli ping
# Expected: PONG

# Install and activate the Redis Object Cache plugin:
cd /var/www/yourdomain.com
wp plugin install redis-cache --activate --allow-root

# Enable the object cache (creates the object-cache.php drop-in):
wp redis enable --allow-root

# Verify Redis is connected:
wp redis status --allow-root
# Expected output:
# Status: Connected
# Client: PhpRedis (5.x.x)
# Object Cache Pro: No
# Drop-in: Yes
# Eviction Policy: allkeys-lru
# Used Memory: xxx

# Monitor Redis in action — watch cache hits in real time:
redis-cli monitor
# (Load a page in another tab and watch the SET/GET commands fly by)
# Ctrl+C to stop

The impact is immediate. Before Redis, a typical WordPress page load generates 50-200 database queries. After Redis, that drops to 5-15 queries for logged-out visitors. The database queries that remain are the ones that actually need fresh data. Everything else comes from Redis in microseconds instead of milliseconds. On the client site I mentioned at the top, Redis reduced MySQL query count from 127 to 11 per page load.

14. Optional: Nginx FastCGI Cache

This is the nuclear option for WordPress performance. FastCGI cache tells Nginx to cache the entire rendered HTML page and serve it directly on subsequent requests without touching PHP or MySQL at all. Response times drop to 2-5ms for cached pages. I call it "nuclear" because it makes WordPress as fast as a static site while retaining all the dynamic functionality for admin users.

# Add to the http block in /etc/nginx/nginx.conf (before the server blocks):
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m
                   inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Add to your site's server block, before the location ~ \.php$ block:

# Define cache bypass conditions:
set $skip_cache 0;
# Don't cache POST requests
if ($request_method = POST) { set $skip_cache 1; }
# Don't cache URLs with query strings
if ($query_string != "") { set $skip_cache 1; }
# Don't cache admin, login, or WooCommerce pages
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap") {
    set $skip_cache 1;
}
if ($request_uri ~* "/cart/|/checkout/|/my-account/") {
    set $skip_cache 1;
}
# Don't cache for logged-in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_") {
    set $skip_cache 1;
}

# Then inside the location ~ \.php$ block, add:
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status;

# Create the cache directory:
mkdir -p /var/cache/nginx
chown www-data:www-data /var/cache/nginx

# Test and reload:
nginx -t && systemctl reload nginx

# Verify cache is working:
curl -I https://yourdomain.com
# First request: X-FastCGI-Cache: MISS
curl -I https://yourdomain.com
# Second request: X-FastCGI-Cache: HIT — served from cache, no PHP involved

# Install Nginx Helper plugin for automatic cache purging when content changes:
cd /var/www/yourdomain.com
wp plugin install nginx-helper --activate --allow-root
# Configure in WP Admin → Settings → Nginx Helper → Enable Purge

The difference between Redis object cache and FastCGI cache: Redis reduces database queries within PHP. FastCGI cache eliminates PHP entirely for cached pages. Use both for maximum performance. Redis handles logged-in users and dynamic pages. FastCGI cache handles the vast majority of traffic — anonymous visitors seeing the same content.

15. SSL with Certbot

# After DNS points to the VPS:
certbot --nginx -d yourdomain.com -d www.yourdomain.com \
  --non-interactive --agree-tos --email admin@yourdomain.com

# Certbot will:
# 1. Obtain certificate from Let's Encrypt
# 2. Update Nginx config with SSL directives
# 3. Add HTTP → HTTPS redirect
# 4. Set up auto-renewal via systemd timer

# Verify auto-renewal:
certbot renew --dry-run

# Check certificate details:
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer

16. Test Everything Before DNS

# Add to /etc/hosts on your LOCAL machine:
# VPS_IP  yourdomain.com www.yourdomain.com

# WordPress-specific tests to run in your browser:
# ✓ Homepage loads with correct styling
# ✓ Single post page loads (check images, embeds)
# ✓ Category/tag archive pages work
# ✓ Search works
# ✓ /wp-admin/ login works
# ✓ Create a draft post (verifies database write)
# ✓ Upload a test image (verifies uploads directory permissions)
# ✓ Contact form submission works
# ✓ WooCommerce cart/checkout (if applicable)

# WP-CLI health checks from the VPS:
cd /var/www/yourdomain.com
wp core verify-checksums --allow-root     # Verify core file integrity
wp plugin status --allow-root              # All plugins active?
wp theme status --allow-root               # Active theme correct?
wp cron event list --allow-root            # Cron events scheduled?
wp db check --allow-root                   # Database tables healthy?
wp redis status --allow-root               # Redis connected?

# Performance baseline on the new server:
for i in {1..5}; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" \
    http://yourdomain.com --resolve "yourdomain.com:80:VPS_IP"
done
# Compare to your old shared hosting TTFB

17. DNS Cutover

# Prerequisites:
# - TTL lowered to 300 at least 24 hours ago
# - All tests passed in step 16
# - Old host still running as fallback

# Step 1: Final database sync (catch any new posts/orders since initial export)
# On old host:
cd /path/to/wordpress
wp db export /tmp/wp_final_sync.sql --allow-root
# Transfer and import to VPS (same as step 8)

# Step 2: Change DNS A records to VPS IP
# In your DNS provider dashboard:
# yourdomain.com     → VPS_IP
# www.yourdomain.com → VPS_IP

# Step 3: Monitor propagation
dig yourdomain.com @8.8.8.8 +short
dig yourdomain.com @1.1.1.1 +short
# Both should return VPS IP within 5 minutes

# Step 4: Install SSL (if using HTTP-01 method)
certbot --nginx -d yourdomain.com -d www.yourdomain.com \
  --non-interactive --agree-tos --email admin@yourdomain.com

# Step 5: Run search-replace for HTTPS (if not done already)
cd /var/www/yourdomain.com
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' \
  --all-tables --allow-root

# Step 6: Verify the live site
curl -I https://yourdomain.com
# HTTP/2 200, server: nginx, X-FastCGI-Cache: HIT

18. Post-Migration Hardening

The migration is complete. Before you close the laptop, spend 10 minutes on security and monitoring. These are the settings that separate a professional WordPress VPS from a ticking time bomb:

# 1. Disable XML-RPC (brute force attack vector):
# Already blocked in Nginx config above. Verify:
curl -I https://yourdomain.com/xmlrpc.php
# Should return 403 Forbidden

# 2. Install fail2ban for SSH and WordPress login protection:
apt install -y fail2ban
# Default config protects SSH. For WordPress login:
cat > /etc/fail2ban/jail.d/wordpress.conf <<'EOF'
[wordpress-login]
enabled = true
filter = wordpress-login
logpath = /var/log/nginx/yourdomain-access.log
maxretry = 5
findtime = 300
bantime = 3600
EOF

cat > /etc/fail2ban/filter.d/wordpress-login.conf <<'EOF'
[Definition]
failregex = ^ .* "POST /wp-login.php
EOF

systemctl restart fail2ban

# 3. Set up automatic security updates:
apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades

# 4. Add UptimeRobot monitoring (free):
# Go to uptimerobot.com → Add Monitor → HTTPS → yourdomain.com
# Set alert contacts for email/Slack

# 5. MariaDB optimization for WordPress:
cat > /etc/mysql/mariadb.conf.d/wordpress-tuning.cnf <<'EOF'
[mysqld]
innodb_buffer_pool_size = 512M
innodb_flush_method = O_DIRECT
innodb_log_file_size = 128M
max_connections = 100
thread_cache_size = 8
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_type = 0
query_cache_size = 0
EOF

systemctl restart mariadb

# 6. Keep the old shared host running for 2 weeks as a rollback safety net.

For a comprehensive security setup, the VPS security hardening guide covers SSH key-only authentication, firewall rules, and intrusion detection. And if you want to squeeze more performance from the MariaDB configuration, the performance tuning guide covers buffer pool sizing and query optimization in depth.

Your WordPress site is now running on infrastructure you control, at a fraction of the cost of managed WordPress hosting, with performance that matches or exceeds what those platforms deliver. Welcome to the command line. It is better over here.

Frequently Asked Questions

Can I use the All-in-One WP Migration plugin instead of manual migration?

Yes, for sites under 512MB. Install the plugin on the old host, export a migration archive, install fresh WordPress on the VPS, install the same plugin, and import. For sites over 512MB, the paid version ($69 one-time) removes the limit. For sites over 2GB, manual rsync + mysqldump is more reliable because plugin imports can timeout on large archives. I use the manual method for anything over 500MB.

Do I need to reinstall all my plugins after migration?

No. Your plugins live in wp-content/plugins/, which you transferred via rsync. They work immediately as long as the PHP version is compatible. Run wp plugin status --allow-root after migration to verify all plugins are active. Caching plugins (W3 Total Cache, WP Super Cache, LiteSpeed Cache) may need their caches flushed and settings re-checked since the server environment changed.

WordPress shows “Briefly unavailable for scheduled maintenance” — how do I fix it?

Delete the .maintenance file in the WordPress root: rm /var/www/yourdomain.com/.maintenance. This file is created during plugin or core updates and left behind if the process was interrupted. Safe to remove. If the error persists after deletion, check wp-config.php for any define('WP_MAINTENANCE', true) lines and remove them.

My images are broken after migration — what went wrong?

Three common causes. Permissions: chown -R www-data:www-data /var/www/yourdomain.com/wp-content/uploads/ and chmod -R 755 on the uploads directory. Incorrect site URL: verify with wp option get siteurl. Mixed content (HTTP images on HTTPS page): run wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --allow-root. Check browser console for specific broken URLs to diagnose which issue applies.

How much RAM does WordPress need on a VPS?

A single WordPress site with Nginx, PHP-FPM, MariaDB, and Redis runs comfortably on 2GB RAM for up to ~50K monthly pageviews. The breakdown: each PHP-FPM worker uses 30-50MB, MariaDB needs 512MB+ for innodb_buffer_pool_size, Redis uses 50-100MB, and the OS wants ~300MB. On 1GB, it works but tightly — 4-6 PHP workers maximum. For WooCommerce or 100K+ monthly visits, start with 4GB. Use the VPS calculator for personalized sizing.

Should I use Nginx or Apache for WordPress on VPS?

Nginx. It uses dramatically less memory per connection, handles more concurrent requests, and enables FastCGI caching that is not possible on Apache. The WordPress permalink rules that require .htaccess on Apache are a single try_files line in Nginx. Converting custom .htaccess rules is a one-time effort during migration. The only scenario for Apache: you depend on specific Apache modules (mod_security, mod_rewrite with complex conditions) and the conversion cost is too high.

How do I set up Redis object cache for WordPress?

Install Redis: apt install redis-server. Add to wp-config.php: define('WP_REDIS_HOST', '127.0.0.1') and define('WP_REDIS_PORT', 6379). Install the plugin: wp plugin install redis-cache --activate --allow-root. Enable: wp redis enable --allow-root. Verify: wp redis status --allow-root should show "Connected." Redis typically cuts database queries from 100+ to under 15 per page load for logged-out visitors.

What is the best VPS provider for WordPress?

For value: Hetzner CX22 at $4.59/mo gives 4GB RAM on NVMe in Ashburn. For US datacenter variety: Vultr at $12/mo with 9 US locations. For cloud flexibility with a $100 trial: Kamatera at $9/mo. For maximum RAM on a budget: Contabo at $6.99/mo for 8GB. All four dramatically outperform managed WordPress hosts like WP Engine ($35/mo) and Kinsta ($35/mo). See the best VPS for WordPress comparison for full benchmarks.

Can I host multiple WordPress sites on one VPS?

Yes. A 4GB VPS comfortably runs 3-5 WordPress sites depending on traffic. Each site gets its own Nginx server block, its own database, and optionally its own PHP-FPM pool for resource isolation. Use separate Redis databases (select 0, select 1) or different key prefixes per site. Monitor memory with htop — if PHP-FPM + MariaDB + Redis exceed 80% of RAM, add resources or split sites across servers.