Statamic Maintenance for IT Teams

If your marketing team has sent you this page, they're probably asking you to approve a maintenance plan for your Statamic website. This is how I run it, in the detail you'll want before you say yes. For personal data, see Security and Data Handling. For the contract, see the terms and conditions.

At a glance

How a maintained Statamic site is run
Area	How it works
Operating system	Ubuntu 24.04 LTS
Web stack	NGINX and PHP 8.5 (PHP-FPM), from Ondřej Surý's packages
Application	The current major version of Statamic, on Laravel
Server management	Ploi, in an account you own
Hosting	Your provider, in an account you own
Server patches	Every night, automatically
Statamic and package updates	Monthly, through local, staging and then production
Critical security fixes	As a priority, outside the monthly cycle
Supply-chain checks	2-day release cooldown, Socket scan, Composer and npm audits
Monitoring	Uptime and application monitoring, around the clock
Access	One person, SSH keys only, from one fixed IP address
Backups	Yours, through your hosting provider

The server

Every site I maintain runs on Ubuntu 24.04 LTS, on a server managed through Ploi. The hosting account and the Ploi account are both in your name, and you pay the providers directly. If your site isn't set up that way yet, moving it onto a managed server comes first.

PHP comes from Ondřej Surý's packages, not from Ubuntu. Ubuntu 24.04's own PHP is 8.3, so Canonical's security notices and Ubuntu's unattended-upgrades don't cover the PHP your site runs on. Where a site needs Node.js on the server, it comes from NodeSource for the same reason.

Ploi runs a full apt upgrade every night, which covers Ubuntu, Surý and NodeSource together. Ploi's update system ignores errors, so a failed run would otherwise go unnoticed. Each server emails me after its nightly run, and a missing email is treated as a failure. During the monthly update I also check the installed PHP and Node versions against the latest security releases.

I move servers to a supported version of PHP or Node before security support for the old one ends.

Network and access

The firewall (UFW) denies all incoming traffic by default. Only ports 80 and 443 are open to the public.
SSH is allowed only from a single fixed IP address, and from Ploi's own server addresses.
SSH uses keys only. Password login is turned off.
Accounts used to reach your website and server use two-factor authentication (2FA) wherever the service offers it.
I'm the only person with access. You own every account, so you can remove my access at any time.

How updates reach your live site

Updates to Statamic, Laravel and the site's Composer and npm packages follow the same steps every month.

I pull a copy of the live site to my machine. Every change is made in Git.
Composer and npm only install versions that were published at least two days earlier. Most malicious package releases are found and pulled within hours, so the cooldown keeps them out. If a security fix can't wait, I bypass the cooldown for that one package, deliberately.
Every new version is checked by Socket for malware and supply-chain warning signs. composer audit and npm audit run before and after the update, and Composer refuses any version with a known security advisory.
I test the site locally, then deploy it to a separate staging server and check it there.
Once staging is right, the same commit is deployed to production through Ploi.
You get a short report of what was updated and why.

Because every release is a Git commit, a bad update can be reverted and redeployed. Before a significant update I may also take a server snapshot, but that's a precaution and doesn't replace your own backups.

Security fixes between monthly updates

Server packages are patched by the next nightly run. For Statamic, Laravel and the site's Composer and npm packages, I apply critical security fixes as a priority, without waiting for the monthly update.

I also build Sentinel, a free Statamic add-on that checks a site's installed packages against known vulnerabilities and end-of-life dates.

Monitoring

Each site has uptime monitoring, plus application monitoring through Laravel Nightwatch, which records errors, slow requests and failed jobs. Nightwatch holds its data in EU data centres for 90 days.

Alerts raised outside business hours are handled on the next business day, unless out-of-hours cover has been agreed. Response times depend on the plan, from three business days on Core to two business hours on Max. There's no uptime guarantee, because uptime also depends on your hosting provider and the services your site connects to.

Who does what

What I look after and what stays with you
Task	Who
Hosting account and invoices	You
Ploi account	You own it, I work in it
Backups and hosting snapshots	You, and I can help set them up
DNS and email records	You
Statamic Pro and paid add-on licences	You
Nightly server patches	Me (automatic, checked)
Statamic, Laravel, Composer and npm updates	Me
Critical security fixes	Me
Monitoring and alerts	Me
New features and changes to custom code	Quoted separately
Personal data in the site	You're the controller, I'm the processor

Questionnaires and documents

I'm happy to complete your security questionnaire, or provide anything else you need for a supplier review. These documents cover the detail:

Security and Data Handling: a short summary written for IT, procurement and data protection teams
Data Processing Annex: roles, sub-processors, audits, and breach notification within 48 hours
Terms and conditions: what each plan covers, and what it doesn't

For prices and plan details, see Statamic maintenance plans. If you'd rather talk it through, get in touch and you'll speak to me directly.

What's included?

Statamic maintenance for IT teams