Docker

The 2 costs nobody puts on the budget: setup and drift

Ask a team that runs more than 1 Drupal(Opens in a new tab/window) site where its time goes, and 2 answers come back.

The first is setup. Every new project spends weeks on the same groundwork before anyone builds a feature:

• local environments
• CI pipelines
• hosting wiring
• code quality tooling
• a test harness

The second is drift. Once a project is running it grows its own arrangement of tooling, so a year later moving a developer between 2 of your own sites means learning 2 different machines.

Neither cost appears on a budget line, and both are paid again on every project.

Installed once and kept current: local environment, CI pipelines and hosting

Vortex(Opens in a new tab/window) is a Drupal project template: a tested foundation you install once, pick features from, and then keep current for the life of the project.

The template is the pre-configured Drupal project itself, wired together and working on day 1:

• a containerised local environment
• CI pipelines
• hosting integrations
• code quality tooling
• a testing harness

Documentation ships with it, including an onboarding checklist for new team members. An installer adds only the features you chose, from hosting and CI provider through to theme and AI agent instructions. On the current line that tool is the installer; the next major moves the job into a dedicated Vortex CLI.

That upgrade path is what separates Vortex from a starter kit, which is a one-time copy frozen at whatever it got right in its year. Vortex keeps the path open, so a project set up in its first year can adopt improvements made in its third through the same tool that created it.

For a client, that reads as continuity: the foundation under your site keeps getting the improvements made after your project started.

Whichever features you pick, local, CI and hosting all run the same provisioning path. That single decision is where "works on my machine" stops being a recurring argument.

The quality gates arrive switched on: secret scanning, static analysis, 90 per cent coverage

Plenty of templates leave quality tooling as an exercise for the reader. Vortex ships the gates configured and running across the whole codebase:

• secret scanning
• dependency auditing
• container linting
• static analysis
• coding standards

A 90 per cent code coverage threshold fails the build by default, with the result posted back onto the pull request. Visual regression waits behind an opt-in label, so an expensive check runs only on the changes that warrant it. Third-party CI actions are pinned by commit hash, a ready answer to a supply-chain question many teams are now being asked.

Every gate can be switched off with a single variable, and that matters more than it sounds. A team can adopt the pipeline on day 1 without being blocked by it, then tighten it as they go. It is the difference between a pipeline people keep and one they quietly delete.

The documentation is held to the same standard: linted, tested, and gated against drifting out of step with the code.

9 years in and busier than ever: 111 releases across Drupal 7 to 11

The usual failure mode of a project template is quiet abandonment: excellent for 18 months, then attention moves elsewhere and the repository goes still.

Vortex began in July 2017 and has shipped 111 releases since. It has tracked Drupal 7, 8, 9, 10 and 11 across their lives, and today it targets Drupal 11.

Releases go out on a stated monthly cadence, borne out across the recent run. A second major version is already published alongside the first, with the release plumbing built so that promoting a new major to the default is a single configuration change.

It is being developed more actively today than in any year of its life.

111 releases since 2017, across Drupal 7 to Drupal 11, and busier today than in any year of its life.

For a client, that history reads as low risk: the foundation under your project is maintained by the team you are already working with.

Open source under GPL-3.0, and used on the work we are paid for

Vortex is open source under GPL-3.0 and developed in public: repository, issue tracker, releases and documentation are all open. Community support runs through Drupal Slack and GitHub issues, and paid support is available for teams that want a commercial contact behind it.

We use it ourselves, which is the part that keeps it honest. Our own website runs on Vortex and is offered openly as a reference for what a long-lived Vortex project looks like, and the client platforms we support run on it too. The template meets real delivery pressure, not only its own test suite.

The flow runs both ways. Tools that began inside client work ship with Vortex, including our Behat step library(Opens in a new tab/window), CI runner image(Opens in a new tab/window) and artifact deployer(Opens in a new tab/window). Pieces that outgrow it are published in their own right.

For teams paying the setup cost on every Drupal project

Everything on this page is 4 of our services pointed at our own product: the architecture of the template, its development, the DevOps and hosting wiring it ships with, and the support and maintenance that has kept it current since 2017. The same template ships the AI agent instructions behind our AI-assisted delivery, and the gates decide what is allowed to merge.

If you run a portfolio of Drupal sites, or a team that starts a new project every few months, this is the shape the engagement takes: your sites build, test and deploy the same way, new developers onboard against a stack they have seen before, and improvements arrive through the same tool that set the project up.

