Updates Without Risk: What’s Behind maxcluster’s Monthly Update Day

Companies that fail to update their systems regularly are playing a game with ever-increasing stakes. According to the BSI Lagebericht 2025, the number of newly registered vulnerabilities per day increased by 24% between July 2024 and June 2025. At the same time, security researchers at Outpost24 found that 18% of publicly accessible assets were classified as highly or critically vulnerable in their analysis—often simply because patches had not been applied.

Even more concrete: 76% of all cyberattacks in 2024 began with an unprotected or forgotten external asset, according to an analysis by Netzpalaver. Systems that are not kept up to date do not merely become slower—they become entry points for attackers.
(Source: netzpalaver.de)

For online shops, this is not an abstract risk. A compromised server can mean, in the worst case: data loss, GDPR notification obligations, reputational damage—and a shop that is offline exactly when customers want to buy. For a comprehensive overview of IT security in e-commerce—from attack vectors to protective measures—see our eBook “IT Security in E-Commerce.”

Regular updates protect against four key risks:

• Security: Critical vulnerabilities (CVEs) are closed before attackers can exploit them.
• Stability: Bugs in packages, memory management, and kernel modules are fixed before they cause outages.
• Compatibility: Dependencies remain cleanly maintained and software versions stay consistent.
• Compliance: Defined update processes help meet internal IT standards and data protection requirements.
   

The Update Day involves far more than just an automated script. A team of four experienced Linux administrators prepares each cycle in advance: open tickets are reviewed, risks are assessed, and responsibilities are assigned. Internal transparency is essential to ensure that nothing goes wrong on the outside.

The rollout itself follows a two-phase model.

Phase 1: Stage Clusters Go First

One week before the actual live update day—on the last Tuesday of the previous month—more than 700 stage clusters are updated. Why start with the stage systems? Because they provide the ideal testing environment: real infrastructure, real configuration, but no active business operations depending on it.

During this week, it can be carefully observed whether a package update behaves differently than expected. Incompatibilities are identified before they reach a live shop. And as a customer, you have time to test your application on the stage system—and react if necessary.

Possible responses:

• Fix a bug in your application that becomes visible with the new package version.
• Contact support if necessary to postpone the update of your live cluster.

Software freeze:
Between the stage and live update day, a software freeze is in place. Stage and live clusters run on the same software version—this is the only way to ensure a valid comparison between the environments.

Phase 2: Live Clusters — Controlled and Staggered

On the first Tuesday of the month, between 6:00 and 9:00 a.m., updates are rolled out across more than 2,500 live clusters. The rollout is staggered—systems are not updated all at once, but with time offsets to avoid overloading the infrastructure.

During this phase, a central monitoring dashboard is active. The admin team can see in real time whether services are running smoothly, if errors occur, or if intervention is required. Updates run automatically—but control remains manual.

Public holiday in NRW?
If the first Tuesday falls on a public holiday in North Rhine-Westphalia, the update day is moved to the second Tuesday of the month.

The Update Cycle at a Glance

On Update Day, all Ubuntu packages on the cluster for which new versions are available are updated. This includes the entire operating system toolchain—from core system commands and PHP to database services and web servers.

What is not updated: all applications that you or your agency have installed and manage yourself. This includes:

• Shopware, Magento, and other shop systems
• WordPress, TYPO3, and other CMS platforms
• PM2 applications and custom services

Clear boundary: maxcluster updates the infrastructure—your application remains under your control. We do not touch it.

No Surprises: Why We Only Apply Backward-Compatible Updates

To ensure updates do not cause unexpected disruptions, maxcluster consistently follows semantic versioning. This means we only update within the same major and minor version—in other words, we apply patch updates only, which are backward compatible.

For example: MySQL 8.0.1 may be updated to MySQL 8.0.2—but not to 8.4.1. The difference is important: patch updates (the third digit) are generally safe, while changes to the second or first digit may introduce incompatibilities.

If a major or minor version ever needs to change, we inform you in advance—giving you enough time to prepare your application.

What Happens If Something Goes Wrong?

In most cases, updates run smoothly. Ubuntu is known for well-maintained package quality and stable dependencies. Occasionally, however, special cases can occur: a service may fail to restart, a configuration file may need adjustment, or a service may require manual intervention. These are exceptions—and they are usually resolved on the same day.

For more serious situations, there is a clearly defined escalation plan:

• The monitoring team detects issues in real time via the dashboard.
• Within one to five minutes, the system can switch to the passive server.
• The passive server holds the data state from 6:00 a.m.—no backup needs to be restored.
• The rollback is minimal, fast, and possible without significant data loss.

Backup strategy and the update process complement each other: if you have both under control, you remain capable of acting even in critical situations. Our article “Backups in E-Commerce” explains what a solid backup strategy for your shop should look like.

For critical security vulnerabilities—such as Heartbleed, Ghost, ShellShock, and similar issues—we respond outside the regular cycle immediately after our analysis. In such cases, services may need to be restarted outside the scheduled update window.

What You Can Expect on Update Day

For most shop operators, Update Day passes quietly. Still, there are a few points you should be aware of:

• Short service restarts are possible.
  Packages such as php-fpm, MySQL, Apache, or NGINX require a restart after an update. During this brief phase, individual services may be temporarily unavailable. The time window is usually very short—but it does exist.
  Test your shop after Update Day.
• Even though we do not expect incompatibilities, running a quick functionality check of your shop after Update Day is a good practice. In the Managed Center, under Access & Management → Package Updates, you can find a complete list of all installed packages, sorted by date.
• What if an incompatibility occurs?
  In rare cases, it is possible to temporarily roll back individual packages to the previous version as a short-term workaround. However, it is important to understand that a downgrade excludes that package from future updates, thereby increasing the very security risk the update was meant to fix. The cleaner solution is always to adapt your application to the updated package version.
• Critical security vulnerabilities
  For severe vulnerabilities such as Heartbleed, Ghost, or ShellShock, we do not wait for the next Update Day. After our analysis, we respond immediately—even outside the regular cycle. In such cases, services may need to be restarted at unscheduled times. We will proactively inform you if this happens.

You can find more details about the process and potential risks in our Knowledge Base article on Update Day.