OpalSpan Automations let Mech return to your servers on a schedule, investigate PHP exposure and carry out the maintenance you have authorized. The 21 October 2026 PHP security releases addressing CVE-2026-109618 and CVE-2026-109619 make immediate patching urgent; a recurring job keeps the responsibility active after the emergency.
For a web agency, hosting team or IT department, this creates continuing maintenance capacity. Mech can check vendor advisories, establish what is installed, prepare a fix, apply it within your rules and check the service afterward. You review the initial responsibility and handle decisions that change its scope.
Illustrative workflow: shop-web-01 and shop-web-02 serve one application redundantly; shop-jobs-01 processes its background work. These are fictional enrolled servers in one OpalSpan workspace.
Separate daily discovery from the maintenance window
Use OpalSpan's desktop Automation editor to select those three exact devices. Create a daily check at 07:30 and a weekly maintenance job on Sunday at 03:00, with changes allowed until 04:30. Save Europe/Copenhagen as the timezone so the schedule follows the local clock.
Review the instructions, selected model and reasoning, per-run AI-credit cap and available credits. Additional device-work spending has a separate budget and authorization; leave it at zero unless an Admin has approved additional spend. The schedule creates an opportunity to work. Connection, permissions and available allowances still determine whether a run can proceed.
Give the daily check a clear instruction:
Check PHP on shop-web-01, shop-web-02 and shop-jobs-01 only. Identify the web and job runtimes and their package or image suppliers. Compare their actual installed revisions with current PHP and vendor security advisories. Make no package, configuration or service changes. Record checked time, applicable fixes and evidence of vendor backports. Keep offline and access-blocked devices separate from verified results. Retain unresolved findings and identify any urgent issue requiring the on-call operator's attention.
Mech builds the assessment from the connected machines' existing tools and available advisory information. Your instruction gives those checks a purpose, scope and follow-up responsibility.
Give the maintenance Automation a complete job
The weekly job performs its own current checks before making changes. Its persistent conversation is separate from the daily check's conversation, so include the scope and maintenance policy in both definitions. For this example, all three servers use an approved, vendor-supported PHP 8.3 branch.
Maintain PHP on shop-web-01, shop-web-02 and shop-jobs-01 only, on Sundays between 03:00 and 04:30 Europe/Copenhagen. Use the current approved PHP 8.3 branch and configured vendor repositories. Apply supported security and maintenance releases, checking the vendor's fixed package revision and advisory coverage.
Before changing a device, confirm current access, runtime ownership, application compatibility, backup readiness and a usable rollback. Prepare the update and expected checks. Allow enough time for verification and recovery within the window; defer changes that cannot fit.
Update one web node at a time. Check the other node can serve the application, use our existing authorized drain/readiness procedure, and wait for active work to clear before updating packages or restarting PHP. Check the updated node's runtime, application readiness and agreed customer journeys before returning it to service. Continue to the second node only after the first is healthy. If draining or readiness cannot be established, stop that rollout.
On shop-jobs-01, pause new job intake through the application's supported controls, preserve queued work and complete or safely stop in-flight jobs before a service restart. Verify processing afterward. Keep application or database migrations, PHP branch changes, new privileges and purchases for the service owner's decision. Reboots require a separately approved window and working recovery access.
Use the configured AI cap and work allowance. Leave a handback covering fixes and checks, already-fixed devices, offline devices, blocked work and the next responsible owner. Preserve unresolved exceptions for later runs. Do not change this Automation or its schedule.
This turns recurring maintenance into executable work: prepare, fix, check and retain whatever still needs attention.
Verify the serving runtime and the application
A package listing is one part of Mech's evidence. The agent follows the site's PHP-FPM pool, web handler or container to the runtime actually serving requests, and checks the interpreter used by jobs separately. An updated command-line PHP binary can coexist with an older web runtime.
For PHP 8.3, the October upstream fixes start at 8.3.36. A distribution may provide a backported fix under another package revision. Mech checks the vendor's advisory and installed build before deciding that an update is required or complete. The upstream security advisories provide the starting point; the server's supplier determines the supported package path.
Your readiness checks should reflect the application: authentication, an agreed non-destructive checkout check, queue processing and relevant error logs. Existing node-local readiness controls or deployment tools provide the drain operation. Their availability and permissions are part of Mech's preparation.
Keep restart and recovery responsibilities explicit
A PHP service restart and an operating-system reboot have different consequences. Prefer the service operation the update actually requires. If an OS reboot is necessary, confirm the specific window, recovery console or equivalent access, and the person responsible if the machine fails to return.
An installed OpalSpan Daemon configured to start at boot can reconnect after restart. Check actual device availability and current authorization before continuing. Obtain renewed authority where the previous approval was boot-scoped. A lost connection remains unresolved until verified; a scheduled run does not guarantee unattended recovery of a broken host.
An abandoned plugin that blocks the supported PHP version becomes another explicit exception. Mech can investigate compatibility and prepare a WordPress staging upgrade under a separate instruction, while the service owner decides about replacing the plugin or changing functionality.
Keep the history useful between runs
Each Automation retains a conversation, and each wake has a separate run with its target and configuration snapshot. Mech can use the conversation's observations and unresolved findings while checking the machines' current state. This gives the next maintenance run useful context about a failed checkout test or a vendor package that was previously unavailable.
Overlapping wakes are skipped and missed wakes are coalesced. Pausing an Automation prevents new runs; an already-running job needs its own stop action if you want its work interrupted. Unattended runs cannot rewrite their own scheduling policy.
Ask for a handback that tells you what happened and what comes next. “Two web nodes patched and checked; job server offline; on-call operator owns reconnecting it” is more useful than treating the entire job as completed. Credit or access limits should leave remaining work visible for the responsible owner.
Use an urgent path when waiting would be wrong
Daily checks leave time between observations. A newly affected service may need action before Sunday. The on-call operator should review the finding and start an immediate Mech job with the appropriate emergency authority, or update the reviewed schedule and policy.
Prepared inventory, compatibility evidence, backups and maintenance procedures reduce avoidable emergency shutdowns. Protective downtime can still be the correct response when a service cannot be patched safely enough to remain exposed. Recurrence supports that decision with current evidence; it offers no guarantee against a new vulnerability.
Give Mech one ongoing responsibility on a server you are authorized to manage. See how OpalSpan works, create your workspace, choose your plan and Mech credits, and connect the server. Review the first check and maintenance policy, then let the Automation bring Mech back to the job.
References
Security facts checked 22 October 2026; recurring checks must use current vendor guidance.
- Official registry: CVE-2026-109618 and CVE-2026-109619.
- PHP's 21 October 2026 security releases.
- Upstream advisories: CVE-2026-109618 and CVE-2026-109619.