SSH access and WP-CLI

A real shell, already pointed at your WordPress installation.

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.

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

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.

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.

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

Moving an existing site in

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

Keep your existing site running while you prepare the new copy. If its domain still points to the old host, use a temporary Woop! Host domain from your hosting panel to test the new site before changing DNS. Take a backup before importing over any content on the destination.

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.

See a worked example: a WordPress migration with two Resident Engineers. The post follows the transfer and checks, including the decisions the site owner approved. For the current migration skill names, see the Resident Engineer section above.

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.

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.

If the daily backup fails, WordPress core, plugin and theme updates are skipped. Permission repair and other routine maintenance still run.

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

Use local Postfix by default, or configure an SMTP provider.

Which email address does what?

The WordPress administration email does not automatically become the sender. Forms and mail plugins can set From and Reply-To without changing the delivery route.

Mail tracing

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.

Local delivery through Postfix

No provider account is needed, and Postfix queues and retries mail. Delivery depends on the VM's reputation and your domain's authentication.

No SMTP constants are needed. WordPress submits mail through PHP's mail() function to local Postfix. Postfix normally sends over IPv4 from the VM to recipients' mail servers, announcing the permanent site-xxxx.woop.host alias. A configured server-level relay changes that route.

An unset bounce address normally comes from the account running PHP at the VM's permanent alias. Web requests, scheduled WordPress jobs and WP-CLI can therefore have different bounce addresses. To choose From and the bounce address together, use the local Postfix SMTP example below.

DNS for the default route

• Woop! alias: We publish v=spf1 a -all for the permanent site-xxxx.woop.host alias. This authorises that alias's IP to send mail with a bounce address at the alias. You do not edit this DNS record.
• Your own domain: If the bounce address uses your domain, authorise the actual sending IP in that domain's existing SPF record. For direct delivery, add a:site-xxxx.woop.host before the final all rule, using your actual permanent site alias. SPF then looks up the alias's address, so you do not hard-code the VM's IP. Preserve other sending services and keep one SPF record per domain. If Postfix uses a relay, use that relay's SPF instructions instead.
• Incoming mail: Keep your existing MX records. This outgoing-mail setup does not create customer mailboxes.

SPF for the Woop! alias does not by itself satisfy DMARC for From: bookings@example.com. DMARC needs a passing SPF result with an aligned bounce domain, or a passing DKIM signature aligned with the From domain. Adding SPF to the visible From domain alone does not fix a bounce address at an unrelated Woop! alias.

Using the same domain for From and the bounce address is the simplest way to align SPF. A dedicated bounce subdomain needs its own SPF record; the parent domain's SPF is not inherited. bounce.example.com can align with example.com under relaxed DMARC SPF alignment, but strict alignment requires identical domains. Keep your existing policy and choose addresses that meet it.

The stack installer does not set up DKIM signing for your own domain. Publishing a DKIM DNS record alone does not sign messages. For DKIM signing through a provider, use an SMTP provider and complete its sender verification and DNS setup. Keep your existing DMARC policy.

Support can check the VM's reverse DNS, hostname, outbound TLS, queue failures and IP reputation. Local DKIM signing requires a server-side signer and matching DNS record.

After setup, send a real site message. Check its From, Return-Path and Authentication-Results headers. A successful WordPress send can mean only that local Postfix accepted the message; it does not prove inbox delivery. Ask support to check the installed Postfix route if delivery fails.

SMTP settings and providers

A provider can handle DKIM signing and sending reputation, but requires an account and may impose sending limits.

The Woop! Host plugin reads WPHOST_SMTP_* settings from wp-config.php. An external SMTP provider bypasses Postfix's queue; retries depend on the calling plugin. The local Postfix example below keeps that queue.

To use your own SMTP provider, add these three constants to /var/www/wordpress/wp-config.php over SSH or SFTP. Place them before the “That's all, stop editing!” line and before WordPress loads wp-settings.php. If an SMTP constant already exists, edit it instead of adding a duplicate.

The host enables SMTP. Credentials enable authentication, port 587 and required STARTTLS, which encrypts the connection. If the username is an email address, that address becomes both the From address and bounce address. Otherwise, WordPress keeps the sender supplied by your site or form plugin. The existing display name stays unchanged.

Use a hostname or IP address without a URL scheme or port in WPHOST_SMTP_HOST. All credentials shown here are placeholders. Enter your credentials only in your site's configuration. Never paste passwords or API keys into a support ticket. The Resident Engineer can check settings without displaying credentials.

Relays and port 465