If your Drupal projects have each grown their own build and nobody can move between them, tell us what your setup looks like today.

Government is organised by department. People are not: the case for one shared web platform

When you need something from government, you rarely know which department owns it. You know what you need: a permit, a payment, advice after a storm.

Yet a lot of government websites are still laid out the way the organisation is, because that is how digital tends to grow. One department at a time, each with its own site, its own supplier and its own way of publishing.

Victoria set out to change that. The Single Digital Presence programme aimed to bring 50 government websites onto one platform with one publishing standard, working to a principle that is still the clearest sentence we know on the subject: content belongs to the people who need it, not to the department that happens to own it.

What we built: the API layer, the multi-site engine and the testing architecture

Single Digital Presence is open source, and the record of who built what is public with it. Starting in 2017, we created most of the repositories behind the platform's Drupal(Opens in a new tab/window) layer, including its API layer, its multi-site engine and its testing architecture.

The pattern was the same across all of them. We laid the foundations before any feature work:

• the project scaffolding every repository is built from
• the continuous integration that runs on each change
• the automated tests over the behaviour that matters
• the developer workflow the teams work in day to day

The department's own team and its delivery partners then filled that structure with features. For a client, that order reads as a head start: whoever arrives next inherits a working pipeline instead of building one. The programme's technical lead credited the distribution and its testing approach from a conference stage in 2019.

In 2019 the Department of Premier and Cabinet contracted us directly, off the Victorian Government eServices Register, to write the developer documentation for the platform: how to work with the code, test an API endpoint and release a module. It shipped as a documentation site with a build that refuses to deploy if an internal link is broken.

One Drupal content system, many public websites: decoupled publishing with real preview

The heart of the platform is one Drupal content system serving many separate public websites, each with its own domain, brand, menus and homepage, all edited by agency staff in the same place. There is no separate installation per site.

A site is a piece of structured content, which makes bringing another agency on board a content decision, not a rebuild. For an agency joining later, that reads as a shorter path to launch: your site is configured on a platform that already runs, rather than procured and built again.

The public websites are rendered by a JavaScript front end, so Drupal serves content rather than pages. That split is good for performance and reuse, and it raises the question every organisation asks about decoupled publishing: how do editors preview their work when the content system renders nothing?

The platform's answer is one of the neatest we have seen, and it was not ours. The editor clicks Preview and lands on the real front end, which renders the unpublished draft exactly as the public will see it. We have carried that technique with us ever since.

Keeping a platform honest as it grows: shared testing across many repositories

The platform's Drupal code lives in many small repositories, each tested on its own. That is good for release safety and hard on consistency: every repository needs its own development environment, test harness and build pipeline, and copies of the same setup drift apart the moment nobody is watching.

We answered it in 2 pieces. The first was a shared test module giving every repository a neutral content type to write tests against, with a filter that scrubs its own fingerprints out of the site's exported configuration, so the test harness stays out of what the site ships. The second was a development toolkit that repositories fetch rather than copy: one small file each, one command surface, one place to change how everything is built and tested.

Where it got to: vic.gov.au, nearly a decade on

The platform is in service. vic.gov.au(Opens in a new tab/window) runs on it, its repositories are public and still active, and its front-end component library is published for anyone to install.

Each layer, hosting, content management and front end, was designed to be taken on its own, so another agency could adopt just the part it needed. Other Victorian agencies were building on the model within the first 2 years.

Nearly a decade after those first commits, vic.gov.au still runs on the platform.

The work outlived the engagement, and the teams who came after us could keep building on it. That is the outcome we care about most.

For governments bringing many websites onto one platform

Everything on this page is 3 of our services on one shared government platform: architecture for a multi-site Drupal system, development of the modules and the API layer behind it, and the DevOps that builds and tests every repository.

If you run a department, an agency, or a group of sites that each grew their own way, this is the shape the engagement takes: foundations first, tests and pipelines before features, and a platform layer other teams can build on. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are consolidating agency websites onto one publishing platform, or trying to keep a growing set of repositories consistent, tell us what your estate looks like.

A university web platform is never finished: upgrades, new brands and content migrations

A university website carries a decade of accumulated content, an audience that never accepts an outage as an explanation, and a platform that reaches end of life on a schedule somebody else set. There is always a version to upgrade, a brand to stand up, content to bring home.

