Drupal configuration management and CI/CD guide

Why Drupal configuration management and CI/CD matter once more than one environment exists

When a Drupal site has more than one environment, the question that matters is not whether changes can be made, but whether they can be moved in a known order. Drupal configuration management with a versioned sync directory, a Composer-built codebase and a tested pipeline lets teams promote content types, views, roles and settings from development to staging to production in a repeatable sequence. Without that, the production site becomes the only place where the current state is written down, and nobody can say with confidence which environment is correct. The usual starting point is familiar. An editor or administrator adds a field on production because it is urgent, a developer makes a matching change locally, and a third person adjusts a role permission in staging to test something. Each change is reasonable on its own. Together they produce three versions of the site that differ in ways no one has listed. The first step for the reader is an inventory: compare the active configuration in each environment against the exported sync directory and count the differences. The result tells you how much of the drift is already in production and which team made each change.

Configuration management is harder than it looks because three layers are mixed together. Code is the custom modules, themes, Composer files and patches that the team controls in version control. Exported configuration is the YAML that describes content types, fields, views, roles, text formats and most site settings. Content is the nodes, media, taxonomy terms and users that editors create every day. Exported configuration can be deployed, but content usually cannot be overwritten without losing work, and a configuration export that includes content dependencies, or content that depends on configuration not yet deployed, will fail in ways that surprise teams. Decide early which layer each change belongs to and who may change it. Some settings must differ by environment. Database credentials, mail relays, API keys, caching backends, trusted host patterns and the staging-only modules used for testing should live in environment-specific settings files or environment variables, not in the shared sync directory. Teams that skip this step either commit secrets or deploy a production setting to a test server. Confirm the list of environment-specific settings with the people who run each environment, and agree on a rule for what happens when a new setting is needed.

Dependencies add a second clock. Contributed modules and Drupal core receive bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule. Major versions arrive about every three years. A pipeline that rebuilds the codebase from Composer lock files each time is the only dependable way to absorb those updates without hand edits. The platform requirements also change by major version: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. The build image, the test runner and the production web servers need to agree on the PHP version before any pipeline stage can be trusted. The work is usually more about process and ownership than about tooling. Someone must own the sync directory, approve what enters it, and decide when a production change made by an editor is accepted back into code or reverted. Someone must own the pipeline and its test suite. The tools in this topic, including Configuration Management export and import, Drush deployment commands and automated tests, work well only when those owners exist and the team follows the same order every time. This applies to every supported Drupal major version, including Drupal 11, which is the current major version, and Drupal 12, which the Drupal core release schedule places for the week of December 7, 2026. Drupal 10 reaches end of life on December 9, 2026, so a site still on Drupal 10 faces a version change that will also need a clean, tested deployment path. Confirm with your own team which version runs in each environment today before you choose a pipeline design.

Which Drupal parts carry code, configuration and content

A Drupal pipeline moves three things that behave differently: code from Composer and custom modules, configuration from the sync directory, and content in the database and file system. Each component below owns one of these, so map them before choosing which changes travel through the pipeline and which never should.

Configuration sync directory and export import

The sync directory holds the YAML files that describe site configuration, such as content types, views and permissions, and it is usually versioned in the repository. Core Configuration Management exports the active database state into these files and imports them into another environment. If a field or view is changed directly on production, the next export overwrites the change or the next import reverts it, so confirm which environment is allowed to change configuration before the first deployment.

Composer dependencies and the lock file

Composer declares Drupal core, contributed modules, themes and libraries in the composer.json file, and the composer.lock file pins the exact versions that were tested. Each environment should install from the lock file so that a deployment runs the same code the pipeline tested. Editing contributed code on a server, or running composer update on production, produces a build that no test run has seen and that the next deployment cannot reproduce.

Drush commands for deployment

Drush runs the steps that follow a code deployment: database updates, configuration import, and cache rebuilds. The order matters, because new code may depend on database schema changes and configuration that must be imported before caches are rebuilt. Confirm the exact command sequence for your Drupal version with the core documentation and test it on a copy of production, since a failed step left half-applied is harder to recover than one that never started.

