🇵🇱Poland @memtkmcc

One more important clarification: while BOA still installs the main Aegir instance in the default /var/aegir path, just like all standalone Aegir setups, it doesn’t actually use it for anything beyond serving as the central web server configuration point. Its main purpose is to include the virtual hosts for BOA-specific Octopus instances located in /data/disk/foo.

This approach improves compatibility and helps avoid conflicts, allowing BOA and standalone Aegir instances to co-exist on the same system. BOA also leaves the /var/aegir directory structure intact—even if it automates its upgrades—while most BOA-specific features apply only to the Octopus instances in /data/disk/foo.

Just to clarify further: BOA has never used Apache, and therefore does not develop or test against Apache-based setups. However, we have also never removed or altered Apache-related code or templates in Aegir itself. This means that while Apache-based Aegir setups will continue to function, they will only receive minimal support moving forward.

That said, we are not introducing any changes to Aegir that would prevent someone from continuing to use Apache if they prefer, or if they just want to apply selective patches (for example, to ensure compatibility with newer PHP versions).

At this time, we haven’t yet committed patches or updates back to the Drupal.org repositories (and haven't done so in quite a while), but assuming there's consensus—and it seems that way so far, which we greatly appreciate—we're preparing to resume active contribution here.

Importantly, since we don’t plan to publish new releases (tarballs) on Drupal.org, these changes won’t impact anyone still running standalone Aegir, whether with Apache or otherwise. The updates will be available only in the Git repositories, and will be clearly documented to distinguish between upstream Aegir usage and BOA-powered Aegir setups.

We’ll make it very clear across all Aegir project pages that while the code on Drupal.org will reflect the full set of BOA-driven improvements, the only supported environment will be BOA. To make adoption easier, we’re working on helper scripts to streamline the upgrade path—even for users currently running Apache—so they don’t have to manually figure out how to switch to Nginx or adjust their system configuration.

We also plan to restore Ubuntu support in BOA for users who have institutional requirements to run Ubuntu—though this will be without systemd. For Debian-based systems, we already support and encourage easy migration to Devuan as a systemd-free alternative.

@steven-jones Yes, that's correct—BOA is indeed more opinionated by design, but that comes with many significant advantages that aren't possible with a fully system-agnostic Aegir setup. It's a virtual tradeoff in that sense: while BOA enforces certain conventions, it dramatically improves security, performance, and reliability out of the box.

This opinionated structure also removes much of the manual overhead and sysadmin expertise typically required to run and maintain Aegir. At the same time, BOA still provides a broad range of configurable options, so users retain flexibility where it matters most. Ultimately, the goal is to empower users by simplifying complex tasks, not to limit them—making Aegir more accessible and sustainable for a wider audience.

@steven-jones Rather than migrating everything entirely to GitHub (though we do maintain active GitHub and GitLab mirrors), our intention is to continue maintaining the canonical repositories on GitHub, while also keeping the Drupal.org codebases in sync. This way, we preserve the existing issue queues and community history, and allow contributors to continue engaging with Aegir on Drupal.org. We believe this approach strikes the right balance between forward momentum and continuity for long-time users and contributors.

We at Omega8.cc continue to actively maintain all key Aegir 3 projects and related modules, including Drush 8, on GitHub. This includes full support for modern stacks such as the latest PHP, Percona (MySQL) versions, and Composer integration. We are committed to maintaining these components for the foreseeable future.

To avoid the misconception that Aegir 3 is abandoned or unmaintained, we would like to propose formally recognizing our ongoing maintenance efforts and making this more visible to the broader community. With the previous method of installing and upgrading Aegir via Debian packages no longer available, we believe the time is right for us to take over official maintenance of Aegir 3 components and clarify that the project is still actively supported and being developed—primarily through our BOA (Barracuda Octopus Aegir) stack integration.

For users seeking a stable and supported path forward, BOA offers a mature and production-ready solution. To further ease adoption, we are working on two key extensions:

1. A BOA in-place conversion tool to allow any Aegir 3 server (running either Nginx or Apache) to be converted to a native BOA configuration without requiring site migration.

2. An enhanced BOA migration script to automate the full transfer of Aegir instances—not just between BOA-managed servers, but also from legacy Aegir 3 servers to BOA if preferred.

In addition to Aegir, we also maintain our Drupal 7 core fork and are committed to publishing timely security and feature patches. Our work builds upon various community-led initiatives to keep Drupal 7 LTS alive and sustainable. At the same time, we are also preparing a contingency plan for the future, in case Drupal 7 eventually loses even the current LTS options. If that situation arises, our goal would be to migrate Aegir 3 to Backdrop CMS as a long-term solution. Only at that point would it make sense to officially retire Aegir 3 on Drupal.org, but we believe we are still years away from such a transition.

We welcome your feedback on this proposal. If the community agrees, we would be happy to proceed with maintaining Aegir 3 "the BOA way," ensuring its ongoing availability, development, and compatibility with modern hosting needs.

You need this patch: https://github.com/omega8cc/hosting/commit/1fe13f2b3d567e01f2cd7cf7d3924...

Hello, I am happy to see you joining the effort to keep Aegir 3 alive.

We at omega8.cc have demonstrated last year that it’s perfectly possible to support Drupal 10 and beyond with surprisingly little effort and just a few tweaks to both Drush 8 and Aegir.

Since our efforts are not limited to making it possible to host Drupal 10 and beyond, we have already forked Aegir to add many new features which required some controversial modifications, including switching the admin interface to Backdrop CMS before D7 dies for good.

We also don’t support Ubuntu nor Apache, not even Debian after we have switched our BOA stack to Devuan, so it further limits our ability to support standalone Aegir 3 as it stands now.

That’s why having you onboard may be useful for those thinking about keeping their Aegir servers close to the project origins.

Anyone else will be able to easily migrate to BOA based Aegir 3 fork already supporting Drupal 10 and soon also Drupal 11. I will post about it separately.

Welcome to the team and hope others will welcome you too.

This has been fixed in BOA and we need to commit the fix back. While not recommended, it’s still useful for users trying to fix issues they can’t fix with system nor local Drush.

The patches looked promising, but they don't fix the problem in our tests (see the first run in the attached log), plus they break compatibility with PHP 7 (see the second run in the attached log) required by older sites and Aegir itself, since it's not yet fully PHP 8.1 compatible until we commit upstream some BOA patches. I'm thus bringing this issue back to Aegir 3 branch, which is currently our focus here.

Hey @porchlight, we are currently preparing to backport our patches to all relevant parts of Aegir and will also post a how-to to list requirements and changes normally automated in BOA but requiring some simple manual work for standalone Aegir. New issues will be opened to track this process.

TL;DR BOA supports Drupal 10 while running slightly modified Drush 8. We don’t need newer Drush versions and we shouldn’t.

Longer version follows.

Aegir 3 can work only with Drush 8 because it’s the only still supported Drush version which can be reliably used as standalone Drush.

All post-8 Drush versions up to 11 could theoretically be used as standalone (on command line but not with Aegir) if their dependencies matched the managed Drupal site code, which in practice happens rarely and thus should be used as site-local only.

Composer doesn’t care about possible versions conflicts between Drush and Drupal and you could get pretty different versions of the same Drush release installed depending on when you have installed it. This makes using them as standalone a completely unpredictable mess.

That’s why Drush 12 has been officially announced as the first version which can’t be used as standalone at all — no matter how hard you would try.

The only question was therefore: can we make the old good Drush 8 able to avoid conflicts despite aggressive deprecation coming with Drupal 10?

It seemed impossible initially, so we at Omega8.cc launched a complete rewrite of our BOA stack to make it use Aegir 3 without Drush — at least without the way it was always used, based on bootstrapping Drupal directly, with the intention to use it as a bridge with our own backend code, not affected by any Drush and Drupal compatibility issues.

It turned into serious rabbit hole and we have realized we couldn’t make it a mature enough project before Drupal 9 EOL, which in turn got us back in the dirty hacking and trying to make things work, removing obstacles as we go through tedious and frustrating debugging and testing cycles.

We didn’t believe it was possible, really, but we just wanted to give it a try before taking the risk of switching horses completely and without option to go back.

Guess what.. it worked! We are planning to release it tonight and upgrade all hosted Aegir systems later this night. More details are coming once we have more free time.

Take a look: https://github.com/omega8cc/boa/issues/1678#issuecomment-1778803057

Well, the news about Aegir 3 death were greatly exaggerated. Here’s visual proof: https://github.com/omega8cc/boa/issues/1678#issuecomment-1778803057

Aegir 3.x actually supports both PHP 8.1/8.2 and latest Drupal 9.x but not in this main/current upstream version but in the BOA fork, so we are working on backporting all accumulated fixes/patches.

Do we have any reference for the changes committed to Provision 4 and Provision 5 branches?

I have looked in the patches for a few months back and both look like heavily experimental sandboxes without any issues referenced, so they almost look like private repository not intended to be used by the community?

My questions arise since we plan to backport many accumulated patches from our BOA fork to bring the Provision 3 up to speed to fully support both PHP 8.1/8.2 and Drupal 9 and then we considered creating separate branch for the work being done on the Drupal 10 support, which is quite separate effort and can't be continued in the 3.x branch, while changes in 4.x and 5.x look pretty drastic without any documentation to figure out either backward compatibility or at least compatibility matrix -- like supported Drupal core, PHP and Drush versions.

I have already noticed many patches there similar to our attempts to overcome the limits of 3.x branch, so making this work more transparent could certainly help in avoiding reinventing the wheel.

This module works with any redis server version, we are using it with latest 7.x for a long time already.