Drupal on premises and in air-gapped networks

Running Drupal on premises and air-gapped: what changes

A regulated organization that must host Drupal without direct internet access changes one assumption most Drupal teams never question: that the code, the updates and the security notices arrive over the public internet. Drupal core and contributed projects come from Drupal.org, and a Composer-based build pulls packages from Packagist and other repositories by default. Each of those paths needs a controlled route into the network, whether that is a internal Composer package mirror, a vetted artifact repository or a transfer process run from a staging zone. Before the build starts, decide which systems will resolve dependencies, which will check for updates and who approves each package crossing the boundary.

Licensing is the easy part. Drupal and the contributed files on Drupal.org that derive from it are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself, so nothing in the license blocks a private deployment. The real cost sits in process and infrastructure: a mirror that stays current, a way to receive the Drupal security team's advisories and a patch cycle that fits a network where a release cannot be pulled on demand. Confirm with your security team how the Wednesday security release window will reach staging and production, since that window is set by Drupal.org and does not wait for your change board.

Plan the update checks as deliberately as the build. The Update Status module normally fetches release data from Drupal.org, which a closed network cannot reach, so confirm how your environment will supply that information and test it on a copy of the site before go-live. Record which Drupal core, PHP and database versions are in use, check them against the Drupal core release schedule, and document who acts when a security release is announced. Verify the PHP version against the Drupal.org PHP requirements, since Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later.

Which isolation model fits your network

Drupal on premises has three common network models: fully air-gapped, restricted egress through an allowlisted proxy, and on-premises with internet access limited to a mirror host. Each model decides who handles transfer media or mirror content, how long a patch takes to reach production, and what evidence you can show an assessor.

Fully air-gapped network

No route to the internet exists, so every Composer package, Drupal core release, contributed module and container image arrives on approved media or through a one-way transfer process. Your team owns the transfer step, including scanning, hashing and logging each import. Patch lead time includes the wait for the next security release window on the third Wednesday of the month, plus your import and review cycle. Ask who signs off each import and how the signed record is kept.

Restricted egress through an allowlisted proxy

Servers reach only named hosts through a controlled proxy, so Composer, Drush update status and module downloads can run on a schedule. The allowlist is the control you must justify, and it should list only the Drupal.org and package hosts your build actually uses. Patch lead time shrinks because updates can be pulled automatically, but each allowed host becomes a path that needs logging and review. Confirm the proxy records requests so you can show what was fetched and when.

On-premises with a mirror host

Production stays inside the network, while a single mirror host syncs packages from outside on a schedule and serves them internally. The mirror host is the trust boundary, so its sync account, storage and signature checks deserve the same hardening as production. Patch lead time depends on how quickly the mirror refreshes after each release, and you should test that the mirror serves the exact versions your lockfile pins. Ask your team who controls mirror content and who can add a package to it.

Who controls transfer media and mirrors

The model you choose determines whether your staff, a managed provider or the network operator handles package intake. Write down who downloads each release, who verifies its integrity against the published checksums, and who approves it for production. Regulated frameworks such as NERC CIP-013-2 expect procurement processes to address verification of software integrity and authenticity of vendor software and patches, so the answer must be documented. Confirm these roles in writing before the first import.

Effect on patch lead time

Patch lead time is the gap between a Drupal security advisory and a verified update running in production. Air-gapped sites add transfer, scanning and review steps before the Composer update, while proxy and mirror models mostly add approval and sync delays. Drupal publishes security releases on a fixed weekday, so plan a standing review slot each week. Ask for a timed rehearsal of one full patch cycle before you rely on the model for an assessor.

Evidence each model produces

Each model leaves different records: transfer logs and signed manifests for air-gapped sites, proxy access logs for restricted egress, and mirror sync logs for mirror hosts. Assessors usually ask for the version running, when it was approved, and proof that the artifact matched the source. Keep Composer lock files, release notes and import approvals together with each change. Confirm with your assessor which records they accept before you choose the model.

How a Composer package mirror carries Drupal across the boundary

A Drupal build inside an isolated network is a Composer build. Drupal core, every contributed module and theme, and their PHP dependencies are resolved from the outside world into a composer.lock file, and that file is the record of exactly what your organization approved. The inside network needs a private Composer repository or artifact mirror that can serve those same packages to composer install without reaching Packagist or Drupal.org. Choose the mirror product with your security team, and confirm that it can host Composer packages with the exact versions and checksums recorded in the lock file. This section does not assume any particular mirror product.

