Drupal support: performance, security, major upgrades and deploys for complex sites

Drupal powers institutional portals, intranets and editorial sites with heavy content, roles and editorial workflows. It’s powerful but demanding: caching to configure well, a major to face every couple of years, security updates you can’t postpone, and environments to keep tidy. We look after the infrastructure and maintenance side, so the site stays fast, secure and up to date over time.

Overview

A complex Drupal site lives on two things: how fast it responds even under load, and how reliable it stays when an update or a traffic spike arrives. A badly configured cache inflates the TTFB, a major put off too long turns into a costly migration, an ignored patch is an open door: Drupal Security Team advisories don’t wait for a convenient moment.

We work to make updating and releasing a controlled routine, not a leap into the unknown: separate environments, exported configuration, tested backups and a rollback ready before every release. Our scope is the server, the platform and the deploy process; on the theme and custom modules, we coordinate with whoever develops the site, without stepping on each other’s toes. You get a single technical point of contact, documented configurations and no lock-in: the infrastructure stays yours and verifiable at any time, even if you decide to switch providers tomorrow.

Typical problems we solve

• High TTFB even on anonymous pages → we review Page Cache and Dynamic Page Cache, put Varnish in front of Drupal, and tune PHP-FPM and OPcache.
• A major put off for years (9→10→11) → we map modules and deprecations on staging, then upgrade with a rollback ready, without improvising on the live site.
• A backlog of security advisories → we apply core and contrib patches in agreed windows, with a backup taken before every release.
• Manual changes made directly in production → we bring the configuration under Configuration Management and releases onto Git and Composer.
• Cron and queues slowing everything down → we move cron to a system scheduler, size the queues correctly, and keep an eye on heavy jobs.
• Backups that exist but have never been tested → we move them off the server, encrypt them, and test the restore at regular intervals.

What’s included

• Performance: page cache and dynamic page cache, Varnish in front of Drupal, BigPipe, tuning of PHP-FPM, OPcache and the database to bring the TTFB down and hold up under traffic spikes.
• Updates: timely security patches on core and contrib modules, and major upgrades prepared on a separate environment with a tested procedure and a rollback ready.
• Security and hardening: correct file permissions, admin-area protection, careful handling of settings.php and credentials, a reduced surface and up-to-date TLS.
• Environment management: separate development, staging and production, with configuration exported through Configuration Management and controlled alignment between environments.
• Deploys: repeatable releases with Git and Composer, tracked changes and no manual edits on the live site.
• Verified backups: regular database and file backups, kept off the server, with the restore tested periodically.
• Monitoring: uptime checks, logs and PHP error tracking, with alerts that reach us before the problem reaches your users.

Stack and technologies

We usually build servers on Debian or Ubuntu; on request we also work with AlmaLinux, Rocky Linux and other distributions. The web front end is Nginx on PHP-FPM with OPcache, on the PHP version your Drupal supports, with Varnish for HTTP caching where traffic justifies it. The database is MySQL/MariaDB sized to the real workload, with Redis for cache and sessions where things need lightening. For recurring operations we use Drush, for code and configuration Composer and Configuration Management; releases go through Git and, where it makes sense, a CI/CD pipeline. On the cloud we work mainly with Google Cloud, with AWS and DigitalOcean as alternatives. On the perimeter, up-to-date TLS and Cloudflare as a first filter. Every component is tuned to your site, not left on defaults.

A real-world example

A public body with a portal on Drupal 9 nearing end of support: dozens of contrib modules, a handful of custom modules, deploys via FTP and no staging at all. We rebuilt the project under Composer, created a staging environment identical to production, and used Upgrade Status to map deprecations and modules with no compatible version. Once the custom code was fixed together with the agency that maintained it, we repeated the migration to Drupal 10 on staging until we had a reliable procedure. The release happened in an agreed early-morning window, with a verified backup and a rollback plan: the portal stayed reachable and the editorial team was back to publishing by mid-morning. Since then, core and contrib get updated on an ordinary monthly round, with no more emergencies to chase.

Who it’s for

• Public bodies and administrations with institutional Drupal portals that need continuity and security.
• Newsrooms and editorial sites with lots of content, roles and traffic to hold up.
• Agencies that built the site in Drupal and want the infrastructure looked after by people who know it.
• Anyone facing a major who doesn’t want to risk the migration straight on the live site.

How we work

We start with a check of site and server: Drupal and PHP versions, contrib and custom modules, cache state, how deploys happen today, environment management, backups and the main security gaps. From there we set out a plan with clear priorities and an indicative “from X” price; the quote is free, with a reply within one working day. Requests go through P1-P4 triage with Mon-Fri 10:00-18:00 coverage: details are on the response times page. For ongoing maintenance, many clients choose hour packages, which never expire. Every job ends with a readable report on what we changed and why: no black boxes.