When a Drupal release depends on one person running commands on a server, every deployment is an event and every change waits for that person. We build the deployment side for your team: Docker images that behave the same on a laptop, on staging and on production, a CI/CD pipeline that runs the tests on every merge request, and a deployment job with a rollback that has been tried. The whole setup is defined in files in your repository, so your developers run it and change it without us.
- Who this is for
- A team that deploys by copying files or typing commands on the server. Developers whose local sites never quite match production. A release process only one person understands. An in-house team or agency moving an existing Drupal site into containers.
One build, every environment The image tested on staging is the image that reaches production
Local DDEV on each developer's machine, from the same container definition
Merge request
CI pipeline Coding standards, static analysis and tests, then one image built and tagged
Same image
Staging Checked end to end
Production Promoted after approval
What you get
- Docker images for your Drupal site, built once in CI and promoted unchanged from staging to production
- A DDEV configuration, so a new developer has a working local site from the repository alone
- A CI/CD pipeline that runs PHPCS, PHPStan, PHPUnit and Playwright on every merge request and stops a failing change from merging
- A deployment job that runs
drush deploy: database updates, configuration import and cache rebuild, in that order, every time - Deployments designed to keep the site online: the new release is built and checked before traffic moves to it
- A rollback to the previous image, tried on staging before it is ever needed
- Secrets and environment settings kept out of the repository
- Runbooks for deploy, rollback and restore, written for your team
A Drupal build is a Composer build: core and contributed modules, such as WE Mega Menu which we maintain on Drupal.org, are pinned in composer.lock, so every environment installs exactly the same code.
Sample Runbook example.org · kept in the repository
Deploy
- Merge request approved and pipeline green
- Image promoted from staging Same tag, no rebuild
drush deployrun by the pipeline
Roll back
- Previous image tag redeployed
- Database restored only if an update changed it Decided before the release
- Rollback noted in the release log
Restore
- Latest backup restored to a clean environment
- Files directory synced
- Site checked, then DNS or traffic switched
An engineer reads it and replies within one business day.
How the work runs
Each step leaves something in your repository that your team can run without us.
How a Drupal DevOps engagement runs
- Audit How a change reaches production today, the environments, the backup position and what is worth keeping. You keep the environment audit
- Reproduce A local environment and a staging site built from one container definition. You keep the DDEV and Docker configuration
- Pipeline Checks, tests and the image build wired into the CI service your repository uses. You keep the pipeline configuration
- Rehearse Deploys and rollbacks run on staging until both go through cleanly. You keep the release log
- Handover Your team runs a release and a restore with us watching. You keep the runbooks
From commit to production
Every release takes the same path. A failing check stops the release where it fails, so a broken change never reaches the next stage.
A Drupal CI/CD pipeline
- Merge request A developer pushes a branch.
- Checks PHPCS for coding standards, PHPStan for static analysis. A failure blocks the merge
- Tests PHPUnit for unit, kernel and functional tests. A failure blocks the merge
- Build One Docker image built and tagged.
- Staging The image deployed,
drush deployrun, Playwright tests in a browser. A failure stops promotion - Production The same image promoted after approval, with the previous one kept for rollback.
What we do not promise
This is what a DevOps engagement commits us to, and what belongs in a written agreement instead.
| Topic | We do | We do not promise |
|---|---|---|
| Uptime | Monitoring, a tested rollback and a tested restore | An uptime percentage as a headline; a commitment belongs in a written SLA under maintenance and support |
| Dependence on us | A standard, documented setup somebody else could take on | That you will never need help again |
| Security | Secrets kept out of the repository, TLS, and administrative paths off the public internet | That the application code is secure; that is a security audit |
| Speed | Caching layers and a CDN configured as part of the build | Faster pages from infrastructure alone; slow templates and queries are separate work |
After handover
You get the configuration in your repository, the runbooks, and a restore that somebody on your team has performed with us watching. Your team runs the pipeline from then on. If you would rather we ran the environment itself, that is managed Drupal hosting; if you want us to keep the application current, that is maintenance, the arrangement we run on the systems we built, such as CreAct.
What it costs
Setting up the pipeline and the environments is quoted once, against the number of environments, the applications involved and the integrations that have to keep working. It is priced from the DevOps and Support Engineer rate on the pricing page.
Running costs after that are the cloud provider's, paid by whoever owns the account, and we do not mark them up. If you want us to operate the environment afterwards, that is a monthly agreement in the Maintenance and support band.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Can you improve our current setup without rebuilding it?
Usually. The audit establishes what is worth keeping before anything is replaced, and a part of the pipeline that already works stays as it is.
Do our developers have to learn Docker?
They run it, but they do not have to learn it first. DDEV wraps the containers in a few commands, and the configuration in the repository gives every developer the same PHP version, database and services as production.
How do deployments avoid downtime?
The new image is built and tested before any traffic reaches it, so the slow part of a release happens while the current version is still serving. What remains is the database update and configuration import in drush deploy. For most releases that step is short; a release with a long-running update is planned with you in advance, with a short maintenance window where one is needed.
Which CI service do you use?
The one your repository already uses, provided it can build containers. The pipeline is a file in your repository, so your team can read it and change it like any other code.
Can you set this up for a site you did not build?
Yes. The audit covers how the site is built and deployed today. The pipeline is then fitted around the codebase as it is, and anything that blocks it, such as configuration that was never exported, is listed and fixed first.
Not covered here? Ask us directly.
Describe your deploymentAn engineer reads it and replies within one business day.
Run
Related services
Tell us how a change reaches production today
Describe the current deployment, and we will say what is worth fixing first and what is fine as it is.
An engineer reads it and replies within one business day.