Staging happens on the outside. A connected build host resolves the approved composer.json into composer.lock, downloads the packages, and mirrors them into a transfer set. Before anything crosses the boundary, verify integrity: check that each archive matches the hash recorded in the lock file, confirm that the package sources are the ones your policy allows, and keep a manifest of files and hashes with the transfer. Your import process on the inside should repeat those hash checks instead of trusting the transfer media. Ask your security team how these checks map to the supply chain controls in your regulator's framework, such as the software integrity requirements in NERC CIP-013-2 if it applies to you.

Treat the lock file as the change record. Every security release that changes a core or contributed package produces a new lock file, which goes through the same staging, verification and import steps before deployment. Commit the lock file to your internal repository, tie each change to the Drupal security advisory it addresses, and keep the previous version so you can roll back. Confirm with your Drupal partner how dependency updates, Composer plugin behavior and any scripts that fetch remote assets will be handled, because a build that quietly reaches the internet will fail the isolation requirement even if it succeeds.

Running update status checks without reaching Drupal.org

The connected staging environment is the one place where Drupal's update status page can reach Drupal.org to fetch current release data for core and contributed projects. Treat it as the source of truth for what is available, not as a place where changes are made by hand. Run update checks on a schedule that matches the core release schedule, so the team sees new bugfix and security releases in the same week they are published. Update Status and Upgrade Status both need current metadata to be useful, so a stale staging copy produces misleading results.

Scheduled refresh: Run the update status refresh on a fixed schedule and keep the timestamp of each refresh in the team's runbook.
Exact code parity: Keep the staging codebase built from the same Composer lock file that production uses, so the report describes what production actually runs.
Upgrade Status runs: Run Upgrade Status against staging before any major version planning, since it needs the external data to evaluate contributed projects.
Output capture: Export the update report and Upgrade Status results into a ticket or document the security reviewers can read without staging access.
Network scope: Limit outbound access from staging to the Drupal.org endpoints required for update data, and confirm the exact hosts with your network team.

Before relying on staging, check that the refresh job actually completes and that the reports reflect the current lock file.

Build sequence for an offline Drupal platform

This sequence takes a Drupal site from an approval decision to a running platform inside a network with no internet access, with a verified release bundle and a repeatable way to take in updates. Each step closes with a check so the team knows the previous step held before moving on.

Confirm the network and approval model
Before any software moves, document which network zone will host Drupal, what crosses the boundary (code, packages, container images, updates, database dumps), who approves each transfer, and which controls apply to that transfer path. Your security and compliance leads own this decision, and DeployOpen can help draft it. It is done when the boundary, the transfer owners and the approval steps are written down and signed off, and every later step refers back to them.
Pick the database and web server
Choose the database (MariaDB, MySQL, PostgreSQL or SQLite) and the web server (Apache, Nginx or another supported server) against the Drupal version you plan to run, using the system requirements for that release. Confirm the PHP version too, since Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Ask your platform team to confirm that every chosen component can be installed from internal mirrors. It is done when the stack is fixed in writing and each component has an internal package source.
Stage the Composer mirror and registry
Build a private mirror for Composer packages, PHP extensions and OS packages, and an internal container or artifact registry if you use containers. Populate them from a staging environment that has controlled access to Drupal.org and its package sources, then record the list and versions of every artifact. Check the mirror by running a clean composer install on a machine that can reach only the mirror. It is done when that install succeeds with no outbound traffic.
Build and verify the release bundle
In the staging environment, build the Drupal codebase from a committed composer.lock file, generate a manifest with checksums, and scan the packages for known vulnerabilities. Have a second person review the contributed modules and their versions, and keep the signed or hashed bundle with the approval record. Verification is complete when the checksums match, the scan results are reviewed and accepted, and a test install from the bundle works in a lab that matches the target.
Install into the isolated network
Move the approved bundle across the boundary through the agreed transfer path. Deploy the code, the web server, the database and the configuration, then run the site install and configuration import with the environment-specific settings kept outside the repository. Confirm that the site starts with no outbound connections required for normal operation. It is done when the site serves pages in the isolated network and the administrators have signed in through the approved access path.
Test a restore before go-live
Take a database dump and a copy of the files directory, restore both into a separate isolated environment, and confirm that the site loads, content is intact and the configuration matches. Record the time the restore took and the steps needed, so the runbook reflects reality. Do this before the first production content goes in. It is done when a restore completes from backups alone and the team can repeat it from the runbook.
Set up update intake and rebuild cadence
Define how security and bugfix releases reach the isolated network: who watches the Drupal security advisories, how advisories are triaged, how the bundle is rebuilt in staging and how the new bundle moves through the transfer path. Align the cadence with Drupal's published release days, bugfix releases on the first Wednesday of the month and security releases on the third Wednesday. Also set up a status check that works without reaching Drupal.org, using a manually imported advisory feed or the update data you carry in. It is done when a dry run of one update cycle completes end to end and the owners have signed the procedure.