Settings.php and environment overrides

The settings.php file and any included environment files hold database credentials, the configuration sync path, hash salts, trusted host patterns and cache backends. These values differ by environment and should come from the server or the pipeline, not from the repository. Editing them by hand on production is a common source of drift, so review every change to these files as carefully as a code change and keep secrets out of version control.

Database and content state

Content entries, users, menus, and file uploads live in the database and the public files directory, and configuration export does not move them. A pipeline that deploys code and configuration still needs a rule for content, such as creating content only on production or copying a sanitized snapshot to lower environments. Confirm with the content owners which data may leave production, because test copies often hold personal data.

Test tooling and the CI runner

Automated tests, such as PHPUnit and browser tests, and static analysis run on a CI runner that rebuilds the site from the repository. The runner's PHP version must match the requirement of the Drupal version in use: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. A runner on an older PHP version can pass a build that production cannot run, so pin the runner image and check it at every Drupal upgrade.

Which deployment model fits your team and change rate

This table compares four ways to move Drupal changes between environments, from core configuration sync to whole-artifact deployment and content flow. Read each row for when the option fits your change rate and team, what it costs to run day to day, and what to confirm before you commit. The main takeaway is that the more environment-specific logic and content you keep out of the repository, the simpler reviews and rollbacks tend to be, but the more discipline the team must maintain.

Model	Fits when	Operational cost	Confirm with the team
Core configuration export and import	Small team, few site builders, infrequent config changes, one primary environment per stage	Every config change is a YAML diff that needs review; merge conflicts in exported files are common when two people edit the same content type or view; rollback means reverting files and re-importing	Who owns the sync step, whether production edits are forbidden, and how often config is exported and reviewed
Split configuration with a contributed split module	Environments need different values such as debug settings, mail routing or third-party keys, and you want those kept out of shared config	Extra split definitions to maintain; a mistake can export a value to the wrong environment; more moving parts in the import order	Confirm the split module's release for your target Drupal version before adoption, and who approves changes to split rules
Composer-built artifact deployed as a whole	Several developers ship often, you need repeatable builds, or you run more than one web node	Build pipeline and artifact storage to maintain; rollback is redeploying the previous artifact, which requires database and file handling to be planned separately	Where artifacts are built and stored, how database updates run during deploy, and who owns Composer lock file updates
In-place updates on servers	A single server, a small change rate and a team that can manually verify each release	Lower tooling cost, but drift between servers grows over time and rollback depends on manual backups and operator steps	Whether production has a tested backup and restore path, and how server state is kept identical to the repository
Content moves through the pipeline	Content is seeded, tested or migrated between environments, such as demo content or landing pages built by developers	Content exports are large and hard to diff; sensitive data can leak into lower environments; editors' production changes can be overwritten	Which content types are pipeline-managed, how personal data is excluded, and whether editors create content only in production
Content created only in production	Editors own all content and developers only ship code and configuration	Simpler pipeline, but staging tests run against non-representative content and content issues surface only after release	Which test data is needed in staging, and how editorial workflows are checked before a release reaches production

How to set up a configuration sync pipeline in the right order

This sequence moves Drupal configuration from a single agreed codebase through review, staging and production with repeatable checks at each stage. Each step closes with an observable result, so the team knows the pipeline is trustworthy before it carries real changes.

