Drupal Project Browser: module discovery and governance

What Drupal Project Browser lets site builders install, and when to restrict it

On a governed Drupal site, a site builder wants a module today and a governance lead wants every module reviewed before it touches production. Project Browser is the feature where those two needs collide, because it lets site builders find and install modules from inside the Drupal site itself rather than only through a developer's codebase. That makes it a decision to settle before launch, not after the first unreviewed module appears in the admin interface. The Project Browser project page on Drupal.org is the starting point for confirming what the current release does in your environment.

The 2.1.5 release of Project Browser supports Drupal ^11.2 or ^12, so a site on an older Drupal 11 minor version or on Drupal 10 needs a version check before anything else is planned. Confirm the installed Drupal core version against the constraint in the release's composer metadata, and confirm the same for any Drupal 12 target date your upgrade plan depends on. Also confirm whether your installation has the module enabled, which roles can reach its pages, and whether installs run through Composer in your build pipeline or directly on the server. Those answers determine whether restricting the feature is a permissions change or a deployment change.

Restricting Project Browser on a governed site is a matter of deciding who may trigger installs and where new code is allowed to enter. The simplest policy is to remove install rights from site builder roles, keep the module reviewed and managed through version-controlled Composer files, and route every addition through the same code review as custom code. Write that policy down with named owners, including who approves a new contributed module and how security advisories for installed projects are tracked. Ask your implementation partner to show how the chosen configuration is tested in staging, so the restriction is verified rather than assumed.

Project Browser configuration options and when each fits

This table compares four ways to govern Project Browser, from open access for all site builders to removing it in favor of a Composer-only workflow. Read each row for the situation it fits, who should approve changes, and the ongoing cost of keeping that control in place. The main takeaway is that discovery and installation can be separated by environment, but the exact controls must be confirmed in the module documentation before you rely on them.

Option	When it fits	Who approves changes	Operational cost
Available to all site builders	Low-risk internal sites with few regulated data flows and a small, trusted build team that accepts modules from Drupal.org without a separate review step.	Site builders decide which modules to install, with the site owner informed after the fact.	Lowest day-to-day effort, but every install becomes a code change that must still be tested, tracked in version control and covered by security advisory monitoring.
Limited to a vetted allow list	Governed sites where only reviewed projects may be added, and where the team can name each approved module and its maintainer.	Security or platform lead approves each addition to the list, after code review of the project and its dependencies.	Ongoing effort to review new requests, retire unused modules and confirm the list still matches the installed Drupal version. Confirm how the allow list is configured in the module documentation.
Installs disabled on production, discovery kept on staging	Sites where production must not change at runtime, but teams still want to explore modules and test them before they are promoted.	Modules found on staging are proposed through the normal change process and installed by the release team through the deployment pipeline.	Requires a repeatable promotion path so that staging and production match. Teams must confirm which environments the installation controls apply to and how they are enforced.
Removed in favor of a Composer-only workflow	Regulated or high-assurance sites where every module must pass code review and enter the codebase through a locked, reviewed dependency change.	Developers propose a Composer change, and reviewers approve it in the same way as other code changes.	Highest discipline cost: developers must know the module names and versions, and discovery happens outside the site. This option gives the clearest audit trail for each dependency.

How to set up Project Browser on a governed site

This sequence takes Project Browser from a version check to a tested upgrade path on a governed Drupal site. The result is a documented approved module list, restricted install rights, and install changes that show up in version control.

