Drupal distributions

A distribution is a Drupal codebase that arrives with its purpose already built in — a shop, a newsroom, a council website, a farm ledger, a community. Instead of assembling modules yourself, you install a site on a distribution platform and start from a working product.

BOA carries a whole catalogue of them. Each distribution in the catalogue is a ready-made platform: it appears in the Platform drop-down when you create a site, and sites on it get the same panel tasks as any other site — Verify, Clone, Migrate, Backup, Restore, HTTPS. The pages in this topic cover each distribution's specifics: what ships, what to expect on first install, and any quirks worth knowing before you pick one.

How distributions stay fresh

Four kinds of build sit behind the catalogue, and the Notes column in the table below tells you which is which:

• Built from upstream — built from the distribution's upstream Composer template as BOA releases ship, so it tracks the version its own project currently publishes. The platform name in your panel always shows the exact version you're getting.
• Fixed by BOA — built from upstream the same way, with a build-level correction BOA applies on top because the stock upstream build doesn't install cleanly as published (the distribution's own page tells the story).
• Pinned — a fixed, known-good build of a specific version. It installs and serves exactly as tested, but it doesn't chase upstream releases; updating core or modules inside a site you build on it is your own (Composer) workflow, like on any platform you'd add yourself.
• Legacy — a pinned build from the Drupal 6/7 era, kept in the catalogue on BOA's maintained legacy cores — deliberately so; the last note under Good to know below explains why.

The catalogue

Every distribution has a short keyword — the symbol you'd use in your platforms.info control file to request it (your account's ~/static/control/README.txt lists them too). How that file works — including the one gotcha, that it replaces your platform list rather than adding to it, and that ALL is the only future-proof value — is covered in Choosing and managing platforms.

Backdrop CMS is deliberately missing from this table: it's not a Drupal distribution but a platform family of its own, with its own topic in this guide.

When a distribution needs an older PHP

The PHP column names the newest PHP version each distribution is supported on, and a BOA server serves everything on PHP 8.4 by default. So for every row showing 8.4 there is nothing to set up — create the site and go.

When the column shows an older version — 8.3 or 7.4 — run the distribution on that version rather than on the newer server default: anything above the column is outside what the distribution supports, and the oldest generations may not even build or install on it. Switching is entirely self-service — a few tiny control files you write from your own shell — and the order matters:

1. Switch your command-line PHP first, before the platform is requested and before any site is installed on it. One marker file covers the whole flow:

   SHCopy

   touch ~/static/control/php83.info
   

   The marker takes effect instantly and steers everything the switch touches: your very next drush or composer command, the Drush runs behind your Ægir tasks — Verify, Install, Clone, Migrate — and the platform build itself, which reads the marker once when its run starts (as long as no higher phpNN.info marker is left lying around, since the highest installed one wins). If you want the choice to outlive the marker, also write it into cli.info — the durable account default the marker overrides while it exists:

   SHCopy

   echo 8.3 > ~/static/control/cli.info
   

2. Request the platform and install your site as usual — platforms.info plus the upgrade trigger, as covered in Choosing and managing platforms, or a support request to your host.

3. Pin the site's serving PHP in multi-fpm.info — one line with the site's main domain, a space, and the version:

   SHCopy

   echo "old-shop.com 8.3" >> ~/static/control/multi-fpm.info
   

   Within a few minutes the listed site serves visitors on its own PHP version, while the rest of your sites keep following your account default.

That's the whole procedure. The full story of the files — fpm.info, multi-fpm.info, cli.info and the phpNN.info markers, including the fact that the command-line choice covers your whole account and how to step back to a newer version when you're done — is in Choosing your site's PHP version.

One practical note on the 7.4 rows: current servers ship modern PHP only, so the legacy versions may not be installed on yours — and a version that isn't installed can't be selected; your choice quietly falls back to an installed one. If the switch doesn't seem to take, or the platform won't build or install, ask your host to enable the version first — a quick server-side addition, not a limitation of the platform.

Good to know

• Your host decides which of these exist on your server. If a distribution you want isn't in your Platform drop-down, shape your own list with platforms.info (where your plan allows) or open a support request naming the keyword — adding it is quick on the server side.
• Distributions choose their install profile for you. When you create a site on a distribution platform, pick the distribution's own profile in the Install profile field — that's what makes it a Commerce shop or a LocalGov site rather than a bare Drupal.
• First impressions vary by distribution. Some land on a themed front page, some greet you with a login page, one (farmOS) deliberately locks its front page altogether. Each page in this topic tells you what a healthy first install looks like, so you don't mistake by-design behaviour for a broken site.
• Legacy generations are a feature here. Drupal 6 and 7 era distributions stay in the catalogue on BOA's maintained legacy cores — that's the point: sites nobody else will host any more still have a home, and a migration runway to a current platform when you're ready.