Establish one Composer-managed codebase
Put the Drupal project under Composer, with core, contributed modules, themes and custom code declared in one composer.json, and commit the composer.lock file to version control. The team lead or platform engineer owns this step, and every environment builds from this one repository rather than from hand-copied files on servers. Check it by deleting the vendor directory on a clean machine, running a Composer install from the lock file, and confirming the site boots with the same module versions listed in the lock file.
Choose and freeze the PHP version
Select the PHP version that matches the target Drupal major version using the Drupal PHP requirements, then pin it in the Composer platform configuration and in the build image or runner that executes the pipeline. Confirm the Drupal release you plan to run supports that PHP version before you pin it, and ask your hosting provider to confirm the same version is available in each environment. Check it by running a Composer install and a Drupal status report on the runner and getting the same PHP version string as the production server.
Create a clean configuration baseline
Choose one environment as the agreed source, usually the environment where the site was built or last changed by hand, and export its configuration into the codebase. Review the exported files so the team understands what is being committed, then import that configuration into a fresh copy of the database. Check it by running the configuration status command and confirming it reports no differences between the database and the exported files.
Separate environment-specific settings
Decide which values differ between environments, such as database credentials, mail relays, API keys, trusted host patterns, caching backends and staging-only modules, and move them out of exported configuration into environment settings files or environment variables. The architect and the Drupal lead make this decision together, because a setting left in exported configuration will override the target environment on the next import. Check it by exporting configuration again from the source environment and confirming the files contain no secrets or host-specific values, then rerunning the status report on a second environment with its own settings.
Define the local, review, staging and production flow
Document which environment each change passes through and who approves each promotion: local development, a review environment created for each merge request, a staging copy that mirrors production as closely as the client can arrange, and production. Agree on which environment is allowed to write configuration and make sure production never exports its own changes back into the repository. Check it by walking one small configuration change, such as a field label, through all four environments and confirming it arrives in production through the pipeline without manual edits.
Add automated tests on each merge request
Configure the CI runner to install from the lock file, run code style checks, run the configuration status check, and run the automated test suite on every merge request, including PHPUnit tests for custom modules and any functional tests the team has written. The QA or development lead defines which tests block a merge, and the platform team maintains the runner. Check it by opening a test merge request, confirming the pipeline reports pass or fail for each job, and seeing a deliberate configuration drift fail the build.
Script the deploy order
Write one deployment script that runs in a fixed order: deploy the code artifact, apply database updates, import configuration, then rebuild caches. Keep the order in the script rather than in an operator's memory, and make the script stop at the first failing step. The platform engineer owns the script and the operations team runs it in each environment. Check it by running the full script against staging and confirming each step logs success and the configuration status report is clean afterward.
Add a rollback path from the previous artifact
Store each built code artifact with its version identifier so that the previous release can be redeployed without rebuilding from source. Agree with the client how database changes are handled during rollback, since a configuration import cannot always be reversed by redeploying old code alone, and document that decision with the runbook. Check it by deploying the previous artifact to staging after a test release, then confirming the site serves the earlier configuration and the status report is clean.

How review and production pipelines separate code from content

A sound pipeline keeps three things apart: code that moves through review, configuration that is exported and imported on purpose, and content that belongs to the live site and must never be replayed from the repository. Review happens in an environment built from the repository for each merge request, so a reviewer sees the exact code and exported configuration under test, with fixture content or none at all. That environment is disposable and holds no real personal data. Promotion to production is a different path. It runs against a shared staging environment that mirrors production data policy: the same database engine and configuration sync settings, a recent copy of content with personal data masked under the organization's own rules, and the same web server and PHP versions. Confirm with your team which environment each check belongs to before the first merge request is opened. A production release should pass explicit gates, and each gate needs a named approver. The first gate is automated: the build installs cleanly from a locked Composer file, the test suite passes, and a configuration status check shows no unexpected drift. The second is a technical review by a Drupal developer who did not write the change, with attention to configuration export files, changed permissions and any update hooks. The third is a staging check by the site owner or product lead, who confirms that the content model and editorial workflows behave as expected on data that resembles production. The fourth is a change approval from whoever owns production risk, often the platform lead or CISO's delegate in regulated settings. Write these approvers into the release procedure so that no one has to guess who can say yes. The release calendar sets the pace. The Drupal core release schedule says bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday. Your pipeline should not depend on those dates, but it must be able to take an update out of cycle. That means a branch that updates Drupal core and contributed projects through Composer, runs the full gate sequence in staging, and produces a deployable artifact that can be promoted the same day a Security Team advisory is published. Practice this path before you need it. Ask your partner or internal team to show a dry run of an out-of-cycle security update, including the time it takes to move through each gate. Content is not replayed from the repository. Configuration sync carries structure such as content types, fields, views, roles and workflow settings. Articles, pages, media and user accounts live in the database and belong to editors. If a deployment imports content from code, or a fixture is loaded over live data, editorial work disappears. Treat any content fixture as test data only, and make sure production deploy scripts never run fixture loaders. Also decide how content changes made directly in production are handled. Editors work on live content by design, so the pipeline should not overwrite it. Instead, record which configuration changes were made on production (for example, a field added through the admin interface), export them, and bring them back through review so that the next deployment does not revert them. Production configuration must never be edited directly and then forgotten. A quick fix in the admin interface may solve today's problem, but it creates drift that the next import will either overwrite or silently keep. Set a rule that all configuration changes start in a branch, and make the configuration status check part of every deployment so that drift stops the release. If an emergency change is unavoidable, log it in the change record, export it within the same working day, open a merge request, and close the loop in staging. Ask your team to show the last three emergency changes and how each was reconciled. If the answer is unclear, the pipeline is not yet separating code from content in practice.

