Docs / GitHub & fix PRs
Connect a site's GitHub repository and Drubix reads its exact module versions. For each security finding, it can open a ready-to-review pull request that updates to the fixed version.
composer.json and composer.lock committed.We recommend a fine-grained token, which only reaches the repositories you choose.
Adding a repository later? A token only sees the repositories on its list. To use it for a new site, edit the token on GitHub, add the repository and click Update. The token itself stays the same.
For a repository owned by an organisation, the organisation may need to approve fine-grained tokens first. A classic token with the repo scope also works.
| Field | What to enter | Example |
|---|---|---|
| Owner | The user or organisation in the repository URL | my-agency |
| Repo | The repository name, without the owner | client-site |
| Token | The token from step 1 | github_pat_… |
| Branch | The branch fix PRs should target. Leave it empty for main. | develop |
| composer.lock path | Only if the lock file isn't at the root of the repo | web/composer.lock |
composer.lock straight away and confirms how many packages it found. From then on it re-reads the file on every check, so findings always use the versions in your code.Drubix encrypts the token before storing it, and uses it only to read the Composer files and open fix PRs.
Open a site's findings and click Create fix PR on a security finding. Within a few seconds, a pull request appears in the repository with:
composer.json: the affected package's version is raised to the release named in the security advisory. Nothing else in the file changes, so the diff is easy to review.drupal/core-recommended, drupal/core-composer-scaffold, drupal/core-project-message and so on). Updating only one would leave Composer unable to install.composer.lock: a minute or two after the PR opens, Drubix runs composer update for just that package (lock file only, no scripts or plugins) and adds the new lock file to the PR. Your CI then tests exactly what will be installed.The version to move to comes directly from the Drupal.org advisory, never from AI. AI writes only the description, and a standard description is used if AI is unavailable.
When one advisory affects several of your sites, the finding shows Fix on all N sites. It lists every affected site with its status:
Select the sites you want and click Open PRs. Each site gets its own pull request.
Autopilot is opt-in, per site. Click the Autopilot chip on a site that has GitHub connected, tick Turn on Autopilot and save. From then on, every 10 minutes it:
Whenever something doesn't look right (CI failed, composer couldn't resolve, the client declined, GitHub refused the merge), Autopilot stops, leaves a comment on the PR, and alerts you through your notification channels. It never retries a merge it isn't sure about. Fix the problem, then click Let Autopilot try again, or merge the PR yourself.
If your hosting builds a preview site for each PR (Pantheon multidevs, Platform.sh environments, Netlify-style previews) or you have a staging site that deploys PR branches, add its address in the Autopilot settings:
| Preview URL | Use it when |
|---|---|
https://pr-{pr}-client.pantheonsite.io | Each PR gets its own preview. {pr} becomes the PR number. |
https://{branch}-client.example.dev | Previews are named after the branch. {branch} becomes the branch name, lowercased, with other characters turned into dashes. |
https://staging.client.com | One staging site that deploys the PR branch. |
Once CI passes, Drubix screenshots the homepage and up to 3 key pages (login, checkout, contact and similar) on the live site and on the preview. Autopilot holds the merge when a preview page shows an error (a 5xx response, a 404, or Drupal's "unexpected error" page), or when a page looks very different from the live one. You can open the screenshots from the Autopilot panel, click Screenshots look fine to carry on, or run the check again. If the preview isn't up yet, it tries again for about an hour.
Tick Ask the client to approve each update and add their email address. When CI (and the visual check) pass, the client gets an email sent in your agency's name. The link opens a page with what's changing and the screenshots, and two buttons: approve or decline. Opening the link does nothing on its own, and it expires after 14 days. The client doesn't need a Drubix account.
The PR already includes the updated composer.lock, so deploy it the way you always do. On the server, that usually means:
composer install --no-dev drush updatedb -y drush cr
If the PR says composer.lock couldn't be updated, run composer update drupal/webform --with-all-dependencies (with the package names from the PR) yourself and commit the lock file before merging.
When does the finding disappear? When the fix is live on the site. Merging the PR doesn't close it on its own, because the site is still exposed until the new version is deployed. After you deploy, the next check closes the finding. To skip the wait, click Scan now, or run drush drubix:report if the connector is installed.
| Message | What it means and what to do |
|---|---|
| GitHub API … failed: 404 Not Found | GitHub hides private repositories the token can't see, so it reports "not found". Check the owner and repo spelling, and make sure this repository is on the token's Repository access list. |
| composer.lock not found in the repo | Either the token can't see the repo (see above), or the lock file is in a subfolder. Set the composer.lock path field. |
| GitHub rejected the token | The token has expired or was revoked. Create a new one and reconnect. |
| Could not find module in this repo's composer.json | Fix PRs edit the composer.json at the root of the repo. The package may be missing there because it's pulled in by another package, kept in a different file, or already updated. |
| A fix PR is already open for this finding | Drubix opens one PR per finding. Merge or close the existing PR first. |
| This advisory has no confirmed fixed version | The Security Team hasn't named a fixed release yet. Try again once one is published. |
| composer.lock couldn't be updated | Composer couldn't resolve the new version, usually because another package pins the old one. The Autopilot panel shows Composer's output. Update the lock file yourself, or adjust the constraint that blocks it. |
| No CI results showed up on the PR | Autopilot only merges tested changes. Set up CI for pull requests, and make sure the token has Commit statuses and Checks read access. |
| GitHub didn't accept the merge | Branch protection needs more reviews, the PR has conflicts, or someone pushed to the branch after CI ran. Review and merge it yourself. |
| The installed version isn't known | Autopilot needs the exact version to know if a fix is patch-level. Connect the repo's composer.lock or install the connector. |
| This feature requires the "monitored_connector" plan | Fix PRs and GitHub connections need the trial or the paid plan. Start the trial from the dashboard. |
Not unless you turn on Autopilot for that site. Without it, Drubix only opens pull requests: it never pushes to your branches or merges anything. With Autopilot on, it merges patch-level security PRs after your CI passes (and after the client approves, if you ask for that). It never deploys and never touches the live site: your deployment process stays in charge.
Not for exact versions or fix PRs: GitHub covers both. The connector adds things only visible from inside the site: PHP version, config drift, and the permissions and security-settings audit.
Yes. Add every site repository to the token's repository list, then paste the same token when connecting each site.
Revoke the token on GitHub or remove the repository from its list, and Drubix can no longer reach it. To switch to a different repository, click the GitHub chip on the site and connect again with the new details.