Confirm the Drupal core version and release match
The site lead or platform engineer checks the running Drupal core version and compares it with the Project Browser release. Project Browser 2.1.5 supports Drupal ^11.2 or ^12, so a site on an older Drupal 11 minor release or on Drupal 10 needs a core upgrade or a different Project Browser release before continuing. Run composer show drupal/core-recommended and composer show drupal/project_browser and record both versions in the change ticket. The step is done when the two versions fall inside the supported range shown on the Drupal.org project page, and the record is saved with the project documentation.
Install and enable the module in a non-production environment
A developer installs the module with Composer in a development or staging environment that mirrors production, then enables it with Drush. Commands such as composer require drupal/project_browser and drush en project_browser are typical, but confirm the exact package name and any required dependencies on the Drupal.org project page first. Check that the module's dependencies resolve and that the Project Browser pages load for an administrator account. The step is done when the module is enabled in staging, the configuration export is clean, and the build passes review.
Define the approved module list and owners
The governance owner, security lead and product owner agree which contributed projects may be installed, and name an owner for each approved project. The list should state the reason for approval, the Drupal version it targets and the review date. Ask who is accountable for accepting security advisories for each project, since the Drupal Security Team publishes advisories for contributed projects as well as core. The step is done when the approved list is stored in version control or the governance register, and each entry has a named owner.
Restrict permissions for who can install
The site builder sets Drupal role permissions so that only designated administrators can reach Project Browser and start installs. Editors, content roles and most site builders should not hold the permission that allows module installation. Test the permissions by signing in as each role in staging and attempting to open Project Browser and install a module. The step is done when every role outside the designated group is denied, and the test results are recorded with the role names and dates.
Verify installs appear in version control
The developer confirms that any module installed through the interface is reflected in composer.json, composer.lock and the exported configuration before the change reaches production. Set a rule that installs made in the browser are not accepted until a code review adds them to the repository. Run a test install in staging, export the configuration, and check the diff in the pull request. The step is done when a test install produces a reviewable commit, and a deployment that contains an unreviewed module can be detected by the pipeline or by a comparison of the lock file.
Test the upgrade path for installed modules
Before any core or module upgrade, the team runs the update in staging against the approved list and checks each installed project against its supported Drupal range. The test should include a dry run of the Composer update, a database update, and a check of the module's release notes for breaking changes. Ask the module owner to confirm that the release will still be maintained when the next Drupal core major version arrives. The step is done when the upgrade completes in staging, the approved list is rechecked, and the result is recorded in the change log for the next scheduled release window.

Security risks of in-site module installs and how to control them

Project Browser makes installing contributed code a few clicks away, which is convenient and also moves a supply-chain decision into the admin interface. The cards below cover the risks that follow from that, and the controls that keep each module tied to a review, an advisory feed and a release schedule.

Unreviewed code reaching production

A module installed from the admin interface can reach production in minutes unless your pipeline blocks it. Treat Project Browser as a discovery tool and require every new project to enter through a version-controlled composer.json change, a code review and a staging deploy. Check whether your production environment allows writes to the codebase at all, because a site that accepts installs from the browser needs a different control set from one that does not.

Dependency sprawl

Each contributed module brings its own Composer dependencies and sometimes JavaScript libraries, so one install can add more code than the name suggests. Review the full dependency tree before approval, not only the module page. Ask who will own each addition after the project ends, and set a ceiling on how many contributed projects a site may carry.

Abandoned modules and gaps in security coverage

A contributed project may stop receiving releases while its code remains installed. Before approving a module, check its maintenance status, release history and whether it targets your Drupal version. Check whether the project is covered by the Drupal Security Team's advisory process, since security coverage for contributed projects depends on the maintainers and the team's reports. Plan a replacement or removal path for any module that lacks an active maintainer.

Drift between environments

When an editor installs a module on production, development and staging no longer match, and the next deploy can overwrite or break it. Keep one source of truth for the module list, and block browser installs on production so every environment is built from the same lock file. Confirm how your team will detect drift, for example by comparing deployed composer.lock hashes against the repository.

Advisory response on a fixed calendar

The Drupal Security Team publishes advisories with CVE identifiers and risk scores, and security releases ship on the third Wednesday of the month. Bugfix releases come out on the first Wednesday. Build a patch routine that reads advisories against your installed module list, not only core, and assign an owner who can apply and test a contributed-module update within the window. Ask your partner or internal team how quickly they can deploy an out-of-cycle fix.

Access control for the installer

Project Browser is only a risk if the people who can use it are not the people accountable for the code. Restrict the Drupal permission that allows module installs to a named group, and log who installs what. Confirm that this permission, and any related administrative route, is disabled on production. Review the list of users with that access during each quarterly access review your organization already runs.

Governance models for teams with different review rules