What drives the effort and cost of Drupal CI/CD work

This table lists the factors that move the effort and cost of Drupal configuration management and CI/CD work, with the practical way to keep each one under control. Read it before asking for a quote, because the same pipeline can be small or large depending on these inputs. Effort figures are not given here because they depend on the written scope.

Driver	Why it changes effort or cost	How to keep it down
Number of environments	Each environment needs its own deployment path, settings, secrets handling and verification steps, and each one adds recurring pipeline upkeep.	Limit environments to those with a clear purpose, such as development, staging and production, and retire the rest.
Number and size of contributed modules	Every contributed module needs a compatibility check during updates, and large or poorly maintained modules add test and fix work.	Audit the module list before automation starts, remove unused projects and prefer well-maintained modules with stable releases.
Environment-specific configuration	Settings that differ between environments, such as API endpoints or email routing, must be excluded from or overridden in exported configuration, which adds rules and review work.	Move environment values into settings files or environment variables and keep exported configuration identical across environments.
State of the existing site	A site with clean exported configuration can be automated quickly, while years of configuration drift require reconciliation before any import is safe.	Freeze a baseline of the current configuration and resolve drift with the site owners before the pipeline is built.
Size of the content model	Large numbers of content types, fields, views and workflows increase the configuration volume that must be reviewed and tested.	Confirm the content model in discovery and separate stable configuration from frequently changing content structure.
Test coverage the team expects	Automated functional, visual or accessibility tests take build time and require test data, fixtures and maintenance as the site changes.	Agree a defined test set in the written scope, starting with smoke tests on deployment and critical user journeys.
Integrations that need mocks or sandboxes	Tests that call external systems such as identity providers, payment services or CRMs need mocks, sandbox accounts or recorded responses, each of which must be maintained.	List every integration in scope and decide which will be mocked in tests and which will use a vendor sandbox.
Compliance or change-approval requirements	Approval gates, evidence retention and segregation of duties add pipeline stages, approval records and audit trail design.	Map the required approvals and evidence to specific pipeline steps early so they are built once, not added later.
Number of people merging changes	More contributors mean more merge conflicts in exported configuration, more review cycles and a greater need for branch rules and coding standards.	Set branch protection, a single review path and a documented process for resolving configuration conflicts before onboarding teams.

How the pipeline changes by hosting model

On a single node, one web server and one database serve all traffic, so the pipeline usually deploys in place. The build produces a Composer-managed codebase, the release is copied to the server, and configuration is imported with Drush during a maintenance window. Because only one copy of the code runs at a time, there is no ordering problem between servers, but a failed import is visible to users immediately.

Build: Run Composer install from the lock file on the build host, then package the codebase for the server. Do not run Composer on production.
Deploy: Put the site in maintenance mode, back up the database and files, deploy the code, then run database updates and configuration import.
Rollback: Restore the pre-deploy database backup and the previous code release. Confirm the backup restores cleanly before the window opens.
Verify: Run the automated smoke tests after the import and before lifting maintenance mode.
Timing: Agree the maintenance window with the business owners and record how long the import took in staging.

