Backdrop CMS on your server

BOA runs Backdrop CMS as a first-class platform, side by side with your Drupal platforms: the same Ægir control panel, the same site tasks (install, verify, clone, migrate, backup, restore), automatic platform builds that always track the newest Backdrop release, Valkey caching with database fallback, and a native CLI (bee) next to the Drush you already use.

It also ships the piece most Drupal 7 owners are waiting for: a safe Drupal 7 → Backdrop upgrade built into the panel, which converts a copy of the site while the original keeps serving untouched.

Backdrop support is on by default: your normal upgrade pair brings the panel module and the bee CLI with it — there is nothing to switch on. Asking an existing instance for the Backdrop platforms themselves is a separate, one-line step, described below.

Default on, easy off

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

1. /root/.<user>.octopus.cnf — the Backdrop platforms and the panel module.
2. /root/.barracuda.cnf — the system layer (the bee CLI).

To keep Backdrop off an instance, set _BACKDROP_SUPPORT=NO in its Octopus config (and mirror it in /root/.barracuda.cnf to skip the system tools too). A value already written in your control files always wins over the shipped default — so a server upgraded while the switch still defaulted to NO keeps NO until you flip or delete that line.

On a stock server the normal upgrade pair is all it takes, 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 Backdrop frontend module and puts bee on the command line. Enabling the module also re-verifies your platforms once, so Backdrop platforms that existed before the module always show up correctly as upgrade targets.

Asking for the platforms themselves

Which platforms an instance carries is a separate switch, and it lives in the instance's own control folder rather than in the config file. Put the BDR symbol into platforms.info — upper-case, space- or newline-separated, alongside any other symbols that instance should carry:

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

Then run the Octopus upgrade for that instance, and the Backdrop platform trio (prod, stage and dev) is built and registered in the control panel.

Two things worth knowing about that file: it replaces the default platform list, so pinned symbols mean the instance skips distributions added in future releases — use the keyword ALL if you would rather never skip anything. And the account owner can do all of this without root: editing platforms.info and then touch ~/static/control/run-upgrade.pid has a background agent start the same upgrade within a few minutes. The cheat sheet in ~/static/control/README.txt on every instance lists the full symbol set.

What you get

