Home > Control panel > Your Woop! Host stack

Your site. Your tools. A managed stack underneath.

Know what runs your site
and how to get the best from it.

example.com runs on its own virtual machine. You get WordPress, SSH, SFTP, WP-CLI and database access. We manage the web, database, caching, certificate, backup and monitoring layers.

Open your hosting panel Connect to your site

Woop! Host at a glance

  • 01One site per virtual machine
  • 02Daily backup before updates
  • 03Layered page and object caching
  • 04Real shell and file access
About this guide This page describes the current Woop! Host setup. Use Reinstall software stack in your hosting panel to add the current stack features to an older site. The reinstall takes a protected backup and keeps your site content. See the recent changes.

Choose the way you work

Your hosting panel, then four ways into the site

The panel shows the platform around WordPress. Use the four site tools for publishing, files, commands and engineering work.

Your site control panel

See and manage the whole site from one page.

Open status, access, troubleshooting and lifecycle controls for example.com.

Open the hosting panel
  • Domains and DNSValidate DNS, change the site domain, or use the permanent site-xxxx.woop.host address.
  • Site accessReset the administrator password or create a separate temporary administrator for 24 hours.
  • Browser troubleshootingRead recent NGINX, PHP-FPM and WordPress error logs without signing in to the server.
  • Site facts and controlsSee PHP, disk use, stack version and data centre. Refresh status, restart services or reinstall the stack.
01

WordPress

Publish, design and manage plugins through the familiar wp-admin screens.

Open wp-admin on your site
02

SSH and WP-CLI

Run updates, inspect the site and make precise changes as the owner of the files.

See shell access
04

Resident Engineer

Choose Claude Code or Codex, then ask in plain English. Both know this stack and use the same playbooks for safe changes and troubleshooting.

Meet the engineer

Under the hood

A fast path in. Clear boundaries all the way down.

A normal page request moves through specialist layers. Each layer has one job and only the access it needs.

Visitor Browser HTTPS request
Secure edge NGINX + TLS Encryption and static files
Page cache Varnish Fast anonymous visits
Application PHP-FPM Runs WordPress + microcache
Site WordPress Themes, plugins and content
Data MariaDB + Redis Durable data and object cache
Fast

Cache without stale admin work

Varnish serves anonymous visits quickly. Logged-in sessions, carts and wp-admin bypass page caching. WordPress purges cached pages when content changes.

Isolated

One customer, one machine

Your site does not share a filesystem, database or traffic budget with another customer's WordPress installation.

Contained

Access stops at your site

Your shell is powerful inside the site and deliberately cannot manage the operating system, services or another account.

Managed

The infrastructure is our job

We maintain PHP, the database, caching, certificates, monitoring, backups and system security updates.

Part one

Work with your site

Your website is ready to use. These are tools, not setup steps you have missed.

SSH access and WP-CLI

A real shell, already pointed at your WordPress installation.

ssh wpuser@example.com

You see your site and your own files. The shell is jailed, so you cannot see or change the web server, database service, caches, certificates or anyone else's processes.

Your site is still yours, including the right to break it. You can edit, overwrite and delete files you own. Backups and the Resident Engineer give you practical ways back if a change goes wrong.

Available in your shell

wp, php, mysql, mysqldump, git, svn, composer, curl, rsync, tar, zip, editors, tmux and image tools.

Managed by us

System packages, services, PHP versions, database configuration, TLS, caching and operating-system security.

WP-CLI already knows the site path. You do not need --path:

wp plugin list wp theme install some-theme.zip --activate wp search-replace 'http://old' 'https://new' --dry-run

WP-CLI runs as the owner of the files. It can install themes and plugins without granting web code write access to PHP.

SFTP — secure file transfer

Use SFTP over port 22. Do not select FTP or FTPS in your client.

ProtocolSFTP / SSH File Transfer
Port22
Usernamewpuser
Website/var/www/wordpress

You start in your home directory. Files arrive owned by you. Some clients, archives and rsync commands can give uploaded files the wrong group. If WordPress then says a theme or plugin is missing, use the permissions repair.

Database access

Use Adminer for quick browser work, or tunnel a desktop client over SSH.

Browser

Adminer

example.com/db

Useful for a quick look, export or migration import.

Desktop client

SSH tunnel

ssh -N -L 3307:localhost:3306 wpuser@example.com

Connect the client to 127.0.0.1:3307. Database credentials are in wp-config.php.

The database is not open to the internet. From your site shell, run mysql to connect over the local socket.