Confirm with the platform team how backups are taken, where the window is scheduled, and whether the hosting provider supports snapshot-based rollback.

Securing deployment credentials, exports and the update path

A Drupal configuration pipeline moves exported settings, code and database changes between environments, so the same mechanisms that deploy a change can also leak a secret or apply an unreviewed update. The four areas below cover where credentials live, who can change production, how the sync directory and settings are protected, and how security releases enter the pipeline.

Keep secrets out of exports

Database credentials, API keys and SSO client secrets should be supplied through environment variables or server-side settings, never written into exported configuration or the repository. Configuration export captures many settings, so a secret typed into a form field can end up in a YAML file under version control. Check each export diff before commit, and add an automated scan that fails the build when a value matches a secret pattern.

Limit who runs production imports

Configuration import and database update commands change live behavior, so restrict them to named roles or a deployment account rather than individual administrator logins. Confirm that the pipeline records who triggered each run, which commit was deployed and what the command output was. Ask your team to document the approval step between staging and production, including who can override a failed check and how that override is logged.

Protect the sync directory and settings

The configuration sync directory and settings.php should be read-only or unwritable by the web server process in deployed environments, so that a compromised site cannot rewrite its own configuration. Confirm that exported configuration does not expose sensitive values, such as mail passwords or key references, by reviewing a sample export from each environment. Restrict file permissions and keep database and private file paths outside the web root.

Route security releases through the pipeline

The Drupal Security Team publishes advisories for core and contributed projects, and security releases are issued on the third Wednesday of the month, while bugfix releases come on the first Wednesday. Subscribe the team to the advisory feed and schedule a test run for each security release so updates are validated in a staging copy before production. Commit every Composer dependency change with its advisory reference, so each update is traceable in version control. Pipeline evidence can support a compliance assessment, but independent auditors decide whether controls are adequate.

How to test that a deployment works and fails safely

A Drupal pipeline is only trustworthy if it proves two things: that a change lands correctly in production, and that a bad change stops before it gets there or can be reversed quickly. Each environment should pass a small set of checks before anyone calls a release done, and the failure path should be exercised on purpose rather than assumed to work. The checks below are the minimum we would expect a team to have in place before the first production release. The first check is a configuration status report. After each environment imports the configuration from the repository, the team runs the Configuration Management status check (through Drush, the config status command) and expects no unexpected differences. Any difference that remains after import means either a setting was changed directly on that environment, or the exported configuration in the repository does not match what the code expects. Both cases need a decision before release. Run the check on development, staging and production, and keep the output as release evidence. The second check is an automated test run. Custom modules should have unit and kernel tests for their own logic. Functional tests should cover the content types that carry business value, the roles and permissions that separate editors, reviewers and administrators, and the main user journeys, such as publishing a page through the editorial workflow or submitting a request form. Ask your team which journeys matter most to the business and write those tests first. A green run proves only what it tests, so the list of covered journeys should be part of your acceptance criteria. The third check is a smoke test immediately after each production deploy. It should confirm that the front page responds, that a test account can log in, that a form submission is accepted and stored, and that each integration endpoint (for example, a CRM or payment service) returns the expected response. Keep the smoke test read-only where possible, or use dedicated test records that editors can identify and remove. The fourth check is a scheduled drift comparison. A job compares the live configuration with the repository on a set schedule and alerts the owning team when they differ. Drift usually comes from emergency fixes made in the admin interface, and it is much cheaper to catch on the day it appears than during the next release. Proving the failure path requires two exercises. First, run a deliberately broken configuration import against a copy of production. The pipeline must stop at the import or status step and must not promote the artifact. If it continues, the gate is misconfigured and must be fixed before any production work. Second, roll back to the previous artifact on that same copy and confirm the site serves correctly. The database decision is the hard part: the plan must state whether a rollback restores a database snapshot taken before the deploy, whether it runs only the reverse configuration import, or whether content written since the deploy is kept. Each option has different data-loss consequences, so the choice belongs to the business owner as well as the engineers. Confirm the database approach with your own environment and backup tooling, because the exact commands and retention depend on your hosting setup. Rehearse the rollback before the first production release, and time it against the outage window your organization accepts. Record who makes the rollback call, how the team communicates with stakeholders during it, and what evidence is kept afterward. These checks are a starting point. They do not replace the acceptance criteria your business owners, security team and compliance function set for the platform, and they should be extended as the site gains integrations, content types and regulated data.