• Platforms that maintain themselves. Backdrop platforms build from the newest Backdrop release automatically — there is no version pin to bump. Each platform gets the Backdrop-native Valkey/Redis cache module (and, in the same bundle, the Webform port) through a shared, centrally updated contrib bundle symlinked in on every platform verify — including platforms you upload yourself — and repaired nightly if the symlink goes missing; sites use Valkey when it is up and fall back to the database cache when it is not.
• The full site lifecycle. Install, Verify, Clone, Migrate, Backup, Restore, Import and Delete behave exactly as they do for Drupal sites. Cloned and imported copies land with cron and Encryption disabled on purpose, so a copy never emails your users.
• Both CLIs. bee (Backdrop's native CLI) and Drush 8 both work against Backdrop sites, with per-site aliases as usual. bee runs under the account's command-line PHP selection — cli.info and the instant phpNN.info markers — exactly like Drush, clamped to PHP 7.4 or newer; its launcher lives at /opt/local/bin/bee. Client shell accounts get the everyday bee verbs; destructive ones are reserved for the panel and admin identities.
• Panel-owned cron. Backdrop's key-authenticated web cron is wired into Ægir's cron scheduling automatically; Backdrop's own visit-triggered cron is disabled so runs never double up.

Upgrading your Drupal 7 sites

On any Drupal 7 site node the panel offers Upgrade to Backdrop. The shape of the task is what makes it safe:

• It converts a copy at a new domain on your Backdrop platform. Give the copy a dev.-prefixed name and self-identifying crawlers are served a 404 on it for the whole review period; the production name arrives at cutover.
• The original Drupal 7 site — database, files, vhost — is never in the write path and keeps serving throughout.
• The task refuses to start unless the source is a fully updated Drupal 7 core, and the refusal happens before anything is created.
• The task log prints a per-module compatibility report during validation: which modules Backdrop absorbed into core, which need a Backdrop contrib port on the platform, and which will be disabled by the conversion (their data tables are kept).
• The copy keeps your theme: a site-local theme is carried across and the site's theme choice stays set, though the copy records a Drupal 7 theme as disabled (it declares no Backdrop compatibility) even while serving it. Simple stylesheet-driven themes can render as-is; a theme that leaned on Drupal 7's page template and regions meets Backdrop's layout system and needs a port (backdrop = 1.x, plus a layout where the page template did the arranging). The module report doesn't cover themes — the review walk on the copy is where you judge it.
• The copy lands enabled and serving with cron and Encryption switched off; you review it, enable both deliberately, and cut over whenever you are ready — the Cutover task on the copy retires the source and renames the copy to its domain in one step (re-enable Encryption for the new name afterwards), or repoint DNS instead. Any failure ends with "discard the copy and re-run" — the original is intact by construction.
• The copy is a point-in-time conversion of the backup taken at task start — later edits on the source are not in it, and there is no delta-sync step because none is needed: re-running is cheap. Do one final fresh run at a quiet moment right before cutover, and cut that newest copy over.

Drupal 6 sites are refused by this task by design (the official Backdrop position) — they get their own first step instead, below.

Upgrading Drupal 6 sites: the two-step chain

A Drupal 6 (or Pressflow 6) site reaches Backdrop through two panel tasks: Upgrade to Drupal 7 on the Drupal 6 site node, then the standard Upgrade to Backdrop on the Drupal 7 copy it produces. Both steps convert a copy at a new domain; the site each step starts from is never in the write path. The in-between Drupal 7 site is a real panel site you can inspect and keep as a fallback.

Step 1 converts the CCK custom-field data along with the site, using a pinned kit of Drupal 7 module ports that your server stages from the BOA mirror automatically during every Octopus upgrade run (only the modules the source site actually uses are enabled on the copy, plus the migration engine and core file/image support). The field-data migration is a hard gate: a field that cannot be migrated aborts the task rather than deliver a site with content silently missing — the disposable copy is left for you to Delete before re-running.

What a Drupal 6 chain needs on the instance:

• PHP 7.4 pinned for the instance (static/control/cli.info and fpm.info set to 7.4, then one Octopus upgrade run). The Drupal 6 code and the kit run under the instance CLI, and 7.4 is the supported interpreter for the legacy chain. Treat a 7.4 instance as a dedicated legacy instance: Drupal 8+ platforms on the same instance would break, so keep modern sites on a separate one.
• Drupal 6 and Drupal 7 platforms: include the DL6 and DL7 symbols in the instance's platform list alongside BDR.
• Backdrop support enabled as above — the kit stages automatically with it; if it is ever missing, step 1 refuses to start and tells you to run the Octopus upgrade (nothing is ever downloaded at task time).

The fine print

• Migrate works for Backdrop sites the same way it does for Drupal sites: move a Backdrop site onto another Backdrop platform (the usual reason: a freshly built platform tracking a newer Backdrop release), or rename it to a new domain, with the same backup-first semantics. The one hard rule is that Migrate never crosses the lineage — a Drupal site never migrates onto a Backdrop platform or the reverse; the panel only offers same-lineage platforms and the backend refuses a cross-lineage pair outright. It also refuses a no-op self-migrate — a site aimed back at the platform it already sits on with no new name — because that moves nothing while still risking the site's live database; point it at a different platform, or give it a new name. Drupal 7 sites reach Backdrop through the dedicated upgrade task above, never through Migrate.
• If you import an old Drupal 7 database dump from another server and its tables are still utf8, convert them to utf8mb4 before upgrading — a fresh copy database defaults to utf8mb4 and mixed collations can break JOIN-heavy pages after conversion. The panel does this for you: the Convert to utf8mb4 task on the site's page takes a fresh backup, converts every utf8 table and text column in a short maintenance window and verifies the result — and simply reports "nothing to convert" on databases created on this server, which are already utf8mb4. The Drupal 7 copy minted by the Drupal 6 step carries 3-byte tables too; convert it between the steps.

One operator note on contrib delivery. The shared bundle attached to every Backdrop platform as modules/o_contrib_backdrop is the supported platform-wide channel, and today it carries the Valkey/Redis cache module and the Webform port (its first curated member beyond the cache layer); members are maintained in BOA's build pipeline, so adding one is a BOA code change, not a box-side setting. A module you place in a BOA-built platform's root modules/ yourself persists (nothing prunes it) but does not carry to the next platform revision BOA builds — per-site code in sites/<uri>/modules/ rides the site instead, and tenant platforms under static/ are tenant-owned in their entirety. And one trap worth knowing: Backdrop has no sites/all layer — the folder exists on the platform (BOA keeps the platform control file there) and Ægir's package listing even reports modules placed in it, but Backdrop never loads code from it.

That is the whole picture for day-to-day operation. When you want to see exactly what an upgrade did, the task's own log narrates every phase as it runs — the validation checks, the module report, the backup, the conversion passes and the final verify — so the record of each run lives right on the task node in your panel.