Standing service linux-patch-and-review-one-server-monthly · revised 11 October 2026
Standing service
Keep one Linux server patched and reviewed, month after month
Each month one Linux server has its automatic updates checked, the rest applied in a window you approve after a snapshot, its services, disk, certificates and logins checked, and a short report.
This starts a conversation by email. Nothing is charged, and no server is checked, until we have agreed scope and terms with you in writing.
The responsibility you hand over
A server that works is easy to forget. Updates wait, a certificate nears its end, a disk fills slowly, an old account keeps its login, and a reboot is pending for months. Each is small, and together they turn into the outage or the incident nobody planned for. Automatic security updates help but do not tell you what they changed, what is held back, what needs a restart or what the disk will do next month.
Who it’s for: A founder or small team with one production server that nobody has time to look after, and no one who owns patching and checking it.
Usually starts when: The server was set up once and has been left running, the last update nobody remembers, or an audit question asks who keeps it patched.
The result: The server keeps its automatic security updates switched on. Once a month we check that they ran, list what they installed and what is held back, and prepare a change set for the rest. After a snapshot, and in a window you approve, that change set is applied and the services you listed are checked. You receive a report of what changed, what is waiting and what needs a decision. Findings that need a repair are raised, not fixed silently.
What stays true, and what we do about it
No response-time or uptime guarantee is published for this new service. A date for each monthly report, and a target for reporting a finding, are agreed in writing before it starts, set to what a service at this stage can keep.
Hours are agreed in writing before the service starts. At launch the service is not staffed round the clock, so we do not offer round-the-clock or emergency cover.
What must remain true
- Security updates are installed by the server's automatic updates, which stay on; each month the review checks that they ran, lists what they installed and reports any that did not install
- Updates that need a decision, including held-back and non-security ones, are applied only in the monthly window you approve, after a snapshot, or the report says why they were not
- The services you listed are checked after every change and the results are recorded
- Disk use, certificate expiry dates, the accounts that can log in and pending reboots are read and reported every month
What we watch
- The package manager's update list and the automatic update log for the server
- Read-only checks run on the server: disk use, certificate dates, listening ports, login accounts and service status
- Your own notes of changes you made between windows
When something happens
Scroll the table sideways to read it all.
| When | What we do |
|---|---|
| The monthly review window opens. | We read the update list and the automatic update log, prepare a change set and send it for approval before anything is applied. |
| The automatic updates did not run, or an update was held back or failed to install. | We report it in that month's report with the log lines and propose the repair for your approval, under the notification target agreed in writing before the service starts. |
| A certificate on the server is inside its renewal period and has not renewed. | We report it with the evidence and propose the repair for your approval, under the notification target agreed in writing before the service starts. Priced as: Certbot renewal repair |
| Disk use grows by more than the agreed threshold from one month to the next and logs are the main cause. | We report the growth by location and propose size limits and rotation for your approval. Priced as: Log rotation for one server |
| A service on your list fails its check after an approved change. | We report it under the notification target agreed in writing before the service starts, with the evidence, and propose the revert. We revert only if the written agreement says we may. |
We do on our own
- Read update lists, logs and system status through the read-only route
- Prepare change sets and run dry runs that do not change the server
- Write the monthly report and the decision list
We ask you first
- Applying any update that we prepare, restarting any service or rebooting for it
- Any change to the automatic update settings, SSH settings, the firewall or accounts
- Any deletion or any new package source
We escalate to you when
- A security update fails to apply or breaks a service
- The automatic updates stopped running
- Signs of compromise appear, such as unknown accounts or unexpected processes
- The operating system release is near the end of its security support
- Disk, memory or certificate figures are near a limit that needs a decision
How you know it held. Each month you receive a report: updates installed automatically, applied by us and deferred, services checked and results, disk and certificate figures against last month, accounts that can log in, pending reboots and open findings.
How we keep it true
This service is never finished. Each month's report shows what was patched, checked and found, and it continues until you end it.
Harden one Linux server: key-only SSH, a firewall and automatic security updates Job Optional
One Debian or Ubuntu server gets key-only SSH, a deny-by-default firewall and automatic security updates, each checked from outside. It is not a penetration test or a certification.
Sets up key-only SSH, a firewall and the automatic security updates this service relies on. Needed first if those are not already in place.
Repair automatic certificate renewal on a server you manage yourself Job Each time it fires
On a server you run, Let's Encrypt renewal is repaired so a dry run passes, the schedule is confirmed, the web server reloads the new certificate, and an expiry alert you own is tested.
As agreed with you
Used when a certificate fails to renew.
Stop logs filling the disk: rotation and size limits on one server Job Each time it fires
Container, journal and application logs on one Linux server get size limits and rotation, so the disk stops filling. A growth test shows the limits working, and nothing outside the logs is deleted.
As agreed with you
Used when logs are the main cause of disk growth.
What is included, and what is not
- A change set for approval each month, and the record of what was applied
- The list of what the server's own automatic updates installed or restarted since the last report, taken from its package and boot logs
- A report of services checked after each change, with the check results
- A short written monthly report with a decision list
Included
- One Debian or Ubuntu server, and the services you list as important
- A monthly review of what the automatic security updates installed, the updates held back or not security-related, the automatic update log and any pending reboot; the updates that need a decision are applied only in a window you approve, after a snapshot
- Read-only checks of disk use, certificate expiry dates, the accounts that can log in over SSH and the listening ports, compared with the previous month
- A written monthly report of updates installed automatically, applied by us and deferred, findings and open questions
Not included
- Emergency response, out-of-hours cover or any guaranteed response time
- Fixing application bugs, restoring from backups or recovering a compromised server
- Upgrading the operating system to a new release, which is a separate project
- Applying any update that this service prepares, or restarting a service or rebooting for it, without your approval
- Turning off the server's automatic security updates: they stay on, and the report shows what they did
- Penetration tests, vulnerability scans or compliance certification
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each month's change set lists every pending update with its version before and after, and what the report calls applied or deferred matches the package log on the server.
Evidence: The change set and the package log lines for the window.
Every service on the list passes its check after each approved change, or the report names the failure and the proposed revert.
Evidence: The check results per service per window.
Each report shows disk use, certificate expiry dates and the accounts that can log in over SSH, with last month's figures beside them, and flags any change.
Evidence: The report tables.
No update that this service applies, and no restart or reboot it triggers, occurs outside an approved window, and anything the server's own automatic updates installed or restarted between windows is listed in the report.
Evidence: Your approval record and the server's package and boot logs for the month, with the automatic-update entries marked.
A snapshot dated before each window exists, and the change set for that window lists the packages and versions before and after.
Evidence: The snapshot date from your console and the change set.
Sign-off. You read each monthly report, approve each window and decide on each finding. A month counts as delivered when you have received the report and the approved changes are logged.
If it fails. If an approved update breaks a service we report it, propose the revert and fix the cause within the service where we can. If we cannot, we say so and what it would take. If the service is not working for you, you can end it at the end of any month.
When it fits, and when we stop
It fits when
- The server runs Debian or Ubuntu with a release that still receives security updates
- Automatic security updates are switched on and pass a dry run, or you first have them set up (the Linux baseline job does that); the monthly service does not turn them off
- A provider console, rescue mode or snapshot restore works, and a snapshot is taken or confirmed before each window
- A named person on your side approves each monthly window and receives the report
- You can provide a read-only route for the checks, such as output you run or an account limited to read commands, that you create and revoke
- The services you list can be checked with a command or a URL
We stop and tell you if
- The operating system release no longer receives security updates and the choice is a new release or a new server
- Signs of compromise appear, which need incident response rather than patching
- Most updates cannot be applied because of held packages or conflicting repositories that nobody on your side can resolve
- No snapshot or console route exists, so a bad update could not be undone
- No approval route exists, so updates would have to be applied without anyone agreeing
What could go wrong
Before each window you take, or confirm, a snapshot. Every change set lists the packages and versions before and after, so your administrator can hold a package or restore the snapshot; installing an older version again depends on whether the repositories still offer it, so the snapshot is the dependable route back. Ending the service leaves the server as it is, with the automatic updates still on and an approved change set finished or handed back.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| An update breaks a service or needs a restart at a bad moment. | The updates this service applies go in only in the approved window, after a snapshot, each listed service is checked afterwards and the revert steps are in the change set. |
| The server's own automatic updates install a package, or on some releases restart a service, between windows. | The report lists what they installed and restarted from the package and boot logs, so nothing between windows is invisible. Automatic reboot stays off unless you chose it. |
| The report gives false comfort because a check proves less than it appears to. | Each check states what it proves and what it does not, and the report lists anything that could not be checked. |
| A read-only route gives more access than intended. | You create the route with the least access, review the commands it allows and can revoke it at any time. |
A reviewer separate from the work that produced the change set reads it before it is sent for approval. No human supervisor is included unless your agreement names one. At launch the work is largely automated, and we say so.
Stays with a person
- You approve every update we prepare, and every restart and reboot we trigger
- You approve any change to the automatic update settings, access, the firewall or accounts
Access we would need
- A read-only route for the checks
- A monthly window in which you approve changes
- A snapshot or console route that you control
Questions
How is this different from automatic updates?
Automatic updates install security packages and stay on. This also checks that they ran, lists what they changed, applies what they do not (held-back and non-security updates, ones that need a restart) in a window you approve after a snapshot, checks your services afterwards, reads disk and certificate figures, flags old logins and tells you in writing what needs a decision.
Will you reboot my server?
Only inside a window you approve, and automatic reboot stays off unless you chose it. The report states when a restart is pending and what it will restart.
Do you give emergency cover?
No. There is no round-the-clock cover and no response-time guarantee for this new service.
Can you upgrade the operating system?
Not as part of this service. A release upgrade or a move to a new server is a separate project.
Also part of
Send an enquiry
Send us
- The provider, the operating system release and the services that matter
- How updates are applied today, if at all
- The day of the month and the time window you could approve
- Do not send passwords, keys or server logins in the first enquiry
Later, once you agree
- A read-only reporting route and the commands or account you agree
- The list of services with a check for each
- The person who approves each window and the person who receives the report
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the server and every key. We read through a read-only route that you create and revoke. Changes are prepared as a change set that your administrator applies, or applied through a time-limited account that you open and close, agreed in writing for each window. You take the snapshot before each window. We never hold root credentials between windows.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “linux-patch-and-review-one-server-monthly” as the subject.