Textpattern CMS on your server

BOA runs Textpattern sites under the same Ægir control panel as your Drupal and Backdrop sites: panel-driven install, verify, backup, restore, clone and upgrade, platforms that always track the newest official Textpattern release, and the same fleet-grade security contract every other vhost on the box gets.

Unlike Grav, Textpattern is a classic database-backed CMS: every site gets a real MySQL database, created utf8mb4 and InnoDB from birth, and its backups ride the same dump machinery your Drupal sites use.

Opt-in, off by default

The switch is _TXP_SUPPORT, mirrored in two control files (each program reads its own), and it defaults to NO in both:

1. /root/.<user>.octopus.cnf — the Textpattern platform, the panel module and the per-instance staging of official release archives.
2. /root/.barracuda.cnf — the system layer (codebase detection and the per-account settings carry).

Set _TXP_SUPPORT=YES in both files, then run your normal upgrade pair, for example:

barracuda up-lts system
octopus up-lts o1

(Use up-pro on PRO instances — whichever tree your server already follows.)

That enables the Textpattern frontend module and stages the newest official release archive for upgrades.

Asking for the platform itself

Which platforms an instance builds is a separate switch: the instance reads its platform symbols from a small control file, so putting TXP there is all it takes.

echo "TXP" > /data/disk/<user>/static/control/platforms.info

Then run the instance upgrade as usual:

octopus up-lts <user>

A client with no root access can do the same thing without you: edit the same ~/static/control/platforms.info, then

touch ~/static/control/run-upgrade.pid

The upgrade starts within a few minutes and the trigger file is removed automatically. Without platforms.info the trigger is ignored.

List every symbol you want that instance to carry, in UPPERCASE and separated by spaces or newlines (for example DE4 TXP to keep your Drupal 11.4 platforms alongside Textpattern), or the keyword ALL to always get everything. The file replaces the default list rather than adding to it, so pinned symbols also mean the instance skips distributions added in future releases, while ALL never skips anything. The run reports NOTE! Custom Platforms List: … when it picks the file up, and finishes with your Textpattern platform registered in the control panel. On a brand-new instance you can pass the same symbols through _PLATFORMS_LIST at install time instead — but on an instance that already exists, use the control file: upgrade runs reset that config line, so a symbol added there would quietly stop being built.

Sites on that platform are partitioned from your Drupal platforms on the site creation form, so the two families never mix by accident.

One core, many sites

Textpattern ships native multisite, and BOA always uses it: the platform is a pristine official release tree, and each site is an entry under the platform's sites/ directory with its own admin/, private/ and public/ areas, tied back to the shared core by the release's own relative symlinks. The web root of the site's vhost is the site's own public/ directory.

The admin side is path-mapped on the site's own vhost — you reach it at /txpadmin/ under the site's domain, with no separate admin subdomain to create, certify or remember.

One platform node therefore serves any number of sites, and deleting the platform is refused while sites still live on it.

What you get

