WordPress on CloudMagnus

WordPress with the install handled. The platform's post-install scaffold downloads WordPress core via WP-CLI and writes wp-config.php with the database credentials we just provisioned. You land on the WordPress installer ready to enter your admin user.

What our scaffold installs

  • WordPress core (latest stable), downloaded via WP-CLI to your htdocs/
  • wp-config.php with database name, user, and password pre-populated. The password reaches WP-CLI via stdin, never argv, so it doesn't appear in process listings or audit logs.
  • A MySQL database scoped to your site, owned by a per-site MySQL user
  • nginx vhost configured for PHP-FPM, SSL, and the standard WordPress URL rewriting
  • FastCGI cache enabled by default (configurable per site in CloudPanel)

What you do next

  1. Visit your domain. The WordPress installer is waiting at /.
  2. Enter your site title, admin username, admin password, and admin email.
  3. Click "Install WordPress." You're done.

From there, log into /wp-admin and configure themes, plugins, content, whatever you need. Standard WordPress.

Where your files live

/home/<site-user>/
├── htdocs/                      ← document root, where WordPress lives
│   ├── wp-admin/
│   ├── wp-content/
│   │   ├── plugins/
│   │   ├── themes/
│   │   └── uploads/             ← media files
│   ├── wp-includes/
│   ├── wp-config.php            ← DB creds + salts (don't share)
│   └── index.php
└── logs/                        ← nginx + php-fpm logs for this site

The <site-user> matches what you see on your dashboard's Site Detail → SFTP User. Everything outside htdocs/ is yours but isn't web-accessible.

Deploying changes

Two paths depending on your workflow:

  • SFTP for ad-hoc edits. Connect with your site user (Site Detail → SFTP) and edit wp-content/themes/ or plugins/ directly. Standard for theme tweaks and small fixes.
  • SSH + git pull for managed deployments. Add an SSH key in CloudPanel, clone your theme/plugin repo to wp-content/themes/yourtheme, and pull on demand. Deploy hooks (e.g. via webhook + a thin script) work fine; we don't gate the SSH session.

Database access

The dashboard's Database tab shows the database name, user, and host. The password is in wp-config.php on the server (set during provisioning, not copied to our application database).

For ad-hoc queries:

  • phpMyAdmin: Site Detail → Database → "Open phpMyAdmin". Hosted by CloudPanel; runs at the IP-port URL shown on the page.
  • WP-CLI: SSH in as your site user and run wp db query "...". WP-CLI reads wp-config.php automatically.
  • mysql CLI: SSH in and run mysql -u <db-user> -p <db-name>. Password from wp-config.php.

PHP version

The wizard lets you pick PHP 8.1, 8.2, or 8.3 at site creation. Change it later from Site Detail → Overview → PHP Version. Switches take effect on the next request; no downtime.

If you bumped versions and a plugin breaks, the dashboard shows a yellow "PHP 8.x is available" notice for sites still on older PHP — but the dismiss is sticky once you've decided to stay.

Updates

WordPress core, theme, and plugin updates are managed from /wp-admin like any WordPress install. CloudMagnus doesn't auto-update WordPress core for you (we don't want to be in the position of breaking your site with an upstream change you didn't ask for).

For batch updates from the command line, SSH in and use WP-CLI: wp core update, wp plugin update --all, etc.

Backups

The platform takes a daily backup of your htdocs/ contents and your database, retained 14 days. Restore from the dashboard's Backups tab in one click. Manual backups are also available there — useful before a risky plugin update.

WordPress's own backup plugins (UpdraftPlus, BackWPup, etc.) still work; we don't replace them. If you use one, point it at off-site storage you control so you have a backup outside our retention window.

Caching

Page cache (FastCGI): enabled by default for WordPress installs. Cache invalidation happens on POST requests (logged-out comment submissions, form submissions) and via the dashboard's "Purge Cache" button. Logged-in users always bypass the cache.

Object cache: not preconfigured. Install Redis Object Cache plugin if you want one. CloudMagnus doesn't expose Redis to user sites in v1, so the plugin will fall back to file-based caching unless you install Redis yourself via SSH.

Browser cache: nginx serves static assets (CSS, JS, images, fonts) with long cache headers and immutable hashes by default.

Migrating from another host

The straightforward approach:

  1. Add the site on CloudMagnus and let it provision. You'll get a fresh empty WordPress install.
  2. On the source host: export the database (mysqldump) and download the wp-content/ directory.
  3. On CloudMagnus: SFTP-upload the wp-content/ directory, replacing the new install's empty one. Keep your existing wp-config.php — the database creds are different here.
  4. Import the database via phpMyAdmin (Database tab → "Open phpMyAdmin" → Import).
  5. Run a search-and-replace on the database for the old domain → new domain (WP-CLI: wp search-replace 'old.example' 'new.example' --all-tables). Skip the wp_users table on emails, or use --include-columns to be precise.
  6. Switch your DNS A records to point at CloudMagnus. Once propagation finishes, your site is live here.

Plugins like All-in-One WP Migration also work, but the manual route is cleaner for sites of any meaningful size.

Logs

Site Detail → Logs tab shows the recent nginx error log entries. For deeper investigation:

~/logs/nginx/error.log         ← nginx errors (404, 502, etc.)
~/logs/nginx/access.log        ← every request (huge; tail when needed)
~/logs/php-fpm/<site>.error.log ← PHP errors
/wp-content/debug.log          ← WP_DEBUG output (if WP_DEBUG_LOG enabled)

To enable WordPress's own debug log: edit wp-config.php and set WP_DEBUG, WP_DEBUG_LOG, and WP_DEBUG_DISPLAY as documented in the WordPress codex.

Common WordPress issues

"There has been a critical error on this website"

WordPress's white-screen replacement. Almost always a plugin or theme issue. Disable all plugins by SSH-renaming the directory:

cd ~/htdocs/wp-content
mv plugins plugins.disabled
mkdir plugins

Reload your site. If it works, move plugins back one at a time to find the broken one.

Permalinks return 404

Visit /wp-admin/options-permalink.php and re-save without changing anything. WordPress regenerates the rewrite rules; nginx picks them up via our vhost config. If that doesn't fix it, check that .htaccess isn't being looked for (we don't use it; nginx handles rewrites).

Can't upload large files

The platform's upload limit is 100 MB by default. For larger uploads, edit ~/.user.ini in your htdocs directory and set upload_max_filesize = 500M and post_max_size = 500M. Restart PHP-FPM via the dashboard ("Purge Cache" also reloads it) or contact support if you need to go beyond CP's per-site cap.

Locked out of wp-admin

SSH in as your site user and use WP-CLI: wp user list to see admins, wp user update 1 --user_pass='newpass' to reset. The platform never sees your WordPress admin credentials, so we can't email them to you.

WordPress is slow

Check three things in order: (1) FastCGI cache hit rate (PURGE comparison; logged-in browsers always miss); (2) plugin count (Query Monitor plugin shows per-request load); (3) DB query slowness (the same plugin shows top queries). The dashboard's Performance tab will show resource usage when monitoring is wired up; until then, the per-request profile from Query Monitor is the most useful starting point.

What CloudMagnus doesn't do for WordPress

  • Pre-install themes or plugins. You install whatever you want yourself.
  • Manage WordPress core updates. You decide when to update.
  • Run backups inside WordPress (we do server-side backups; in-WP backup plugins still work fine if you prefer them).
  • Provide WordPress-specific application support. We support the hosting; you handle the application. Theme/plugin authors handle their code.

Going further

For settings that aren't in our dashboard yet (per-site PHP-FPM tuning, deeper nginx vhost edits, additional security headers), open CloudPanel from the site detail page and use its UI directly. Anything you change there persists; we don't overwrite CP-side configuration on subsequent provisions.