What to monitor, back up, upgrade and document after go-live

Once a Drupal configuration pipeline is live, its value depends on routine work that someone must own: watching the pipeline, protecting data, staying on supported versions and keeping the setup understandable. The cards below list those recurring responsibilities and the decisions that should be written down before handover.

Monitor pipeline health and drift

Track failed builds, failed configuration imports and drift reports from production, not only pass or fail on the main branch. Recurring failures in the same tests often point to flaky tests rather than real defects, so record flaky tests and fix or quarantine them with an owner and a date. Review drift reports on a fixed schedule, because unreviewed drift is the usual reason a later import overwrites an emergency change.

Back up before every production deploy

Take a database and file backup immediately before each production deployment, and store it outside the web server so a failed import can be reversed. Confirm the backup includes the private files directory and the settings that are not in version control. A backup that has never been restored is not a tested backup, so schedule restore tests into a non-production environment and record how long the restore took and what needed manual steps.

Keep Composer and PHP supported

Keep Drupal core, contributed modules and the PHP runtime on versions that still receive support. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so the runtime upgrade often has to come first. Align the pipeline with the monthly bugfix release on the first Wednesday and the security release on the third Wednesday, and confirm that test and staging environments receive the same updates before production.

Document the pipeline and environment map

Write down the pipeline stages, the environment map showing what runs where and which database and file store each environment uses, and the list of environment-specific settings such as database credentials, trusted host patterns and third-party keys. Keep these settings out of exported configuration, and check that the document names each one. Without this record, a new engineer cannot tell whether a difference between environments is intended.

Define configuration ownership and rollback

State which team owns each part of the configuration, such as content types and views, authentication settings and site-wide defaults, and who approves a change to each. Document the rollback procedure step by step: which backup to restore, how to revert the code release, and when to stop and escalate. Practice the rollback at least once before go-live so the steps are tested, not only written.

Assign owners for every recurring job

List each recurring task, including backup restore tests, dependency updates, flaky test review, drift review and release window checks, and name one accountable owner for each. A support retainer from DeployOpen can cover some of this work, such as monitoring, patching and restore testing, but the client should still decide which duties stay in-house. Write the division of duties down before handover so responsibilities are not assumed to belong to whoever noticed the problem first.

What buyers ask about Drupal CI/CD cost, time and effort

What drives the cost of setting up Drupal configuration management and CI/CD?

The cost is driven by how much of the pipeline has to be built, how many environments and repositories are involved, and how much of the existing site's configuration is already clean. Main drivers:

The number of environments (local, development, staging, production) and how they are promoted between each other
The state of the existing configuration: whether it is exported, consistent and free of environment-specific values
The test coverage that has to be added, such as automated tests run in the pipeline
Integration with the client's existing source control, build and deployment tooling
Documentation and handover for the team that will own the pipeline afterward

The effort table in this guide breaks these drivers down. A written, fixed scope is the basis for any quote, so ask for each driver to be stated as an assumption.

Is Drupal CI/CD work a one-time project or an ongoing cost?

The initial build is one-time, while pipeline maintenance and configuration drift checks recur. One-time work includes designing the export and import workflow, setting up Composer-based builds, writing deployment steps and configuring the pipeline stages. Recurring work includes updating pipeline dependencies, keeping tests working as contributed modules change, reviewing configuration that bypassed the normal workflow and checking that environments still match. Drupal core and contributed module updates also add recurring effort, because each update can change configuration and test results. Ask any partner to separate the one-time build from the support work in the quote so you can see what continues after handover.

