Tips & Tricks

WooCommerce Tips & Tricks on CloudSOE Images

2026-07-30 · woocommerce docs

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

Back up the two things that matter

A WooCommerce store is its database (orders, customers, products) plus wp-content. A simple nightly backup:

sudo mysqldump wordpress | gzip > /home/$(whoami)/store-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). For a store, the database is live business data — back it up more often than a blog, and test restores.

Keep things updated

  • Update WooCommerce, other plugins and themes from Dashboard → Updates regularly, or with wp-cli: sudo -u www-data wp --path=/var/www/wordpress plugin update --all.
  • OS security updates come from the distribution’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 is the biggest win on small instances; make sure it excludes the cart, checkout and my-account pages (most WooCommerce-aware caching plugins do this automatically).
  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 product images grow past a few GB.

Security hardening

The image already disables password SSH, generates all credentials per instance and serves HTTPS. On top of that:

  • Change the generated admin password after your first login (Users → Profile, or wp user update admin --user_pass=...).
  • Get a trusted certificate before taking payments — see the configuration guide; payment gateways will not tolerate a self-signed certificate.
  • 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.

Troubleshooting first boot

If the store doesn’t respond a few minutes after launch, check both first-boot services in order:

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

The setup scripts are safe to re-run: if one 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 woocommerce-firstboot

First boot writes the standard WordPress rewrite rules to /var/www/wordpress/.htaccess. If shop, cart or my-account pages ever start returning 404 after you’ve edited that file, restore the permalink structure from Settings → Permalinks (just pressing Save regenerates the rules).

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 store itself is unaffected — but do update the site URL as shown in the configuration guide). 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 store from your own machine:

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