Give maintenance an owner
A cloud server needs a person responsible for keeping it supported and recoverable. Record who applies updates, checks alerts, investigates incidents and can restore the site. If someone else manages it, agree their scope and keep an independent way to regain your own provider and domain access.
Treat this as a routine to adapt to your environment. No short checklist establishes that an individual server is secure.
Control access
Use SSH keys, named administrative accounts and the least access required. Protect provider, DNS and Joomla administrator accounts with the available multi-factor options. Keep recovery methods somewhere accessible if the main device is unavailable.
Restrict management access appropriately and avoid exposing the database to the public internet when the application connects locally. Check both the host firewall and any provider firewall; a rule in one layer does not tell you the other layer is correct.
When changing SSH or firewall settings, retain an existing session and confirm a new login works before removing the old route. Know how to use the provider’s recovery console.
Review the application accounts, MFA and extension choices using the Joomla application security guide.
Keep every layer supported
Track the operating system, web server, PHP, database, Joomla core, templates and extensions. Review security announcements and apply updates through a process that includes a fresh backup, suitable testing and any required restart.
Remove extensions and accounts you no longer use. Check that remaining extensions are actively maintained and support your Joomla/PHP versions. Do not keep obsolete software simply because the homepage still appears to work.
Protect files and credentials
Use permissions that match the deployment model. Avoid world-writable files or using broad permission changes to suppress an error. Where Joomla’s web-based updater needs write access, understand that trade-off and limit unrelated access.
Keep backup archives, SQL exports, temporary PHP diagnostics and deployment credentials outside the public document root. Do not leave a phpinfo page or a completed installer exposed. Review whether uploaded executable files can run in places intended only for media.
Joomla’s configuration contains sensitive database settings. Ensure it is served through the intended PHP handler and cannot be downloaded as source. Keep secrets out of public repositories and shared troubleshooting logs.
Monitor useful signals
Check availability, disk space, memory pressure, backup completion, TLS renewal and error logs. Arrange alerts to reach an address outside the affected website’s own mail path when practical.
Limit log access and retention according to what you need to operate the site. When investigating an issue, avoid sharing customer data or credentials unnecessarily.
Rehearse recovery and respond to incidents
Keep an independent application backup and run an isolated restore drill. A server snapshot can help, but does not replace a recovery plan or prove database consistency.
If you suspect compromise, contain the affected environment and preserve enough evidence to investigate. Identify the entry point, review exposed credentials and restore into a clean, supported environment where needed. Bringing back a backup without addressing the cause can repeat the incident.
Build a protected staging copy for significant changes. If this ongoing work exceeds the time or expertise available, reconsider the management arrangement.
References: Ubuntu Server documentation, Vultr product documentation and Joomla Security Centre. Follow the current instructions for your actual operating system and software versions.