How long does it take to set up Drupal configuration management and CI/CD?

The duration depends on the written scope and on the condition of the existing site, so no general duration applies. A site with clean, fully exported configuration and a single environment path usually needs less discovery than one with unmanaged changes made directly in production. Confirm these points before you ask for a schedule: the number of environments, whether a repository already exists, which tests are expected to run in the pipeline, and who approves changes. Ask for a scoped plan with phases, deliverables and the client inputs each phase depends on. A fixed-scope plan lets you compare options against a stated timeline rather than an estimate.

What does the client need to provide for a Drupal CI/CD engagement?

The client needs to provide working access and clear decisions, since the pipeline cannot be designed without them. Typical inputs:

Access to the source control repositories and the Composer project
Access to each environment, including permission to inspect configuration and run deployment commands
A named decision maker who owns configuration, meaning which settings are managed in code and which may be changed in the admin interface
Test data or a plan for producing non-sensitive test data
Access to hosting and deployment targets, and the people who approve production releases

Delays most often come from unclear configuration ownership, so settle that question before the build starts.

Can our internal team set up Drupal CI/CD without a partner?

Yes, an internal team can do this if it can run a Composer-based Drupal codebase and reviews configuration changes as code. Skills to check:

Working knowledge of the Configuration Management export and import workflow
Composer dependency management and the Drush commands used for deployment
Experience with a CI service and automated tests
A review process that treats exported configuration files as code changes

If one or more of these skills is missing, a partner can cover the gap through a fixed-scope build with handover documentation. Either way, the internal team should own the pipeline after go-live, so plan time for that from the start.

How does Drupal CI/CD relate to a Drupal upgrade or migration project?

A reliable pipeline makes upgrades and migrations easier to test, but it does not replace them. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later; they are migrated into a new site with the core Migrate modules or Drush, and their themes must be rebuilt. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, so a pipeline built now can run upgrade tests later. Practical sequence: stabilize configuration and the pipeline first, then run the upgrade or migration through it, so each change is tested in the same way. Confirm with the upgrade project lead which work is in scope for each engagement.

What should we ask a partner for in a Drupal CI/CD quote?

Ask for a quote built from a written scope that lists the environments, repositories, tests, deployment targets and handover items. A useful quote separates one-time build work from recurring support, names the client inputs each phase needs, and states the assumptions about the existing configuration. Ask who performs each task, whether the partner's staff or your team, and what documentation is delivered at handover. Ask how changes to scope are priced and approved in writing. DeployOpen does not publish a price list; a quote follows from the written scope, so the clearer the scope, the more comparable the quotes will be.

How DeployOpen scopes, builds and hands over Drupal CI/CD work

DeployOpen plans and builds Drupal configuration management and CI/CD inside the client's own infrastructure, with the work agreed in a written, fixed scope before any build starts. The sequence runs from scoping the current environments and change flow, through building and testing the pipeline, to handing over documented runbooks and an operating model your team can run.

How we scope

Map the current environments, how configuration changes move today, and who approves each promotion
Confirm the Drupal version, PHP version, database and hosting targets the pipeline must serve
Agree in writing which Composer, Drush and configuration sync steps, tests and pipeline stages are in scope

How we build

Put the site codebase under Composer with pinned dependencies and a committed configuration export
Set up review and production deployment stages that run configuration import, database updates and cache rebuilds
Add automated tests for critical site paths and configuration drift checks before any promotion step is enabled

How we hand over

Document the branching model, deployment steps, rollback procedure and secrets handling for your engineers
Walk your platform and content operations teams through a supervised production release from start to finish
Deliver the pipeline definitions, test suite and runbooks in your own repositories and accounts

How we support

Offer an ongoing support retainer to keep pipelines, Drush tooling and test suites working after handover
Include updates to pipeline steps when Drupal core, Drush or contributed modules change their deployment behavior
Confirm response expectations, environment access and coverage hours with the retainer scope before signing