• A platform that maintains itself. The platform tree builds from the newest official Textpattern release — there is no version pin to bump. Only official, checksum-verified release archives are ever used, delivered through the BOA mirrors; your server never fetches from third-party channels at task time.
• The site lifecycle. Install, Verify, Backup, Restore, Import, Clone, Enable, Disable, Reset login and Delete behave as they do for Drupal sites. Clone regenerates the copy's site identity and clears its login tokens, so the clone is cryptographically its own site from the first request; it also points every user's e-mail address at the copy's own admin address and returns the mail settings to Textpattern's defaults, so a copy never mails the original site's people (the addresses survive in the pre-clone backup the panel registers). Clone refuses a platform whose core is a different release from the one the site's database records, and points at the Upgrade task instead. Migrate is not offered for Textpattern sites.
• Upgrading a site: a copy, then a switch. One Textpattern core serves every site on its platform, so a release upgrade is not an in-place swap. The Upgrade Textpattern task builds a copy of the site at a new domain on a platform carrying the newer release, runs Textpattern's own update chain against that copy, and checks the result against the new core's own table definitions before the copy is verified — a missing table, column or index fails the task rather than leaving you a site that merely claims a version number. Your original site keeps serving its own domain throughout: the upgrade reads it and archives it, and a failure discards the copy and leaves the original as it was. The copy is the same site under a temporary name, not an independent one — its feed identity, its accounts and its image ids all come with it, and only live sessions are ended. It starts with encryption switched off and stays that way until you switch over, because certificates are bound to a name.
• Rename. Moves a site to a new domain on the same platform: a safety backup first, then the directory move, the site's settings and stored paths rewritten, the old vhost removed and the new one rendered. The site keeps its content, its users and its identity; logins end with the rename, custom aliases are not carried over, and encryption ends up disabled for the new name — re-enable it deliberately afterwards. The domain is unserved while the rename runs (Textpattern has no maintenance mode to hold the door with), for a window that scales with the size of the site.
• Cutover. The deliberate last step after an upgrade: it retires the site currently holding a domain — backed up first, and that backup stays restorable — and then renames this site onto the freed domain, both as real panel tasks with their own logs. If nothing holds the domain any more, Cutover simply claims it, which is also how you re-run one that stopped half way.
• A real database, first-class backups. Every site's database is created utf8mb4 and InnoDB from the start — nothing to convert, ever — and Backup captures the database and the site's file tree together, exactly like a Drupal site backup.
• No cron to babysit. Textpattern core needs no scheduled tasks, so the panel's cron dispatch skips Textpattern sites entirely — nothing to configure and nothing to mis-fire.
• Enforced modern PHP. Textpattern sites always run the server's default modern PHP (8.4) for both web and admin. Unlike Drupal sites there is no per-site PHP selection — the version is part of the hosting contract.

Plugins, themes and email

Textpattern ships no command line, and none is needed: plugins and admin-side themes install through the site's own admin interface at /txpadmin/, and front-side themes live inside the site's own directory tree, so they ride every backup, restore and clone with the site.

Outbound email (password resets, comment notifications) leaves the box through the server-level mail relay — configure _SMTP_RELAY_HOST once in the barracuda control file and every site on the box uses it; there is nothing mail-related to configure per site.

The security posture

A Textpattern site's vhost is rendered with the same fleet contract as every other vhost on the box:

• Only the site's own entry scripts execute; Textpattern's internal trees, dotfiles, YAML/INI sources and SQL dumps are denied outright, and the admin interface is served only through the path-mapped /txpadmin/ location.
• Direct downloads from the site's /files/ area are denied by default — Textpattern serves managed file downloads through its own controller, so the raw directory stays closed. A site that wants raw downloads open can opt out with a per-site control file (txp-files-open-<sitename>.info in the instance's static/control/ directory).
• The fleet's request classification (bans, scanner probes, crawler and AI-fetcher policy, TLS-on-plain-port) applies unchanged, and the per-site user_admin_access allow-list covers /txpadmin the same way it covers Drupal's /user. Classification guards answer with a dropped connection; capacity sheds answer with a retryable 503, never a dropped connection.
• The site's configuration file carries no world-readable bits on disk, and the hosting tasks re-assert the whole permission model on every verify.

The fine print

• Upgrade Textpattern needs somewhere to upgrade to: it lists the verified Textpattern platforms carrying a newer release than the site's own, so add and verify that platform first, and an upgrade onto a same-version or older core is refused when you reach for one anyway. The task also refuses a site whose database records a release older than 4.7.2 — the update steps below that version delete files from the core directory, which on a multisite platform belongs to every other site on it.
• The panel's cron scheduling does not apply to Textpattern sites by design: the core needs none.
• A site's drushrc.php at the site root is a hosting artefact (the panel writes and protects it); leave it be — it survives backups and restores by construction.