Every Night, Argo Watches

While your site is running, things change. A content editor tweaks a configuration setting. A security vulnerability surfaces in a dependency. A production fix gets applied directly instead of going through the normal release process. Any one of these left undetected can cause a failed deploy, a security exposure, or a lost change.

We manage dozens of Drupal and WordPress sites. Every night, an automated job checks all of them -- git status, deployment state, configuration sync -- and tells us if anything has drifted. That system is called Argo, and this month we made it significantly more capable.

Security Advisories in Every Nightly Check

It started with an offhand comment. Pierre Rudloff, a member of the Drupal Security team, mentioned in Slack: "You should have a process to run composer audit on your websites at regular intervals."

We already had the nightly job. Adding composer audit seemed straightforward — but threading it correctly through several repositories turned out to be the interesting problem. Security advisories are informational. They should never block the very deploys you need to fix them. So we carved out a clear distinction in Argo's result schema: dirty (config or git state, blocks deploys) vs. advisory (security notices, reported but non-blocking).

Now every morning our bot reports new vulnerability disclosures per-project, with severity-colored icons in the nightly summary. Coverage extends to any package Composer knows about — not just Drupal core and contrib.

Cleaning Dirty Production sites

Drupal's configuration management is one of the platform's great strengths. All config lives in code, and if someone changes something directly on production, that change needs to get committed before the next deploy — or it gets clobbered. Our nightly job detects those changes and marks the site "dirty," blocking deploys until the drift is resolved.

The old workflow was: detect, export, commit, coordinate across environments. Tedious, and easy to get wrong.

A while back, our developer Andrew suggested: why not automatically merge those production changes into a special release branch and push it out to clean the site? That idea sat for a while. This month we took it further. We built a clean-prod job that copies production config changes into a pull request for a developer to review. Once approved, it merges into our main branch — the branch that always reflects production — and the site is clean again. Future nightly checks compare against main, so already-committed changes don't keep triggering alerts.

With tools like Drupal Canvas generating more configuration changes than ever, this closes a gap that was quietly creating real risk.

Bosun: Run Commands Across the Entire Fleet

When a security bulletin drops, we used to search for specific files across our dev servers, assemble a list of affected sites by hand, and check them one by one. It worked, but it didn't scale.

Image

A bigger problem was that site data lived in half a dozen places: subscription status in one app, server paths in a drush alias repo, contacts in a CSV, release state in Matrix room state. Adding a new site meant touching all of them.

We'd already built a remote-ops shell script to replace SaltStack for server management — Salt's Docker orchestration support was fragmenting, and getting compatible versions across our mixed fleet of NixOS and older Ubuntu servers was becoming untenable. That script worked so well it quickly became our standard tool. So we applied the same thinking to sites: Bosun, a new internal tool that can run arbitrary commands — drush, WP-CLI, composer, ripgrep, fd — against any managed site, on any host (Pantheon, Acquia, or our own servers), targeting any environment.

The longer goal is consolidation. Carina, our internal management app, becomes the single source of truth. Add a site once, and aliases, contacts, and CI/CD config are generated from there.

What's Coming Next

• WordPress parity - WP-CLI plugin update detection and optional Composer management, bringing the same vulnerability reporting to WordPress that Drupal sites now have
• Pre-deploy safety checks - divergence detection between main and develop, plus a pre-release check-clean run to shrink the window where production changes can get clobbered
• Auto-deploy after config-pull PR merge - eliminating the manual hotfix trigger once a clean-prod PR lands

One thread running through all of this: we're using AI heavily to build and improve these tools. We're deliberately keeping AI out of operations. Supply chain attacks are the dominant threat now. Prompt injection attacks on AI-assisted ops pipelines are what we're watching for next.

Freelock maintains websites for organizations that can't afford downtime or security surprises. If you'd like to talk about what managed maintenance looks like for your site, get in touch.