Hosting safety and deployment boundaries

The existing Virtualmin management server is hq.hslg.uk. HSLG staging is media.hslg.uk, with WordPress in /home/media/public_html/. Build tools on the operator's server are kept under /home/media/.hslg-build/; Composer lives under /home/media/.local/bin/.

Rule

Never change other Virtualmin domains, global PHP settings, system Composer, shared MariaDB configuration, or system Apache settings as part of an app release. Normal HSLG deployments update only the authorised site and its explicitly backed-up HSLG tables.

Preparation

Confirm backups, free space, site ownership, PHP version, HTTPS, WordPress health, MariaDB UTC sessions, plugin conflicts and restoration access. Test on staging before public rollout. No deployment changes happen during package generation in the AI workspace.

Trade-off

Site-local dependencies are easier to support and protect other tenants, but multiple isolated dependency copies use more disk. That cost is acceptable compared with shared-server regression risk.

One Ubuntu host, multiple isolated roles

The current HSLG staging host is an existing Ubuntu server managed through Webmin/Virtualmin. Its media virtual-server user owns the staging website under /home/media/public_html. This server may also host unrelated sites. HSLG changes must not alter global Webmin/Virtualmin configuration, other virtual hosts, shared mail services or MariaDB server-wide settings simply to install an app build dependency.

What is allowed in each directory

The WordPress document root contains the installed WordPress site, its plugins, themes, uploads and normal site files. The separate private build directory /home/media/.hslg-build is intended for Node, Java, Gradle, Android SDK, pnpm caches, source extraction and logs. It is not web-served. Public plugin ZIPs should contain only their required runtime files, not SDK packages, debug tokens, database dumps or signing keys. Historical SSH commands are retained as references and must be inspected before rerunning because site configuration can change.

PHP and MariaDB configuration boundaries

Before touching PHP settings, identify the active PHP version and site-specific PHP-FPM pool. Record the prior values, back up the correct configuration, run syntax validation and verify the resulting website response. Virtualmin may assign different pool filenames after rebuild, so copying an old numbered pool path is dangerous. The earlier 64M upload / 80M POST values belong to a specific staging workaround. They are not permission to change every PHP pool or /etc/php globally.

Schema changes must target HSLG-owned MariaDB tables through reviewed API plugin migrations. WordPress admin/editorial tables and unrelated websites must not be rewritten. An additive migration may still affect indexes, backups and rollback; test it against a staging database and document when a plugin downgrade cannot undo schema effects.

Release sequence

Build and test in the AI/private environment, package each independent WordPress plugin, take the appropriate site backup, install the approved plugin ZIP in WordPress and confirm site behaviour. The documentation publisher updates its own pages automatically upon installation; the operator does not need to run root SSH or WP-CLI to publish them. A source ZIP is not an installable WordPress plugin. A browser presenter ZIP is not an Android APK.

Recovery and incident limits

After an incident, identify which layer failed before attempting restoration: WordPress plugin, PHP worker, MariaDB, HTTPS, native app build or customer-service API. Roll back only the affected component when possible. A total-loss rebuild can reinstall Ubuntu, Virtualmin, WordPress and the SDKs from source and pinned packages; it cannot recreate customer records, original WordPress revisions or lost signing private keys if every backup was destroyed. The single Disaster Recovery page is authoritative for recovery commands and validation steps.