Patching discipline on a timetable you can keep

Drupal publishes on a predictable calendar, so an air-gapped team can plan intake, testing and transfer windows ahead of time. The cards below cover the routine cycle, the exception path for urgent advisories and the information a team needs to decide how fast to act.

Plan intake around the monthly rhythm

Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. Build a standing calendar that starts intake a few days before each date, so a package can be pulled from your upstream source, scanned and carried across the isolated boundary before the next change window. Confirm with your change board how many business days each step takes in your own environment, since those steps are yours to set and are not supplied by Drupal.

Separate security and bugfix tracks

Security releases and bugfix releases answer different questions, so treat them as separate queues. A security release addresses reported vulnerabilities and should be staged on the same week it arrives, while a bugfix release can wait for the next routine window. Record which queue each package belongs to in your patch log so auditors and approvers can see why a change was fast-tracked or deferred.

Handle out-of-cycle advisories

The Drupal Security Team can publish advisories outside the normal calendar when a risk is severe or actively exploited. Keep a named on-call contact and a pre-approved emergency change path that skips the routine window but still requires hash verification, a test deployment and a rollback plan. Ask your partner or internal team to confirm how quickly they can mobilize, because that response time is an operational commitment you must set yourself.

Read advisories for CVE and risk scores

Each Drupal Security Team advisory carries a CVE identifier and a risk score. Use the CVE to match the flaw against your inventory of core and contributed projects, and use the risk score together with your own exposure to decide urgency. A flaw in an anonymous-facing module on a public network warrants a different response from the same flaw in an internal administrative module, so record both factors when you decide.

Verify contributed projects, not just core

Advisories often concern contributed modules and themes rather than Drupal core. Maintain a bill of materials listing every project and version in the codebase, including Composer-resolved dependencies, so you can answer whether an advisory applies within minutes. Confirm that your mirror carries the exact versions you need, because a missing contributed package can block a security fix even when core is current.

Confirm supported PHP and core versions

Some patches are blocked by the platform beneath Drupal rather than by Drupal itself. Check each target release against the PHP version it requires, and confirm the PHP runtime and operating system packages are available in your mirror before you plan the core upgrade. A security fix that needs a newer PHP build can stall the whole window if the runtime was never mirrored, so verify that dependency at intake rather than at deployment.

Version and runtime constraints that set the upgrade path

The version you choose sets the runtime your air-gapped network must carry for years. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. A site built on Drupal 10 today therefore has a fixed window before it stops receiving core security releases, and that window has to fit inside your change calendar, not the other way round. The PHP minimums are the constraint most often missed: 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, per the Drupal.org PHP requirements page. Confirm that the PHP build you can install from your internal operating system repositories meets the minimum for the target release, because an OS image that ships an older PHP can block the upgrade regardless of Drupal's readiness.

Drupal 7 is a harder case. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, and Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They must be migrated into a new site, with themes rebuilt. For sites that cannot migrate yet, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors. Using an external provider is a contract and data-handling decision, and in an air-gapped network it also means confirming how their patches are delivered across the boundary and verified before they are installed. Ask each provider how patches are packaged, signed and reviewed, and whether they can supply them as offline bundles.

Before you set a target version, confirm that every runtime dependency is also available inside the network: PHP extensions, the web server, the database engine and its minimum version, and Composer itself. Each of these needs its own mirror or offline package set, and each new major Drupal release can change them. Record the target PHP version, the database version and the operating system release in one compatibility matrix, and treat a change to any of them as a planned upgrade rather than a routine patch.

