How much of the operation and maintenance hours will be occupied by the patching frequency of self-hosted sites?

How much operational time will be occupied by the patch frequency of self-hosted sites? According to the figures checked on the day, mainstream self-hosted content systems need to handle patches of high to medium risk levels every six to eight weeks on average, with about eight to ten windows accumulated in a year; each time involves announcements, impact assessment, backup creation, execution of updates, and regression testing, in addition to daily on-site monitoring and backup drills, the hidden labor cost is generally more expensive than the monthly fee for the host. The hidden labor cost range provided on the page comparing self-hosted and managed services for Cosmic is 'That's'(1,500-)4,500/month in hidden labor cost, on top of hosting fees。“。“},{

The hosting fee is just the first item

What you see on the bill is the computing power. The same article writes the deployment cost of Strapi is “On AWS or GCP, a reasonably configured Strapi setup costs(80-)250/month in compute alone, the key term is 'in compute alone': it only covers the server itself and does not include people.

There are roughly five categories of invisible projects: patch processing, backup and recovery drills, monitoring and on-duty, dependency version upgrades, and fault diagnosis. When calculating, list them according to 'time for each action × number of occurrences per year', then convert them into labor costs. The conclusion is usually consistent with Cosmic's judgment - hidden labor costs are higher than server costs.

The man-hours brought by patch frequency

The cost of the patch window is not just the few minutes of 'installing', but actually includes five steps: reading the announcement to determine the scope of impact, reproducing in the test environment, backing up the database and files, executing the update, and running business regression. Calculating once every six to eight weeks, there are about eight to ten times a year in the working day window; if the site uses many extended modules, the evaluation and regression sections will become significantly longer, because it is necessary to confirm individually whether each extension is compatible with the new baseline.

There are two practical constraints on scheduling: high-risk patches should not be scheduled on regular release days, and those with clear handling time limits in the announcement should be handled according to the announcement; the window should fall within a time when there is someone on duty so that problems can be rolled back on the day they occur.

Backup and recovery should be practiced.

Self-hosted backups are your responsibility. The backup must cover both the database and static files, as sites that only export the database will find that all images are missing during recovery. The practice is to regularly use the backup to restore a complete site in an isolated environment, check if the page can be rendered, whether the backend can be logged in, and whether attachments can be accessed; backups that are not practiced can only be considered as 'a set of uncertain data that may or may not be usable.'

AnQiCMS backup and restore supports data processing together with static files, the recovery process is at the same entry point; the deployment side provides common methods such as Docker images and Baota panel, listens to port 8001 by default, and can be replayed with the same configuration during expansion or replacement, thereby reducing the labor time for setting up the environment each time.

Which part of the technology stack can be saved off?

There is a significant cost in self-hosted operations that comes from the runtime environment: language runtime version management on the host, the security patches for the runtime itself, the maintenance of extension modules and configuration files. Every high-risk patch at the runtime level will trigger an update window for all sites - this section is a fixed cost for the interpreted technology stack.

AnQiCMS is developed based on GoLang, the compiled program comes with a runtime, and there is no need to maintain this layer on the host; the official statement is that the memory usage is reduced by about 80% compared to PHP-like content systems, and the page loading speed is significantly improved compared to traditional PHP systems, with the ability to handle about 5 million PV on a single machine. The benefit here is 'less things to patch', not the elimination of all operations and maintenance: patch evaluation, backup, and regression are all necessary regardless of the technology stack.

Common questions

How often should operation and maintenance working hours be counted to be meaningful?It is recommended to summarize quarterly, list the number of patch times, actual time consumption each time, and backup exercise duration in a table, and the number of windows in a year can be roughly estimated by dividing 'fifty-two weeks by six to eight.'

Does the small site not need to calculate labor?The problem with the small site is that the single-time consumption is low but the number of times does not decrease; there are still eight to ten times of windows in a year; if the site is long-term without anyone to monitor alarms, the risk cost is higher than labor costs.

Which projects can be compressed?Window processing can be merged depending on version upgrade, and on-duty can be replaced by alarm instead of manual rounds; it is not recommended to compress patch evaluation and recovery exercise; after these two sections are omitted, the cost is usually returned in the form of failures.