Your VPS is self-managed, which means the operating system, the security patches and the software on it are yours to look after. This is the fifteen minutes a month that keeps it safe, and a ready-made prompt that does most of the work for you.
Hand this whole guide to your AI assistant
Download it as a prompt file, paste it into Claude Code, ChatGPT, Gemini or any LLM, and it will run the checks, tell you what it found, and prove your site still works afterwards.
▶ The whole routine in 4 minutes, narrated, with captions — where the provider’s job ends, the four separate things that need updating, and the one-time change that does the urgent half for you.
The shape of it. Your VPS is self-managed, which means the operating system, the security patches and the software on it are yours to look after. This is the fifteen minutes a month that keeps it safe.
Where the line falls. Your provider looks after the physical hardware and the hypervisor, the network and DDoS filtering at the edge, whatever backups your plan includes, and keeping the machine powered on. You look after everything else: OS security patches and the kernel, your control panel, the web server, PHP and the database, your TLS certificate, SSH access and firewall rules, and PageMotor core and every plugin.
The part people misread. That provider column is a set of tools, not a service. A malware scanner in a dashboard nobody opens has never caught anything. Your provider will keep the machine running perfectly while the software on it goes quietly out of date, and nobody emails you when a patch is published.
Not only good practice. If your site collects any personal data at all, and a contact form counts, UK and EU GDPR Article 32 require appropriate technical measures to keep it secure. A server left alone for a year is running a year of known, catalogued, publicly indexed vulnerabilities, and that is difficult to argue as appropriate.
Four jobs, not one. The operating system, which can be fully automatic once you turn it on. Your control panel, manually, monthly. PageMotor core, from the Updates screen when a release appears. And your plugins, from the same screen. A fully patched Ubuntu with an out-of-date CMS is still an out-of-date CMS.
And a fifth thing that is not an update. Certificate renewal is automatic and keeps working, right up until something changes the web server configuration and quietly breaks the renewal path. You find out ten weeks later, when it expires.
The highest-value job, done once. Operating system security updates can install themselves, and the gap between a fix being published and your server having it drops from months to about a day. Do not assume it is already running: it is not on by default on most control-panel server images, CloudPanel included.
The monthly run is report first, act second. The prompt asks for a status report and then stops: uptime, free disk, what is upgradable split into security and the rest, whether unattended-upgrades actually ran, certificate expiry, fail2ban bans, failed services, and recent authentication failures. Most months it finds very little. That is exactly the point.
Not a Tuesday job. It will never upgrade a major version of PHP, the database or the operating system on a routine run, because those are planned projects with a rollback plan. And it will never reboot without asking.
The step that matters most. Prove the site still works: fetch it over the public internet and show the status code and enough of the body to prove the real page came back. Not “updates applied”. Evidence.
You do. Every mainstream VPS is sold self-managed. Hostinger put it plainly on their own VPS page:
As our VPS solutions are self-managed, you will get full freedom to configure and manage the virtual server.
That freedom is the entire reason a VPS fixes what shared hosting does to PageMotor. On a cheap shared host you cannot raise the PHP execution limit, so AI plugins and busy forms time out. On a VPS the limits are yours. So is everything else.
Here is where the line falls.
| Your hosting provider looks after | You look after |
|---|---|
| The physical hardware and the hypervisor | Operating system security patches and the kernel |
| The network, and DDoS filtering at the edge | Your control panel, for example CloudPanel |
| Whatever backups or snapshots your plan includes | The web server, PHP and the database |
| Dashboard tools: firewall controls, malware scanner, monitoring | Your TLS certificate, SSH access and firewall rules |
| Keeping the machine powered on and reachable | PageMotor core and every plugin you install |
Nobody emails you when a patch is published. A server left alone for a year is running a year of known, catalogued, publicly indexed vulnerabilities, and the scanning that finds them is automated and constant. This is the most common way a small self-hosted site gets compromised, and it is almost entirely preventable.
If your site collects any personal data at all, and a contact form counts, then in the UK and EU this stops being only good practice. UK GDPR and EU GDPR Article 32 require appropriate technical and organisational measures to keep that data secure. An unpatched server is difficult to argue as appropriate.
People often patch one of these and assume they are covered. They are four separate jobs with four separate update mechanisms.
| Layer | How it updates | How often |
|---|---|---|
| Operating system Ubuntu, the kernel, OpenSSL, everything underneath |
Can be fully automatic once you turn it on | Continuously, then a reboot when the kernel changes |
| Control panel CloudPanel, if you use it |
Manual, by running clp-update |
Monthly |
| PageMotor core | The Updates screen in your PageMotor admin | When a release appears |
| Your plugins | The same Updates screen | When a release appears |
There is a fifth thing that is not an update but fails the same way: your TLS certificate. Renewal is normally automatic, and it normally keeps working, right up until something changes the web server configuration and quietly breaks the renewal path. You find out ten weeks later when the certificate expires. The monthly run below checks it.
This is the highest-value thing on the page. Operating system security updates can install themselves, and once they do, the gap between a fix being published and your server having it drops from months to about a day.
It is not on by default on most control-panel server images, including CloudPanel ones. Do not assume it is running. The prompt below checks rather than guesses.
Paste this into Claude Code, edit the bracketed lines, and press Enter.
I have a PageMotor site on a self-managed VPS and I want you to harden it
and set up automatic security patching.
MY DETAILS
- Server IP: [YOUR_VPS_IP]
- I SSH in as: root
- My SSH key: ~/.ssh/id_ed25519
- My site domain: [yoursite.com]
- Control panel: [CloudPanel / none / other]
- Provider: [Hostinger / Vultr / other]
HOW I WANT YOU TO WORK
- Take a snapshot or backup through my provider's dashboard BEFORE you change
anything. If you cannot do that yourself, stop and tell me how to do it,
and wait until I confirm it is done.
- Show me what you plan to change before you change it.
- Never restart the web server, PHP, the database or the machine itself
without telling me first and getting a yes.
- If something is already correctly configured, say so and move on. Do not
reconfigure things that are fine.
WHAT TO DO
1. Report the current state first: OS version, kernel, uptime, free disk,
free memory, and which of the things below are already in place. Do not
change anything yet. Wait for me to say go.
2. Automatic security updates. Check whether unattended-upgrades is
installed and actually enabled. If it is not, install and enable it for
SECURITY updates only. Do not enable automatic reboots. Show me the
resulting config and confirm the timer is active.
3. Firewall. Confirm only the ports I actually need are open, normally
22, 80 and 443, plus my control panel port if I use one. Tell me every
other listening service you find before closing anything.
4. SSH. Confirm key-based login works for me RIGHT NOW before you touch
anything, then disable password authentication and set root login to
key-only. Getting locked out of my own server is the worst outcome here,
so verify first, change second.
5. fail2ban. Install it if missing and enable an sshd jail. On many
distributions the package installs inactive, so confirm it is actually
running, not just installed.
6. Backups. Tell me exactly what backup my provider plan includes, how
often it runs, how many copies it keeps, and how I would restore one.
If my plan has no backups, say so plainly and tell me what it costs to
add them.
7. TLS certificate. Confirm the certificate is valid, tell me its expiry
date, and confirm automatic renewal is scheduled and working. If my site
runs PageMotor behind CloudPanel, confirm that /.well-known/acme-challenge
is still served from disk, because PageMotor MCP fixes to /.well-known/
can break certificate renewal if they are applied carelessly.
8. Write me a plain-text summary at /root/server-notes.md recording what
this server runs, what you changed today, and what needs checking monthly.
FINISH BY PROVING IT WORKS
Fetch https://[yoursite.com]/ over the public internet and show me the HTTP
status and the first part of the response. Then fetch the admin page and
confirm it loads. Do not tell me the server is hardened until you have
pasted that output. A command exiting successfully is not proof the site
still works.This is the routine one. Most months it finds very little, which is exactly the point. Paste it in, read what it reports, and tell it to go.
Monthly maintenance run on my PageMotor VPS. Work carefully and report
before you act.
MY DETAILS
- Server IP: [YOUR_VPS_IP]
- I SSH in as: root
- My SSH key: ~/.ssh/id_ed25519
- My site domain: [yoursite.com]
- Control panel: [CloudPanel / none / other]
- Provider: [Hostinger / Vultr / other]
GROUND RULES, THESE MATTER MORE THAN SPEED
- Snapshot or back up through my provider BEFORE any change. If you cannot
trigger it, stop and tell me how, and wait for my confirmation.
- This is a live production site. Report first, act second. I want to see
the list of what would change before it changes.
- Never upgrade a MAJOR version of PHP, MySQL, MariaDB or the operating
system as part of routine maintenance. Those are planned projects with a
rollback plan, not a Tuesday job. Flag them and stop.
- Never reboot without asking. If a reboot is genuinely required, tell me
why, and let me pick the time.
- If anything looks wrong or ambiguous, stop and ask. Leaving a job half
done and telling me is far better than guessing.
STEP 1: REPORT, CHANGE NOTHING
Give me a short status report:
- Uptime, and whether /var/run/reboot-required exists
- Free disk and free memory, and flag anything over 80 per cent used
- Everything in `apt list --upgradable`, split into security updates and
everything else
- Whether unattended-upgrades is enabled and when it last ran successfully
- TLS certificate expiry date for my domain
- fail2ban status and how many bans in the last month
- Any service that failed to start (`systemctl --failed`)
- The last 20 authentication failures, so I can see if I am being probed
- Current PageMotor core version and whether the Updates screen shows one
available
Then stop and wait for me.
STEP 2: AFTER I SAY GO
- Apply the operating system SECURITY updates.
- Apply non-security updates too, unless any of them touch PHP, the
database, or the kernel, in which case list those separately and ask.
- If I am on CloudPanel, update it with `clp-update`. CloudPanel's own
documentation says to snapshot first, so confirm the snapshot from the
ground rules actually exists before you run it.
- Clear out old kernels and package cache if disk is tight, and tell me how
much you freed.
STEP 3: THE APPLICATION LAYER
- Check my PageMotor admin Updates screen for a core update and tell me
what is available and what changed. Do not install a core update without
asking me.
- Check my installed plugins for updates the same way.
- These are separate from the operating system. A fully patched Ubuntu with
an outdated CMS is still an outdated CMS.
STEP 4: PROVE THE SITE STILL WORKS
This is the part that matters, so do not skip it or summarise it.
- Fetch https://[yoursite.com]/ over the public internet. Paste the HTTP
status code and enough of the response body to show the real page came
back, not an error page or a holding page.
- Fetch the admin login page and confirm it loads.
- Submit nothing, but confirm my contact form page renders.
- Confirm the TLS certificate is still valid and shows the expected expiry.
- If any of those fail, tell me immediately and tell me how to roll back to
the snapshot.
STEP 5: WRITE IT DOWN
Append today's run to /root/server-notes.md: the date, what you updated,
anything you deliberately did not update and why, and anything I should
watch next month.
Then give me a five-line summary I can read on my phone. Do not use the
words "done", "fixed" or "all good" unless you have pasted the live site
response from step 4.Monthly is the right rhythm for the run above, with automatic security patching covering the urgent things in between. That combination means critical fixes land within about a day, and your monthly pass catches everything automation cannot safely do alone: reboots, the control panel, the CMS, the plugins, and a human actually looking at the thing.
On scheduling, be realistic. You can ask an AI assistant to run on a schedule, but it runs on your computer, and your computer is asleep in a bag most of the time. A calendar reminder on the first of the month that you actually action beats automation you assume is running. If you want it genuinely unattended, that belongs on a machine that is always on, not a laptop.
The one thing worth automating properly is the security patching, because that is where the delay between a fix existing and you having it is the whole risk. Step 1 sets it up.
Nothing dramatic happens the day you miss one. The risk accumulates rather than arriving. If you are coming back to a server you have ignored for a long time, do not simply run everything at once on a Friday afternoon. Take a snapshot, run the report step, and read it. A long-neglected server sometimes needs an operating system release upgrade, which is a planned job, not routine maintenance.
Security patches are specifically designed not to. They are backported fixes that keep the same version numbers and behaviour, which is exactly why they are safe to automate. The things that genuinely can break a site are major version upgrades of PHP, the database, or the operating system, which is why both prompts refuse to do those as part of routine work and tell you to plan them separately.
Only kernel and a few core library updates need a reboot, and the server tells you by creating a file at /var/run/reboot-required. A reboot on a small VPS is typically well under a minute. The prompts deliberately never reboot on their own so you can pick the moment.
It is a good safety net and much better than nothing, but check three things: how many copies are kept, whether they include your database, and whether you have ever actually restored one. A backup nobody has tested is a hope, not a backup. The hardening prompt asks your assistant to find out and tell you.
There is no shame in deciding you do not want to be a systems administrator. Reasonable signs it is time to hand it over:
At that point the honest options are a managed hosting plan, a managed VPS from a provider that sells one, or a maintenance retainer with someone who does this for a living. All three cost less than the incident.