In a regulated organization, every module that can run code on the site usually needs a formal review record before it is installed in any environment that handles regulated data. The approval path normally sits with the security or architecture function, with the application owner recommending a module and a reviewer signing off on its code, maintainer history and dependencies. Project Browser is most useful here as a discovery tool, while the install capability is typically restricted so that only the platform team can add modules through the normal code pipeline.

Approvers: Name a review board or security reviewer in writing, and record who may approve, who may deploy and who may grant exceptions.
Refresh cadence: Review the approved catalog on a fixed schedule and also whenever a security advisory affects a listed module, since the Drupal Security Team publishes advisories for contributed projects as well as core.
Evidence to keep: Store the review ticket, the exact version reviewed, the diff against the previous release, the license check and the deployment record linking that version to each environment.
Restriction method: Disable in-site installation for administrators and route all changes through version-controlled Composer updates that the review process gates.
Exceptions: Log every emergency install with a justification and a deadline for formal review.

Ask your assessor which artifacts they expect for change management and whether they accept a tracked allowlist in place of per-module sign-off.

Limits to confirm before you rely on Project Browser

Project Browser only helps governance if the modules it offers fit your core, PHP version and review policy. Work through these checks against the project page and your own staging site before you open it to site builders.

Core and PHP compatibility

Check the release notes for the Project Browser version you intend to install, because its supported Drupal core range is set by the project, not by the module you are discovering. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so a site on an older PHP runtime cannot run the current core line regardless of what Project Browser shows. Confirm both values on your own servers before enabling the module.

Drupal 10 sites on supported releases

Project Browser's 2.1.5 release supports Drupal ^11.2 or ^12, so a Drupal 10 site cannot use it on that release. Drupal 10 reaches end of life on December 9, 2026, which means a governance model built around Project Browser assumes an upgrade to Drupal 11 first. Ask whether your team plans to move off Drupal 10 before that date, and whether the module list you approve today still applies after the upgrade.

Dependency review coverage

A module you approve through Project Browser may pull in several other contributed projects or libraries. Your code review process may cover only the project you looked at, which leaves the dependency chain unreviewed. Before you approve a module, list its required projects from its composer metadata and confirm each one passes the same review, or add a rule that blocks installs with unreviewed dependencies.

Maintenance status against your policy

Project Browser shows what is available, not whether a project is still maintained to your standard. Check each candidate project's maintenance status, last release date, open security coverage and issue activity on its project page. Write the thresholds into your policy, such as the minimum recency of a release or whether a project with no recent release may be installed, so that approvers apply the same test each time.

Who can install and where

Restricting Project Browser is a permissions and environment question as much as a module question. Confirm which roles can open the browser and run installs, whether production sites have it enabled at all, and whether installs happen through Composer in version control rather than from the admin interface. Test these settings in staging, because the install path determines whether your code review actually sees the change.

Questions teams ask about Project Browser and module governance

What does it cost to set up Project Browser with module governance?

Project Browser itself is free to use, because Drupal and the contributed projects on Drupal.org are licensed under GPL-2.0-or-later and there is no paid edition of Drupal. The cost is the work around it: configuring which modules appear, setting up a staging environment, reviewing each candidate module's code, documenting the decisions and training the people who approve installs. Your own staff are paid for their time on that work, and any external partner is paid under a written scope. The main cost drivers are how many modules you intend to allow, how deeply each one must be reviewed, how many environments must be tested, and how often your approval process runs. Ask any quote to split one-time setup (catalog design, policy, first review cycle) from recurring work (reviewing new releases, security updates and dependency changes), and to state what is excluded.

How long does governance setup take for Project Browser?

The duration depends on two things: the size of the catalog you intend to allow and the review process you already have. A short allow list with an established code review process is far quicker to configure than a broad catalog that must pass a new security and legal review for every module. No reliable figure applies across organizations, so ask for a timeline in the written scope that lists the modules in scope, the review steps, the environments involved and the approvals each step requires. If your organization has no review process for contributed code yet, that work will usually dominate the schedule, not the Drupal configuration itself.

Can our team set up Project Browser governance without a partner?

