The most expensive moment in any website, information-management-system, or mobile-app project is not the build. It is the Monday three months after launch, when a CVE drops, the team that built the system has already moved to the next client, and nobody knows who is supposed to patch what. The Managed Hosting + Security-Patch Retainer service we describe below was designed to make that Monday boring.
This article is not a sales page. It is a written-out explanation of the deliverable, the response timeline, and the operational shape of the service — so a prospective client can read it once and know exactly what they are buying, what they are not buying, and where the seams sit between this retainer and the other service lines (new feature work, redesign work, major version upgrades).
1. Who This Service Is For
The retainer is designed for organizations whose website, MIS, or app is business-critical but does not justify a full-time DevOps hire. Typical clients: B2B SaaS with a single product website plus a customer portal, manufacturers with an internal MIS and a public catalogue, e-commerce on Laravel / Shopify / WooCommerce, and Flutter apps in production with a Laravel backend. If you have between two and twenty surfaces that need to stay up, this retainer is the right shape.
2. What's Included Every Month
Five line items, fixed scope:
- Hosting infrastructure. We provision and operate the production servers (Nginx + PHP-FPM + MySQL/PostgreSQL, or the equivalent for your stack), the staging environment, and the backup target. You stay the legal owner of the cloud account.
- Daily backup with monthly restore test. Automated nightly backups to a separate region. Once a month, we run a full restore into a throwaway staging environment and verify that the application boots cleanly. The restore test is the line item that justifies the entire backup line — backups that have never been restored are not backups.
- Security patching. We monitor the CVE feeds for your specific stack (your PHP version, your framework version, your CMS, your key Composer / npm dependencies). When a patch lands, we apply it to staging within 24 hours, run the regression suite, and ship to production within 48 hours. For KEV-listed or actively-exploited CVEs, we compress that to 24 hours end-to-end.
- Uptime monitoring and on-call. External monitoring from three regions. An on-call engineer responds to a P1 within 15 minutes between 09:00–22:00 local time, within 60 minutes overnight. Quarterly we review the on-call ledger with you and adjust thresholds.
- Monthly health report. A one-page PDF: uptime, patch ledger, backup restore result, security incidents (if any), top three slow endpoints, recommended fixes. The report is the single artefact that proves the retainer is doing what you paid for.
3. What's Not Included (And Why That's A Feature)
The retainer explicitly does not cover new feature work, redesign work, major-version framework upgrades (Laravel 12 → 13, PHP 8.2 → 8.5), database schema migrations, or third-party integration changes. Those are quoted separately at the project rate. The reason this matters: if those items were "included," we would be incentivized to keep the retainer's scope ambiguous and undercharge for the easy months while taking losses on the hard months. By drawing the line clearly, both sides know what counts as a retainer task and what counts as billable work.
4. The 24-Hour Patch Timeline, In Detail
This is the part clients ask about most. The flow when a critical CVE drops:
- T+0: CVE published, our monitor pings the on-call engineer.
- T+1h: We confirm whether your stack is affected and email you a one-paragraph status note. If unaffected, the work ends here.
- T+4h: Patch applied to staging. Automated test suite runs. We notify you that the patch is in staging.
- T+24h: After human regression review on staging, the patch is deployed to production during the next maintenance window. For unambiguous critical CVEs, we deploy without waiting for the standard maintenance slot.
- T+48h: A "what we did" note is added to your next monthly health report, with the CVE, the affected component, the patch version, and the deployment timestamp.
5. Pricing Model
Three tiers, sized by the number of production surfaces and the criticality of uptime. Tier 1 covers a single website with standard business-hours response. Tier 2 covers a website plus an MIS or app, with extended-hours on-call. Tier 3 covers a portfolio of three to five surfaces with 24/7 on-call and an SLA-backed uptime guarantee. Annual contracts. Two months' notice to cancel.
6. The Onboarding Process (First 30 Days)
Onboarding is fixed-scope:
- Days 1–7: Inventory. We document every surface, every dependency, every credential, every cron job. The output is a written "system map" you keep, whether or not you stay on the retainer.
- Days 8–14: Backup and monitoring setup. First successful restore test gets done in this window.
- Days 15–21: First patch cycle. We bring all dependencies to current minor versions and ship the first monthly health report two weeks early so you see the shape.
- Days 22–30: Handover meeting with the client's IT lead. Two hours. We hand over runbook access, dashboard logins, and on-call escalation paths.
7. The Three Times This Month The Service Earned Its Keep
Specific to May 2026, three retainer clients had their Monday morning saved by this service line: an Exchange Server fix for CVE-2026-42897 deployed Wednesday night, a Composer dependency rollback for CVE-2026-45793, and the Drupal patch for CVE-2026-9082 scheduled in the maintenance window the same night the patch dropped. None of the three clients heard about the underlying vulnerabilities from a journalist. All three heard about them from a one-paragraph email from us, with the line "we have already deployed the fix to your production." That sentence is, in the end, what this retainer sells.