The Resident Engineer

Claude Code and Codex are WordPress specialists that already know this stack and can inspect, back up, change and verify your site.

Start a persistent customer session directly from your computer:

ssh -t wpuser@example.com claude ssh -t wpuser@example.com codex

If you are already connected over SSH, run claude or codex. Both clients run as wpuser, so their operating boundary is the same as yours.

Describe the outcome in ordinary language, or invoke a bundled skill for a particular playbook. In Claude Code, use /wphost-backup. In Codex, use $wphost-backup. Run /skills in Claude Code to see the complete current list.

Understand and diagnose

wphost-site-report · wphost-troubleshoot

Inventory the site and pending updates, or work methodically through errors, outages and plugin conflicts.

Change safely

wphost-backup · wphost-safe-update

Create a protected restore point, then update one component at a time and check the site after each change.

Review site health

wphost-performance-audit · wphost-security-audit

Find database, media and caching bottlenecks, or produce a read-only integrity and security report.

Move a site

wphost-migrate-export · wphost-migrate-import

Build and verify a migration bundle, transfer it safely, import it, repair permissions and check the result.

Build and edit

wphost-child-theme · wphost-content-ops

Keep theme customizations update-safe, or make reviewed bulk content and URL changes with a dry run first.

Verify and recover

wphost-visual-check · wphost-exploit-recovery

Check responsive rendering in managed Chromium, or investigate a suspected compromise before cleanup.

Sign in with your own supported Claude, ChatGPT or API account. Your persistent login and local session history stay in your server home directory. Relevant file content and command output go to your selected model provider. Do not steer either client at credentials, customer records or secrets.

Guest sign-in. Claude asks whether you have a Claude setup token or an Anthropic API key. Codex starts ChatGPT device login. Open the displayed URL on your own computer and enter the one-time code.

Create a Claude setup token on your own trusted computer with claude setup-token. Do not create it from the client's persistent Claude login.

To use an API key, ask the remote command to read it without echo:

ssh -t wpuser@example.com claude-guest --prompt-api-key ssh -t wpuser@example.com codex-guest --prompt-api-key

Use --prompt-token instead for a Claude setup token or Codex access token. Do not put the credential in the SSH command. A variable before ssh remains local and does not normally reach the guest command.

Codex may warn that it cannot create PATH aliases in its temporary directory. The warning is expected because the managed codex command is already available. Run claude-guest --help or codex-guest --help for all options.

It is an engineer, not an oracle. Read proposed destructive actions before approving deletion, user changes or publishing. The platform guidance asks it to back up before risky work and verify the site afterwards.

Moving an existing site in

Bring files, import the database, replace the old URL, then verify the result.

  1. 1
    Move the files

    Use SFTP, rsync or SSH from the old host.

  2. 2
    Import the database

    Use Adminer, mysql or WP-CLI.

  3. 3
    Update URLs safely

    Run wp search-replace with --dry-run first.

  4. 4
    Check permissions and behavior

    Repair ownership, then test public pages and wp-admin.

For a Woop!-to-Woop! move, the two Resident Engineers can coordinate the transfer after you approve it. The destination creates restricted, expiring SSH trust. The source builds a manifest and bundle. The destination then pulls, verifies, imports and checks the site. Private keys never move between the sites.

Woop! Host also specialises in migrations from exploited sites. The security and exploit-recovery skills inspect the imported copy, replace compromised software and verify the site before it goes live on the current stack.

Part two

Care and maintenance

The routine server work is automated. These sections show where you still make the decisions.

Backups and restores

Protected daily history plus self-service backup, comparison, staging, export and guarded live restore.

DailyAutomatic backup cadence
~30 daysNormal history
10 daysMinimum history for large backups
Read-onlySite access to managed backups

Extra backups run before a stack reinstall, before risky Resident Engineer work, and whenever you or we request one. Managed history lives outside the website folder, where WordPress cannot alter or delete it.

The helper is installed at /usr/local/bin/wphost-backups.sh and is also available by its short name. Start by listing recent runs. Each successful run has a stable run ID:

wphost-backups.sh info wphost-backups.sh list --limit 10
Take a backup now

Create a named restore point

wphost-backups.sh backup --reason "before plugin change"

The request waits for the protected files-and-database backup to finish.

See what changed

Compare a run with the current site

wphost-backups.sh diff --run RUN-ID --names

Scope the comparison with --plugin, --theme, --path, --uploads, --db or --table.

Inspect safely

Restore into your home directory

