What to know
- Test recovery and a second login before restricting access.
- Review both cloud and operating-system firewall rules.
- Verify running services, restore tests and alert ownership.
Start with recovery access
Before changing a production VPS, confirm that you can reach the hosting provider’s recovery console. Keep a working administrative session open, document the current network settings and identify the application owner. A security change is incomplete if the team cannot recover from a mistake.
Record the services the server must provide and which users need access. This inventory becomes the basis for a firewall policy and a sensible maintenance plan.
Secure SSH without losing your way in
Use individual administrator accounts and public-key authentication where your environment supports it. Test a second, independent login before removing an existing sign-in method. Validate the SSH configuration before applying a reload, and use instructions for your exact distribution. The Ubuntu OpenSSH guide specifically discusses configuration and validation.
Changing a port does not replace authentication or patching. Avoid copying a hardening command list onto a live server without checking what the application and its administrators need.
Build firewall rules from required traffic
List the actual administration, web and application ports before you change rules. Account for both the provider’s network firewall and the operating system’s firewall, including IPv6 where enabled. Test an allowed administrative connection from outside the VPS. The Ubuntu firewall documentation is a starting point for Ubuntu systems; panel-managed servers need their panel’s supported tools.
Treat patching as a complete workflow
Plan how the operating system, PHP, database, web server and application dependencies receive security updates. The Ubuntu automatic-update documentation explains repository selection and restart behavior. A third-party repository needs its own maintenance policy.
After an update, verify the running service rather than relying only on the package manager’s success message. Check a public page, sign-in and the application’s most important workflow. Our PHP security update explainer shows why runtime selection matters.
Backups and monitoring need an owner
Store a recoverable copy outside the server’s failure boundary and test it in an isolated environment. Set alerts for failed backups, disk pressure and service failures, and decide who responds. A log file nobody reads is not an incident process. See our website backup and restore plan for a useful drill.
What should the handover include?
Keep a short record: access tested, required ports verified, package releases recorded, backup restored and application checks passed. Revisit it after deployments and staff changes. Exact commands vary between Ubuntu, CloudLinux and other systems, so this checklist defines outcomes rather than one universal script.
Compare Kiava cloud VPS plans or ask our IT team to scope the management tasks your project needs. Management and backup coverage should be confirmed as part of the service agreement.
Sources & further reading
Primary sources supporting this article. The practical recommendations are Kiava’s general guidance and should be adapted to your project.