Security and compliance considerations in isolated networks

An isolated Drupal site loses the convenience of online patch feeds, hosted secrets and cloud logging, so each control has to be designed for the network it runs on. The cards below cover the controls that carry most of the risk: what crosses the boundary, where credentials live, who can reach administration, what the team can still see, and what evidence proves it.

Package integrity and provenance

Every Composer package, Drupal module and theme that enters the isolated network crosses a boundary that nobody can check against Drupal.org in real time. Record the source, version and cryptographic checksum of each artifact at import, keep the lock file under version control, and reject any build whose lock file differs from the approved set. Ask your team how a tampered package would be detected if the mirror itself were compromised.

Secrets outside the repository

Database credentials, hash salts, API keys for identity providers and mail relays belong in the environment or a secrets store, never in settings.php committed to the codebase. In an isolated network, the secrets store is also inside the boundary, so plan its backup, unseal procedure and rotation before go-live. Confirm that the build pipeline cannot print secrets into logs.

Administrative access and MFA

Drupal administrators can change code paths, roles and content at scale, so administrative logins need stronger controls than editor logins. Decide where administration happens (an internal bastion, a hardened workstation segment or a dedicated VPN), require multi-factor authentication for every admin account, and confirm that the chosen factor works without a cloud service. Test account lockout and recovery from the isolated network itself.

Logging that works offline

Drupal's watchdog records and web server access logs are only useful if they reach a store the team can search without internet access. Forward logs to an internal collector, set retention that matches your records policy, and alert on failed logins, permission changes and cron failures. Confirm that time sources are internal so events from web, database and cache servers line up during an investigation.

Supply chain evidence

Auditors and regulators ask for proof of what was approved, who imported it and when it was deployed. Keep import tickets, checksum records, mirror change logs, test results for each security release and the deployment record linking each artifact to a change. DeployOpen prepares these systems, controls and evidence for your assessment, but independent auditors and certification bodies issue any audit report or certification.

Transfer controls for regulated operations

Where Drupal supports operational technology or a regulated utility, the transfer step is governed by requirements such as NERC CIP-013-2, which expects procurement processes to address verification of software integrity and authenticity of vendor software and patches. Separately, NERC CIP-005-7 governs interactive remote access to high and medium impact BES Cyber Systems through an intermediate system with encryption and multi-factor authentication. Confirm with your compliance team which of these apply before you design the access path.

Configuration options and when each fits

This table compares the main stack and packaging choices for Drupal inside a private data center or an isolated network, with the trade-off and the question to confirm with your platform team for each. Read each row against your own patching cadence, staffing and how often you can move packages across the boundary. The main takeaway is that the fewer moving parts you carry across the isolated boundary, the less you have to verify on every release.

Option	Fit	Trade-off	Confirm with the platform team
Apache or Nginx	Apache fits teams already running .htaccess-based sites. Nginx fits teams standardizing on PHP-FPM behind a single internal ingress.	Apache keeps .htaccess protections in place. Nginx needs those protections recreated in server configuration, which must be tested after every core update.	Which web server your security baseline and hardening guides already cover, and who owns its configuration files.
MariaDB or MySQL	Fits sites where the platform team already runs a supported MySQL-family service with tested backups.	Some contributed modules include MySQL-specific code, so database choice narrows module options.	Minimum version for your target Drupal release and whether your offline package mirror carries that database's server packages.
PostgreSQL	Fits organizations standardizing on PostgreSQL for high availability and tested point-in-time recovery.	Requires the pg_trgm extension for some search features, and extension packages must also be carried across the boundary.	Whether the extension is available in your offline repository and who approves its installation on the database host.
SQLite	Limited to small, single-server test or demonstration sites.	Not a fit for production sites with multiple web nodes or high write volume.	Whether any production use is planned at all. Treat it as a development option unless the platform team has a documented reason.
Container images built offline	Fits teams that already run a container platform in the isolated network and want each release as one signed, reviewable artifact.	The image build needs base images, PHP packages and Composer dependencies available offline. Every rebuild for a security release repeats the verification.	Where base images come from, how they are scanned, and whether your registry is reachable from the build environment only.
VM-based installs	Fits teams with mature configuration management and existing VM patching processes.	Patching the operating system, PHP and Drupal can drift between servers unless configuration management enforces one state.	Which configuration management tool manages the hosts, and how it receives offline packages.
Internal Composer mirror	Fits sites that must receive regular contributed module and core updates with a repeatable build.	A mirror must be synchronized from outside the network, so each sync is a transfer event that needs review and records.	Who runs the sync, how often the mirror is refreshed, and how the mirror verifies package integrity before use.
One-way transfer of vendored code	Fits small estates or sites that change rarely and want the exact code tree reviewed before it enters the network.	Each security release requires a new full transfer and review. Manual steps are easier to skip under time pressure.	The transfer procedure, the reviewers, and how the team proves the transferred tree matches the approved release.