Yes, if you have Drupal engineers who understand module installation, Composer-managed builds and code review, and if someone in the business can own the approved module list. Many teams handle the configuration in-house and bring in outside help only for specific gaps, such as a security review of a module with unusual permissions or a one-time audit of an inherited site. The questions to answer honestly first are whether you have the review capacity for each candidate module, who will respond when a contributed module publishes a security advisory, and whether your staging process can catch a broken update before production. If those answers are unclear, a partner can help define them, but the decisions remain yours.

What does Project Browser governance need from our team?

Governance needs three things from your organization. First, named approvers who can accept or reject a module and who have authority over security, legal and architecture questions. Second, a catalog owner who maintains the list of allowed modules, records why each one was approved, and removes modules that are abandoned or no longer meet policy. Third, a staging environment that mirrors production closely enough to test installs, updates and configuration changes before they reach users. Your team should also decide who can install from Project Browser at all, since most governed sites restrict that permission to a small administrator group. Without these roles, the catalog quickly becomes a list nobody trusts.

Does Project Browser replace code review for contributed modules?

No. Project Browser makes modules easier to find and install from inside the site, but it does not review their code, test them against your configuration or decide whether they meet your security policy. Contributed modules are maintained by different people, with different levels of activity, and each release can change behavior. Your review process still needs to check the module's maintenance status, its open security advisories through the Drupal Security Team, its dependencies, its permissions and whether it fits your data handling rules. Restricting Project Browser is a way to make sure installs go through that process, not a substitute for the process itself.

Which Drupal versions and PHP versions should we check before enabling Project Browser?

Check the version compatibility before you plan the rollout. The Project Browser 2.1.5 release supports Drupal ^11.2 or ^12, so a site on an older core line will need a core upgrade first. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, and Drupal 11 requires PHP 8.3 or later. Confirm your PHP runtime and your planned Drupal target in the scope before you choose a governance design, because the approved catalog must be tested against the version you will run after the upgrade. Confirm the current compatibility notes on the Project Browser project page, since releases change.

How do we restrict Project Browser so only approved modules can be installed?

Start by limiting who holds the permission to install modules, then decide how the approved list is enforced. Typically the permission to use Project Browser is granted only to a small administrator role, while editors and content teams never see it. Engineers then manage the codebase with Composer, so modules that pass review are added to the repository and deployed through the normal release pipeline rather than installed directly on production. Confirm with your engineers which controls your configuration can enforce in your Drupal version and which must be handled through deployment process, and test that a non-approved module cannot be installed by an unauthorized user in staging before you rely on the restriction.

How DeployOpen works on this

DeployOpen plans and implements Project Browser for module discovery and governance inside your own infrastructure, with the allowed module list, roles and review steps agreed in writing before any build starts. Engagements are fixed-scope, and the handover includes the governance record your reviewers need.

How we scope

Inventory the contributed modules your team expects site builders to install from Project Browser today.
Agree in writing which Drupal versions, module categories and install roles are permitted on each environment.
Confirm the review path for modules outside the allowed list, including who approves and where requests are logged.
Define the written scope, deliverables and timeline before work starts; engagements are fixed-scope, and ongoing support is available as a retainer.

How we build

Install and configure Project Browser on a non-production site, checking it against the Drupal version your project targets.
Restrict module installation to the agreed permissions and disable discovery paths your governance model does not allow.
Test install, update and removal of approved modules on a staging copy before anything reaches production.
Verify that blocked or unreviewed modules cannot be installed by administrators through other routes, and record the results.

How we hand over

Provide a written module governance procedure covering request, review, approval, installation and retirement steps.
Document the configuration, role assignments and the version checks your team must repeat during each Drupal upgrade.
Walk your administrators and reviewers through the workflow and the evidence each review should produce.
Deliver the approved module register in a format your code review and change records can reference.

How we support

Review the approved module list when Drupal core or Project Browser releases change compatibility or security status.
Re-test permission settings after upgrades so restricted discovery does not reopen silently.
Provide ongoing support, upgrades and continuous testing as a retainer, sized to the written scope.
Confirm with your security team how advisories from the Drupal Security Team will reach module owners and reviewers.

Drupal Project Browser for module discovery and governance