wphost-backups.sh restore --run RUN-ID --plugin plugin-name

Staging is the default. The live site is unchanged and the restored content lands under ~/restores.

Keep or download a copy

Export files and database

wphost-backups.sh export --run RUN-ID

The portable archive lands under ~/backups/wphost/exports and uses your disk space.

Restore the live site

Use the run ID from list throughout the review and restore. Preview a full files-and-database restore first:

wphost-backups.sh restore --run RUN-ID --live --exact --dry-run # After you review the dry run: wphost-backups.sh restore --run RUN-ID --live --exact --yes

Use --merge to keep files created after the backup, or --exact to make the selected file scope match history. Instead of a run ID, --at-or-before 7D selects by time and --with-reason "label" selects the newest exact reason match. A bare date means midnight at the start of that date.

Automatic updates

The Auto-updates switch beside each plugin and theme controls whether the daily pass updates that item.

  1. 01
    Back up files and database

    A restore point exists before anything changes.

  2. 02
    Update WordPress core

    Core is brought up to the current release.

  3. 03
    Update opted-in plugins and themes

    Only items with WordPress auto-update enabled are included.

  4. 04
    Repair file permissions

    The stack checks ownership after the update work.

Plugins and themes present when a site is built normally start with auto-update enabled. A plugin installed later follows WordPress's default, which is off. Check the Plugins screen after adding one.

Scheduled posts, WooCommerce jobs and plugin cron run from the server every five minutes. They do not depend on a visitor arriving at the right moment.

Email from your site

Mail attempts are traceable without recording message bodies.

For each attempt and its result, the stack records the time, hostname, recipients, the first 200 characters of the subject, headers, attachment count and the PHP call chain that led to the send. Message bodies are never recorded.

The log is outside the website and survives a site's software stack reinstall. It identifies the plugin and function behind unexpected mail. Disable all tracing with WPHOST_MAIL_TRACE, or only the call chain with WPHOST_MAIL_TRACE_BACKTRACE.

To route mail through your own provider, add all five constants to wp-config.php:

define( 'WPHOST_SMTP_HOST', 'smtp.example.com' ); define( 'WPHOST_SMTP_PORT', 587 ); define( 'WPHOST_SMTP_USER', 'wordpress@example.com' ); define( 'WPHOST_SMTP_PASS', 'your-smtp-password' ); define( 'WPHOST_SMTP_USER_DISPLAYNAME', 'Example Website' );

A partial configuration is ignored. Port 465 uses implicit TLS; other ports use STARTTLS. A provider with correctly configured SPF, DKIM and DMARC gives mail the best chance of arriving.

Example: Gmail

Gmail is practical for low-volume site mail. Google prefers OAuth, which this built-in configuration does not support. To use these constants, turn on 2-Step Verification and create a separate Google app password. Do not put your normal Google Account password in wp-config.php.

define( 'WPHOST_SMTP_HOST', 'smtp.gmail.com' ); define( 'WPHOST_SMTP_PORT', 587 ); define( 'WPHOST_SMTP_USER', 'your-account@gmail.com' ); define( 'WPHOST_SMTP_PASS', 'your-16-digit-app-password' ); define( 'WPHOST_SMTP_USER_DISPLAYNAME', 'Example Website' );

Use your complete Gmail or Google Workspace email address. The authenticated address becomes both the From address and bounce address. Some managed Workspace, security-key-only and Advanced Protection accounts do not offer app passwords.

Software installed with your site

A small visible plugin plus must-use components connect WordPress to the managed platform.

ComponentWhat it doesYour control
Woop! Host default settings Suppresses routine successful-update email and provides SMTP configuration. Visible in Plugins. You can deactivate it.
Filesystem access notice Replaces an unusable FTP path with guidance and the correct panel link. A must-use plugin, readable in wp-content/mu-plugins.
Mail tracing Records delivery metadata and the originating code path, never the message body. A must-use plugin with tracing controls in wp-config.php.
Cache integrations Coordinates WordPress object and page caches, including cache purges after changes. Automatic. Content changes purge affected cached pages.

Must-use plugins load automatically and do not appear in the normal Plugins list. They do not collect visitor data or send site data elsewhere. You can inspect their files over SSH or SFTP.

Woop! Host

We handle the platform.

The virtual machine, PHP, database, web server, caches, certificates, backups, monitoring and system updates.

You

You shape the website.

Your content, themes, plugins, users and the choices you make in wp-admin.

The hosting panel exposes platform status and recent logs. The Resident Engineer can investigate the WordPress side in plain English.