For a relay that accepts mail without a login, only the host is required:

This uses port 25 without authentication and upgrades to STARTTLS when the server offers it. The relay must permit sending from your VM. If old credentials remain configured, add define( 'WPHOST_SMTP_AUTH', false ); to ignore them. Without an explicit override, one missing credential stops the send with a configuration error. Two empty credentials mean no authentication.

If your provider requires port 465, add define( 'WPHOST_SMTP_PORT', 465 ); to the host and credentials above. Port 465 implies implicit TLS, which encrypts the connection from the start. Certificate verification remains enabled.

Optional settings

These constants override the defaults. Use PHP booleans true and false without quotes.

Setting a recognised WPHOST_SMTP_* constant without WPHOST_SMTP_HOST fails the send through wp_mail_failed, unless WPHOST_SMTP_ENABLED is false. Other malformed settings also fail the send. SMTP errors do not fall back to local mail. Disable TLS only for a trusted connection that requires it.

Use these settings with local Postfix

To choose a From and bounce address while keeping Postfix's queue, use the same configuration file and placement above. Replace any existing SMTP settings with:

Replace the sender with an address you control and monitor for delivery failures. The display name is optional. No password is needed. If WPHOST_SMTP_ENABLED is false, remove that setting to enable this configuration. The connection stays inside the VM; disabling TLS here does not change Postfix's onward delivery.

FROM_EMAIL sets both From and the bounce address. A separate bounce address, such as bounces@bounce.example.com, needs a mail plugin that supports a separate envelope sender, or a Postfix change scoped to envelope senders. Set up bounce reception with your existing mail provider. Adding a Return-Path header yourself does not change the SMTP envelope sender.

Example: SendGrid and other SMTP providers

SendGrid uses the literal username apikey. Since that login is not an email address, set WPHOST_SMTP_FROM_EMAIL to a sender verified with your provider:

Amazon SES, Mailgun, Postmark, Brevo and SMTP2GO use the same configuration pattern. Use your provider's SMTP endpoint and SMTP credentials, which can differ from its API credentials. Amazon SES endpoints are regional.

Verify your sender address or domain with your provider and publish its required DNS records. SPF authorises sending services. DKIM signs messages. DMARC checks that SPF or DKIM aligns with the From domain and sets a policy for failures. Configure these for the actual sending path and keep existing authorisations for your other mail services. Keep your incoming-mail MX records unchanged for this SMTP setup.

Other mail plugins

WP Mail SMTP and FluentSMTP provide controls in wp-admin, including options to force the From email and name supplied by other plugins. Where supported, Return Path can match From. Providers may enforce their own sender or bounce address. Configure one mail plugin to manage delivery.

These settings support SMTP password authentication and relays without a login. OAuth and provider HTTP APIs require a separate mail plugin. Let that plugin handle mail by adding:

Use the PHP boolean false, not the string 'false'. Removing authentication does not grant permission to relay to external recipients.

Example: Microsoft 365 and Azure email

Use an existing Microsoft 365 mailbox: Choose a mail plugin's Microsoft OAuth connection, such as FluentSMTP's Outlook / Office 365 connection. Follow its Entra app registration and Microsoft sign-in steps; your tenant administrator may need to approve access. Use the authorised mailbox as From and set WPHOST_SMTP_ENABLED to false, as shown above. OAuth supports Microsoft sign-in with MFA. Password submission through smtp.office365.com:587 is a legacy option subject to tenant restrictions and Microsoft's Basic authentication deprecation.

Use Microsoft's SMTP service for application mail: Azure Communication Services Email works with the built-in settings. This is a separate paid Azure service. Connect an Email resource and verified domain, create an SMTP username linked to an Entra application, and use that application's client secret:

This uses port 587 and required STARTTLS. Use a sender at the verified domain and complete Azure's SPF and DKIM setup.

Send only to your Microsoft 365 organisation: If your tenant permits Direct Send, its MX endpoint can accept mail without a login. This endpoint does not accept SMTP username/password logins. Ask your administrator for the actual endpoint and an accepted sender domain. For example:

AUTH=false ignores old username and password settings; no custom mu-plugin is needed to disable login. Direct Send cannot deliver to external recipients. Authorise the VM in the sender domain's SPF as described under local delivery. Keep incoming-mail MX records unchanged. Microsoft's mail delivery guidance excludes third-party hosted applications from connector SMTP relay, so use OAuth or Azure Email for external recipients from a Woop! VM.

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.

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.

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.

Who owns and serves your files

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

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:

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.