Questions buyers ask before running Drupal offline

How long does an offline Drupal setup take?

No fixed duration can be given for every environment, because the time depends on what the network already provides. The main drivers are how many Drupal and contributed projects the site uses, whether a Composer mirror or artifact repository already exists inside the network, how many web, database and cache hosts must be built, and how many approval steps apply to each package that crosses the boundary. Teams with existing internal repositories and mature change control usually move faster. Ask any partner to show the written work breakdown and the list of assumptions behind its timeline before you commit.

What does it cost to run an offline package mirror?

Costs fall into four parts: the hardware or virtual machines that host the mirror and its storage, the staff time to build and maintain the transfer process, the security review of every package batch, and the internal licensing for any repository software you choose. Drupal core and most contributed modules are open source, so the software itself has no license fee. Recurring costs come from keeping the mirror current with each bugfix and security release, which follow the core release schedule. Ask for a quote that separates one-time build work from ongoing update work and states who pays for each item.

Is Drupal or a paid edition required for an air-gapped site?

No paid edition of Drupal exists. Drupal and the contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, so you can run them offline without a license purchase. Some other open-source platforms bundle air-gapped deployment into commercial tiers, but that is a product decision for those platforms and does not apply to Drupal. Check the license of each contributed module and any custom or third-party library you add, because those can carry their own terms that your legal team should review.

Can an internal team run an offline Drupal site without a partner?

Yes, if the team has Drupal and PHP operations skills, a working Composer workflow, and a defined way to move verified packages across the boundary. The harder parts are usually the transfer process, the update cadence, and keeping the build reproducible from the mirror alone. Drupal core releases bugfix updates on the first Wednesday of each month and security updates on the third Wednesday, so the team needs a standing process for those dates. Assess honestly whether that capacity exists before deciding, and consider a retainer if it does not.

What does the organization need to provide for this work?

You need a named owner for the platform, access to the target network and its change process, the hosts or cloud accounts inside the boundary, and a security approval path for packages imported from outside. You also need the list of required contributed modules, decisions on the database and web server, and the people who will test updates. Engineers from the security team should agree early on how software integrity and authenticity will be checked for each batch. Gather these inputs before requesting a quote, since missing ownership is one of the most common causes of delay.

How do we keep an offline Drupal site patched?

Patching depends on a repeatable cycle: check the core release schedule, pull the new release into the mirror, verify its contents, test it in a staging environment inside the boundary, then promote it to production. Security releases follow the Drupal Security Team's advisories, and the Security Team publishes advisories with CVE identifiers and risk scores that help prioritize work. Because security releases arrive on a fixed Wednesday window, schedule the transfer and test steps ahead of time. Also confirm the supported PHP version for each Drupal release, since Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later.

What compliance controls apply to offline Drupal in regulated sectors?

Requirements depend on your sector and your assessor, so confirm them with your compliance lead before design starts. Many frameworks expect documented supply chain controls, change records and verified software sources, which map to the package verification and patch evidence described above. Energy-sector rules such as NERC CIP-013-2 explicitly address verification of vendor software and patches, which is the control behind checking every package carried across an isolated boundary. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue the audit reports and certifications.

Limits to confirm in your own environment

An air-gapped Drupal build fails quietly when a dependency assumes internet access. The cards below list the items to test on your network, in the order they usually surface, so the gaps appear during planning rather than after cutover.

Runtime calls from contributed modules