Part three

When something works differently

Each answer stands alone because these links often reach customers in the middle of a problem.

“This site needs web code write access first”

You tried to install or update code in wp-admin while the stronger read-only-code posture was active.

This site needs web code write access first

New sites begin with web code write access while you build them. WordPress can install themes and plugins normally. If you later choose the stronger posture, PHP can run your code but cannot rewrite plugin or theme files.

This blocks a common persistence path: vulnerable plugin code can be exploited, but the PHP process cannot leave a new executable backdoor in the code directories. The trade-off is that browser installs need a temporary grant.

A

Grant temporary access in your hosting panel. Return to wp-admin and install normally.

B

Install with WP-CLI. It runs as the file owner and needs no grant.

C

Upload over SFTP. Then activate the theme or plugin in wp-admin.

D

Ask the Resident Engineer. Describe what you want installed and ask it to verify the result.

Web code write access

Writable during setup, optionally read-only later, and temporarily writable whenever you need it.

During normal setup, PHP-FPM can write the WordPress installer directories and update wp-config.php when WordPress or a plugin needs to change configuration. Your SSH and SFTP account can always write the files it owns.

After you choose the stronger read-only posture, grant bounded access from your hosting panel. An hour is usually plenty.

Temporary web code write access is granted until (date and time).

You can install themes and plugins normally until then, and plugins may update wp-config.php when needed. It switches off by itself — you do not need to do anything. While it is on, your site is missing one of its protections, and any file that appears in your themes or plugins folders is recorded, so it is worth finishing and not leaving it open.

Temporarily writable
  • Themes and plugins
  • Download and rollback work folders
  • wp-config.php for PHP-FPM
Still protected
  • WordPress core
  • wp-content itself and drop-ins
  • wp-config.php from direct NGINX access

You cannot grant access from SSH because changing the runtime's permissions is a privileged platform action. You do not need the grant for command-line installs:

wp plugin install woocommerce --activate wp theme install some-theme.zip --activate wp core update

A theme or plugin “does not exist”

If the files are visible over SSH or SFTP, the problem is usually their group rather than missing content.

PHP and NGINX read your files through the shared wp-site group. Some uploads, archive tools and rsync commands replace that group. WordPress can no longer read the component even though the files remain.

The hourly repair normally corrects this. To repair it immediately, run the copy installed inside your site shell:

/usr/local/bin/wphost-fix-webroot-perms

The shorter wphost-fix-webroot-perms form works too because the directory is on your command path. The command is safe to run at any time.

Who owns and serves your files

Four accounts divide ownership, PHP execution, static-file serving and platform administration.

AccountRoleFile access
wpuser You: SSH, SFTP, WP-CLI and the Resident Engineer. Owns the site and can change its files.
wp-php Runs WordPress PHP on each request. Runs code and writes runtime data. It can write installer paths while web code write access is granted.
www-data NGINX serving images, CSS and JavaScript. Reads public assets. Explicitly cannot read wp-config.php.
root Woop! Host platform administration. Not involved in serving your site.

Your files are owned by wpuser and grouped as wp-site. The group gives PHP and NGINX only the access required to serve the site:

-rw-r----- 1 wpuser wp-site 4096 Jul 29 10:12 index.php

Runtime-data directories under wp-content add group write access. Media, caches, translations and plugin data continue to work while executable code can remain read-only to PHP.

Keep this nearby

Quick reference

I want to…Do this
Install from wp-adminInstall normally during setup. Under the stronger posture, grant temporary web code write access.
Install without the panelSSH in and run wp plugin install <file>.zip --activate.
Upload filesUse SFTP over port 22.
Fix a missing theme or pluginRun wphost-fix-webroot-perms.
Inspect the databaseUse Adminer, mysql, or an SSH tunnel.
Keep a new plugin currentEnable its auto-update switch in wp-admin.
Take a backup nowRun wphost-backups.sh backup --reason "before my change".
Restore the siteChoose a run with wphost-backups.sh list, then preview restore --run RUN-ID --live --exact --dry-run.
Use my own SMTP providerAdd all five WPHOST_SMTP_* constants.
Move an existing site hereUse the wphost-migrate-export and wphost-migrate-import skills.
Work with a WordPress specialistSSH in, run claude or codex, and describe the outcome in plain English.

You do not have to manage the stack

You only need to know where your site ends
and where our work begins.

Your hosting panel shows the platform. The Resident Engineer knows WordPress, plugins, backups and this stack.

Go to your hosting panel