Most of that work arrives irregularly and none of it can be deferred, which is an awkward shape to hire for. Victoria University(Opens in a new tab/window) runs its own Web Services team in Melbourne and brings in specialists for the peaks. We have been one of them since 2017.

Working alongside the university's own team: platform engineering from Drupal 7 to Drupal 11

The university's team owns the estate day to day. We provide the platform engineering, the architecture and the delivery practice underneath it, and we hand over what we build as we go. Building technical understanding inside their team has been part of the arrangement from the first year, not something bolted on at the end.

In practice that means:

• a build that runs on Vortex(Opens in a new tab/window), our open-source Drupal project template
• preview environments that appear per change
• automated testing
• release tooling
• hosting
• a rolling programme of upgrades that has carried the estate from Drupal(Opens in a new tab/window) 7 to Drupal 10 and now Drupal 11

For a client, that reads as capacity without a handover cliff: the specialists arrive for the peak, and what they built stays understood inside your own team.

New brands, and content brought home: a vocational site and an institute migration

The university's vocational brand had been sitting inside the main site as a section of it. We built it out as its own website on its own domain, with the university's own team moving the content across.

A few years later we consolidated the separate site of one of the university's policy institutes into the main site. A research institute's whole value is its published papers and the authors attached to them.

So instead of writing scripts for 2 months and finding out on launch night whether they covered everything, we ran the migration continuously throughout the build, proving it against the real content every day. For a client, that turns launch night into a rehearsal you have already run rather than the first full test.

Researcher profiles people can actually find: a searchable directory of academics

An academic profile is commercial infrastructure for a university rather than a vanity page. It is how:

• an industry partner finds a collaborator
• a research student picks a supervisor
• a journalist finds someone to comment

Working to the university's own requirements, our team built its public directory of academics: a profile the academics drive themselves through an editorial workflow, and a search that finds people by expertise rather than by name. Publications, grants and supervision history arrive from the university's own systems, and the rest belongs to the academic to write.

For anything opt-in, adoption is the number that matters. Within weeks of launch, 271 of the 354 academics in scope had a published profile.

Moving the whole platform with no planned downtime: the Lagoon hosting migration

In 2021 both public websites moved onto one hosting platform, amazee.io Lagoon, and every non-production and preview environment moved with them. That second part is the difference between relocating a website and moving a team's whole way of working.

There was no planned downtime, and that came from sequencing rather than heroics. Each site was stood up on the new platform first, its integrations moved and tested there, and the university's team validated it with their own tooling and acceptance testing before traffic followed. Publishing paused for a business day.

What 9 years adds up to: 3 measured results and 2 open-source tools

3 pieces of this work have a number on both sides of them.

• Long-lived sites accumulate weight, and the weight is usually not growth. Most of what was sitting in this one's database turned out to be historical data nothing referenced any more, and removing it left the database 63 per cent smaller.
• Editors on large sites often wait hours for a published change to appear. We measured that end to end and brought the worst case down from most of a day to about 20 minutes.
• Asked to speed up a test suite that took close to 30 minutes, we found 3 of our 4 assumptions about the cause were wrong: the tests were waiting on third-party assets, not on the application. That path ended up about 3 times faster.

A database 63 per cent smaller, and a published change live in about 20 minutes instead of most of a day.

Some of it has come back out as open source. The deployment tooling we first wrote here became drevops/git-artifact(Opens in a new tab/window). And the practice of shipping the development database inside a Docker image, born on this platform so every developer and pipeline starts from real data, grew into drevops/mariadb-drupal-data(Opens in a new tab/window).

9 years, continuous, across 3 generations of architecture. In a market where suppliers rotate every couple of years, that is the outcome we are proudest of.

For web estates that outlive their suppliers

Everything on this page is 4 of our services running on one university estate: development alongside an in-house team, migration of content and of whole platforms, DevOps and hosting, and the training and handover that leaves the knowledge inside the client's team.

If you run a university, a TAFE or another estate that has to keep serving while it changes underneath, this is the shape the engagement takes: specialists who arrive for the peaks, a rolling upgrade programme instead of a rebuild, migrations rehearsed against the real content, and the knowledge left with your own team. The same engineering is available with AI-assisted delivery where the work suits it, at the same tested standard.

If your estate has a Drupal site heading toward end of life, or content sitting in a separate site that should not have one any more, tell us what is on the platform.