Tips & Tricks

WordPress Tips & Tricks on CloudSOE Images

2026-07-30 · wordpress docs

A collection of practical advice for running the CloudSOE WordPress image in production, on either cloud.

Back up the two things that matter

A WordPress site is its database plus wp-content. A simple nightly backup:

sudo mysqldump wordpress | gzip > /home/$(whoami)/wordpress-db-$(date +%F).sql.gz
sudo tar czf /home/$(whoami)/wp-content-$(date +%F).tar.gz -C /var/www/wordpress wp-content

Ship those files off the instance (S3, Azure Blob, anywhere). Cloud-level snapshots (EBS snapshots on AWS, disk snapshots on Azure) are a good belt-and-braces complement, but application-level dumps restore faster and across instance types.

Keep things updated

  • WordPress core minor releases auto-update by default; update plugins and themes from Dashboard → Updates regularly.
  • OS security updates come from Ubuntu’s repositories: sudo apt update && sudo apt upgrade on your own schedule.
  • New CloudSOE image versions are published to the marketplaces — for major moves, launch a fresh instance and restore your backup rather than upgrading in place.

Performance quick wins

  1. Enable a page cache — a caching plugin (e.g. WP Super Cache or W3 Total Cache) is the single biggest win on small instances.
  2. PHP OPcache is already active with mod_php — don’t disable it.
  3. Right-size the instance — if htop shows sustained CPU saturation or MariaDB is swapping, step up one size (t3.medium → t3.large on AWS, B2s → D2as_v4 on Azure).
  4. Offload media to S3/Azure Blob with a media-offload plugin if wp-content/uploads grows past a few GB.

Security hardening

The image already disables password SSH, removes default credentials and serves HTTPS. On top of that:

  • Install a login-protection plugin (rate-limits wp-login.php brute force).
  • Keep phpMyAdmin behind an IP allow-list in your security group / NSG, or remove it entirely.
  • Use strong, unique passwords for every WordPress account — the database password is already unique to your instance.
  • Consider Cloudflare or the cloud provider’s WAF/CDN in front of the site for TLS at the edge and bot filtering.

Troubleshooting first boot

If the site doesn’t respond a few minutes after launch:

systemctl status wordpress-firstboot
journalctl -u wordpress-firstboot --no-pager

The setup script is safe to re-run: if it failed (for example a transient metadata-service hiccup), it retries automatically on the next boot because its completion marker was never written. A manual retry is just:

sudo systemctl restart wordpress-firstboot

The MOTD shows the wrong IP

The login banner captures the public IP at first boot. If you later attach a new Elastic IP / public IP, the banner will be stale (the site itself is unaffected). Edit /etc/motd to update it.

Test HTTPS from outside

On Azure especially, a VM often cannot reach its own public IP from within. Always verify the site from your own machine:

curl -skI https://<public-ip>/

The certificate’s CN should be your public IP (or your domain once you’ve switched to Let’s Encrypt — see the configuration guide).