LochStudios / Help Centre / Security / Keep your website secure (updates, backups, least privilege)

Keep your website secure (updates, backups, least privilege)

Keep a site on our shared hosting or VPS safer with updates, the hourly copies we already keep, and logins that only have the access they need.

Updated 2026-08-18 01:36:43

Website security is not a one-time setup. It is an ongoing habit: keep the software you control updated, know how to restore a clean copy, and give each person only the access they need.

On Beginner and Standard shared hosting (cPanel) in Australia you already have tools for that. WordPress Toolkit and Installatron handle WordPress updates. Acronis hourly backups run without you turning them on. AutoSSL issues a Let's Encrypt certificate once the name points at this hosting. Open cPanel from the portal. Do not guess a hostname.

On a VPS you patch the operating system, the web stack, and the site yourself. Credentials and the console are on that server in the portal.

On a dedicated server, open a support ticket and we will walk you through access.

A step is unclear, or you would rather we apply the hardening? Open a support ticket and we will help.

Open cPanel

Sign in at the portal.
Open the hosting service for the site.
Click Log in to cPanel.

You do not need a server hostname to get in.

1. Keep software updated

Attackers look for known holes in old CMS installs, plugins, and PHP. Updates close those holes.

What we patch on shared hosting. We keep the server operating system, Apache, and MariaDB current. You do not log in as root to update those.

What you update on shared hosting.

WordPress, themes, and plugins. Prefer WordPress Toolkit or Installatron in cPanel. Open Toolkit, find the site, then Updates. Turn on automatic updates for WordPress (at least minor and security releases). Turn them on for plugins and themes if you are happy for those to update without a click. Full checklist: Secure Your WordPress Site.
Other CMS or custom code. Update it from that product's own tools, or from a copy you test first. Do not leave abandoned plugins or modules installed.
PHP. Keep the site on a current version this server offers. See Choose your PHP version.

Do not start a new WordPress site by downloading a zip from wordpress.org. Toolkit or Installatron creates the files, the MariaDB database, and the admin user.

How to stay on top of it.

Check Toolkit (or the CMS update screen) weekly if automatic updates are off.
Test a risky plugin or theme change on a subdomain first when you can.
Remove anything you no longer use. Deactivate is not enough. Delete it.
An outdated WordPress install is a common way sites get compromised. Apply security releases as soon as they appear.

On a VPS. You are the administrator.

Patch the OS. See First steps on a new VPS and Enable Automatic Security Updates.
Keep Nginx or Apache, PHP, and MariaDB current with the stack you installed.
Issue TLS with Certbot. There is no WordPress Toolkit on a stock VPS unless you installed a panel yourself.

2. Maintain regular backups

A backup is how you recover from a bad deploy, a deleted folder, or a compromised site. On shared hosting you already have hourly copies. You should still keep your own file before a redesign or a plugin experiment.

Hourly copies we keep. Every Beginner and Standard plan includes Acronis hourly backups. Those copies live on a separate server and do not use your disk quota. You do not turn them on. Restore points sit in a 30-day window.

To put the account, one site folder, or a database back from one of those points, open a support ticket. Tell us the domain, what to restore, and the date and time you want. Wait for us to confirm before you keep editing the live site.

Hourly copies are not a file you download yourself.

Copies you make. Use Backup or Backup Wizard in cPanel when you want an archive on your computer. Download it, then delete the leftover file from the account. Archives that stay in the home directory do count toward disk, and they can be fetched if the site is compromised. Full steps: Download and Restore a Backup.

For WordPress, prefer a Toolkit or Installatron backup when those tools already list the install. See Back Up and Migrate a WordPress Site.

Good habits.

Take your own copy before you update WordPress, change PHP, or replace a theme.
Store that copy off this account (your computer, an external drive, or storage you control). A zip that only exists in public_html is not a backup.
Keep more than one generation of your own copies, plus ours.
Back up files and the database. A site without one of those is not restorable.
Test a restore on a subdomain when you can, instead of overwriting the live document root first.

On a VPS. We do not run Acronis on the VPS for you. Snapshots and copies are yours to schedule. Keep at least one recent copy somewhere that is not that server. Open a support ticket if you want us to walk through a snapshot plan.

This article does not cover LochStudios Mail (Axigen). Those mailboxes live on the mail service. Open that service in the portal and open a support ticket if you need a restore there.

3. Use least-privilege access

Give each person and each tool only the access they need, and no more. That limits the damage if one password leaks.

Your portal password, your cPanel password, an FTP login, a WordPress administrator, and a MariaDB user are different credentials. Do not reuse one password across them. See Create strong passwords and use a password manager.

Practical steps on shared hosting.

- Portal and cPanel. Sign in at the portal and use Log in to cPanel. Do not share the main cPanel user with a contractor. That login can see the whole account.
- WordPress roles. Only use an administrator login when you need full access. Day to day, work as an Editor or Author. Do not keep a user called admin. See Secure Your WordPress Site.
- FTP. Create a separate FTP account for each person or deploy tool. Jail it to the folder they need:
- Developer: public_html only (or the addon / subdomain document root)
- One feature: public_html/new-feature only
- Do not clear the Directory field or set it to / unless you mean to give the whole home directory
- MariaDB. Create a database user per application. Attach it to only the database that app needs. Use a narrower privilege list when the app documents one. Leave Remote MySQL empty unless something outside this account must connect. See Allow Remote MySQL Access.
- File permissions. In the File Manager, folders should be 755 and files 644. You can set wp-config.php to 600 if you want it tighter; reload the site, and set it back to 644 if WordPress cannot read it. Never use 777. That lets a visitor write PHP into the site. If a script cannot write after 755 / 644, open a support ticket rather than opening the permissions further.
- Revoke promptly. When a developer leaves, a contractor finishes, or a plugin no longer needs FTP, delete that login the same day. Do not leave it active "just in case."
- Audit monthly. In cPanel, review FTP Accounts, MySQL Databases users, and (for WordPress) Users in wp-admin. Remove anything you do not recognise.

Example. You hire someone to build a feature. Create an FTP account jailed to public_html/new-feature, give them that login only, and delete it the day the project ends.

On a VPS.

Create a sudo user and stop using root for daily work. See First steps on a new VPS.
Restrict SSH to keys and turn off password login. See Secure SSH with key-based authentication.
Put a host firewall in front of the services you actually run. See Set up a UFW firewall on Ubuntu.

Turn on HTTPS

Shared hosting includes AutoSSL (Let's Encrypt). The name must already resolve to this account.

In cPanel, open SSL/TLS Status.
Find the domain and www.
Run AutoSSL if a certificate is not there yet, then wait for a valid cert on that row.
In cPanel Domains, turn Force HTTPS Redirect on for that name.

Background: Understanding SSL/TLS and HTTPS. If SSL/TLS Status still shows no certificate after DNS has updated, open a support ticket.

Putting it together

A secure site follows a cycle:

Update the CMS, plugins, and PHP (or the VPS packages) when security releases appear.
Back up before a big change. We already keep hourly copies on shared hosting. Keep your own file as well.
Audit FTP, database users, and CMS roles monthly. Delete what you do not need.
Watch for extra administrators, odd files, or spam pages. If the site has already been changed by someone else, stop editing plugins and follow What to do if your website is hacked.

These three practices stop most attacks before they start, and they make a restore a ticket instead of a rebuild.

Need hosting first? Browse shared hosting, VPS, or dedicated. After the account is ready: Getting started after you order hosting.

Do not wait on an email thread. Open a support ticket and we will help.

← Back to Security