Many contributed modules call external services during normal requests, cron runs or configuration saves, such as map tiles, font CDNs, translation APIs, AI providers or update feeds. Review each module in the approved list and trace its outbound calls with a test host that has no route to the internet. Confirm which features degrade and which block a page load, and decide whether each feature is removed, pointed at an internal service or disabled in configuration.

Reachability of mail, SSO and search

Drupal depends on internal endpoints for outbound mail, identity and search. Confirm that the SMTP relay accepts connections from the web tier, that the identity provider metadata and token endpoints resolve inside the network, and that the search server answers on the port the Search API configuration expects. Test each path with a real login and a test message, since a green health check on a server does not prove the application can use it.

PHP extensions and system packages in the mirror

Composer resolves PHP extensions and system libraries that the mirror may not carry, including image libraries, database drivers and the PHP version required by your target Drupal release. Build the site from a clean machine that only uses the mirror, and list every extension the build and runtime load. Confirm the PHP version against the requirement for your Drupal line before you request packages.

Approval path for each transfer

Every package, container image and security release that crosses the isolation boundary needs a documented approval step. Ask who signs off on Drupal core and contributed module updates, how checksums or signatures are verified, and how long a security release can wait in the approval queue. Agree the path with the security and change teams before work starts, because it sets the real patching cadence more than the Drupal release schedule does.

Update status checks without Drupal.org

The Update Manager module normally fetches release data from Drupal.org. In a closed network, confirm how release metadata reaches the site, whether through a locally hosted copy or a scheduled import, and who reviews it. Without this feed, the site cannot report pending security releases, so the patch schedule must be driven by your own monitoring of published advisories.

Release timing and Drupal line support

Plan upgrades against the public calendar rather than ad hoc needs. Bugfix releases land on a fixed Wednesday pattern and security releases follow a separate Wednesday window, so your approval process must accept a release within days of publication. Confirm which Drupal line you run and its end-of-life date, because a mirror refresh that lags behind a security release leaves the site exposed.

Where to read the official guidance

Start with the Drupal.org licensing page before you plan any air-gapped build, because the license determines what you may copy, mirror and redistribute inside your network. Drupal core and all contributed files hosted on Drupal.org that are derivative works of Drupal are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Your legal and procurement team should confirm how that applies to any private packages, custom modules and vendor-supplied code you intend to carry across an isolated boundary, since the licensing page addresses the Drupal.org projects rather than your own code.

Next, read the Drupal core release schedule and map it to your patching calendar. The schedule states that bugfix releases ship on the first Wednesday of each month, security releases on the third Wednesday, and new major versions typically every three years. It also gives the dates Drupal 10 reaches end of life and when Drupal 12 is scheduled. Use those dates to decide how many days your mirror and transfer process must absorb, and confirm the current dates on the schedule itself before you commit to a change window. Then check the system requirements page, which lists the supported web servers and database engines, and the PHP requirements page, which sets the PHP minimum for each major version. Confirm both against the exact versions in your offline image set before you build it.

How DeployOpen scopes and delivers offline Drupal hosting

DeployOpen plans, builds, hardens, documents and supports self-hosted Drupal inside your own data center or isolated network. We treat the offline boundary as a design constraint from the first scoping call, so package mirrors, update checks and patch intake are agreed in writing before any code or infrastructure is built.

How we scope

Engagements are fixed-scope, with the offline boundary, supported Drupal version and PHP target agreed in writing before work starts.
We map which Composer packages, contributed modules and themes your site needs, and which must be vetted and carried across the boundary.
We confirm with your team which update checks, security advisory feeds and mirror sources are reachable, and which must be supplied manually.

How we build

We build a internal Composer package mirror and artifact store, and configure the Drupal codebase to resolve every dependency from it.
We set up a patch intake path that runs the Drupal core and contributed module update routines on a tested staging copy before production.
We test the offline build from a clean environment with no outbound internet access to prove the site installs, updates and runs as documented.

How we hand over

You receive the written runbook covering mirror refresh, package verification, release steps and rollback for your environment.
Documentation records the offline architecture, network boundary, credentials ownership and the evidence trail for each transferred package.
Your operators are trained on the monthly bugfix and third-Wednesday security release cadence and how to act on each one.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped to your offline environment and release calendar.
Each security release is reviewed against your installed modules, then carried across the boundary through the same verified process.
We help prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any formal opinion.