WordPress-first hosting with Jabali Panel

WordPress is Jabali Panel’s primary citizen. The Applications section ships 15 apps; WordPress gets the first-class treatment — one-click install, automatic wp-admin SSO, per-install auto-update, clone, and integration with the panel’s security stack. This post walks through how the WordPress path actually works.

One-click install

The Applications wizard provisions everything needed to bring up a fresh WordPress site:

1. Create a MariaDB database + dedicated user with a generated password
2. Download the latest WordPress release archive
3. Extract into the chosen docroot (defaults to a fresh subdomain or a path you pick)
4. Generate wp-config.php with the DB credentials and secret salts
5. Run wp core install via WP-CLI 2.12.0 with the admin user, email, and site title from the form
6. Write a single-use SSO drop-in into the docroot so the panel can sign you straight into wp-admin

No SFTP-and-extract dance. No copy-pasting database credentials. From “click Install” to a working wp-admin login is typically under 30 seconds.

How the wp-admin SSO works

The panel never stores or proxies WordPress passwords. Instead, it writes a self-deleting PHP file at the WordPress docroot:

/jabali-sso-<43-char-nonce>.php

When you click “Open Admin” in the panel, the browser opens that URL. The file uses flock to claim itself exclusively, calls wp_set_auth_cookie() for the admin user, then unlinks itself. The file has a 60-second TTL — if nobody hits it within that window, a separate cleanup pass removes it.

Each “Open Admin” click fetches a fresh nonce. Two consequences:

• The link is single-use. You can’t share it. You can’t replay it.
• A stolen jabali-sso-*.php URL is useful for at most 60 seconds and only if the cleaner hasn’t run.

This replaces an earlier magic-link / mu-plugin approach (M22 in the milestone log) that had subtle issues with multisite and wp-config.php overrides. The self-deleting shim has none of those.

Per-install auto-update

Each WordPress install exposes a toggle:

Run a weekly systemd-user timer that executes: wp core update && wp plugin update --all && wp theme update --all

Off by default. Enable it per install once you trust the upstream release cadence for that site’s plugin set. The timer is owned by the WordPress install’s Linux user — there is no root-level cron, and a misbehaving update cannot escape the user’s PHP-FPM pool.

Cloning

The Clone action on an installed WordPress site is currently WordPress-only (other apps in the registry support manual clone via file copy + DB dump + URL search-replace). It:

1. Stops the source PHP-FPM pool briefly (optional, recommended)
2. Copies the docroot tree to the new target docroot
3. Dumps the source database, imports into a new database, runs wp search-replace for the URL change
4. Restarts the source pool, registers the clone in the panel, opens it for “Open Admin”

Useful for staging copies, customer onboarding from a template site, or migration testing.

PHP versions

PHP-FPM is a hosted workload managed by the panel — the panel API and agent are Go, not PHP. Each hosted user gets a dedicated PHP-FPM pool socket. Available versions are 8.1, 8.2, 8.3, 8.4, and 8.5, all from the Sury repository. Domain-level PHP-version selection means a single user can run one site on PHP 8.1 and another on PHP 8.5 without conflicts.

Security defaults

Hosted WordPress sites get the same stack every Jabali-hosted site gets:

• CrowdSec AppSec WAF — virtual patches for LFI, RCE, and XSS patterns, plus CrowdSec community blocklists for IP-layer decisions
• Snuffleupagus — PHP runtime hardening (no eval, no include-from-uploads, taint tracking)
• AppArmor — per-pool enforcement profiles so a compromised PHP process can’t reach outside its own world
• Per-user nftables egress rules — stop a compromised tenant from being usable for outbound abuse
• YARA-X malware scanning — periodic file scans for known web-shells and droppers
• AIDE — host-integrity baseline; any file change outside the expected set fires an alert

WordPress doesn’t get a special hardening profile here — it gets the same default profile every PHP workload gets, which is plenty for keeping a typical install behaved.

Try it

Run the installer on a fresh Debian 13 VPS, create a hosted user, point a domain at the server, then open Applications → Install → WordPress. The quickstart walks this end-to-end in seven steps. The demo panel shows the Applications section live.