Secure hosting is a set of properties, not a product tier. A host is secure when your site is isolated from other tenants, served over TLS that renews itself, running on software someone patches, backed up in a way you have actually restored, connected to a database that is not on the public internet, and administered through accounts with two-factor authentication and a record of who deployed what. Everything else on a hosting company’s security page is either one of those seven restated or decoration.
The search results for this term are a strange mix: hosting companies with the word in their name, a vendor page listing every security acronym it can, and a forum thread from a business owner who just wants a simple site that will not be hacked. That third person is the reader. They do not need a compliance framework. They need to know which properties matter for a small site and how to check a host for them in ten minutes.
Table of contents
- What secure hosting is not
- Isolation: who else is on the box
- TLS by default, renewed without you
- Patching: the software you do not see
- Backups you have restored at least once
- Network: what the database is exposed to
- Access: the account is the perimeter
- The ten-minute check for any host
- How this fits the rest of the stack
- FAQ
What secure hosting is not
It is not a padlock icon. TLS has been the baseline for every serious host for years, and a company advertising a free certificate as a security feature is telling you about its pricing page, not its security. It is not a phrase like military-grade or bank-level, which describe nothing checkable. And it is not a single product you buy: a site on the most carefully run infrastructure in the world is still insecure if the admin password is on a sticky note.
The useful framing is a short list of properties, each of which you can verify or ask about. The rest of this post is that list, in the order they tend to matter for a small site.
Isolation: who else is on the box
On traditional shared hosting, hundreds of sites run under the same web server on the same machine, separated by file permissions and hope. A vulnerability in one tenant’s outdated plugin becomes a path to the others, and a noisy neighbour’s traffic becomes your outage. This is the property that separates cheap hosting from safe hosting, and it is rarely mentioned on the pricing page.
The modern answer is a private runtime per site or service: a container or virtual machine with its own filesystem, its own process space and its own resource limits. Your site cannot read a neighbour’s files because there are no neighbours in the filesystem. When a host says each service runs in its own isolated environment, that is the sentence to look for. The firewall in cloud computing post covers the network side of the same boundary.
TLS by default, renewed without you
Every site should be served over HTTPS with a certificate the host issues and renews automatically. The renewal is the part that matters. A certificate that someone has to remember to renew expires on a Saturday, and the SSL certificate renewal post exists because that happens constantly. Ask the host: when I add a custom domain, is the certificate issued automatically, and does it renew without a ticket?
Two smaller things belong here. Plain HTTP should redirect to HTTPS rather than serving a second copy of the site, and the host should let you set security headers, HSTS in particular, so browsers stop trying HTTP at all. A host that cannot set response headers is a host that will fight you on this.
Patching: the software you do not see
Your site runs on an operating system, a web server, a language runtime and a database, and every one of them has security releases. On a VPS you patch them. On a managed platform the host does, and the question is whether they actually do. A site running on a PHP or Node version past its end of life is exposed to every vulnerability found since, and the host that let it happen usually calls that flexibility.
For managed hosting, ask which runtime versions are offered and whether old ones are retired. For WordPress specifically, ask whether core updates are applied and whether the PHP version can be changed from the dashboard. The WordPress malware removal post is a catalogue of what happens when nobody patches.
Backups you have restored at least once
A backup is a claim until you restore from it. Hosts advertise daily backups; fewer advertise where they are stored, how long they are kept, and whether restoring is a button or a support ticket with a three-day queue. The database is the part that matters most, because the code is in a repository and the uploads can be re-uploaded, but the orders, the posts and the users exist nowhere else.
The checklist is short. Are database backups automatic and on a schedule you can see. Can you trigger one before a risky change. Can you restore to a point in time, and have you done it once, on purpose, on a quiet afternoon. The PostgreSQL backup post covers the database half; the database backups on RunxBuild page is what the managed version looks like.
Network: what the database is exposed to
The single most common serious mistake on small deployments is a database listening on a public IP with a password as its only defence. Scanners find it within hours. The database should be reachable only from the services that use it, over a private network, with public access off by default and an allow-list when it must be on. The database network security docs describe the shape.
Secrets follow the same rule. Database URLs, API keys and tokens belong in environment variables set on the service, not in a file committed to the repository and not baked into a container image. The Dockerfile secrets post explains why the image is the wrong place; the short version is that anyone who can pull the image can read it.
Access: the account is the perimeter
Most breaches of small sites are not exploits. They are a reused password on the hosting account. The host should offer two-factor authentication on the account, team roles so a contractor does not need the owner’s login, and deployments from a connected repository rather than credentials typed into an FTP client. A deploy history that shows who shipped what and when turns a bad afternoon from a mystery into a rollback.
Runtime logs belong on this list too. Security is partly about knowing what happened, and a host with no accessible logs is asking you to trust that nothing did. The error logs post is about reading them; the point here is that they should exist and be yours to read.
The ten-minute check for any host
Run these against a hosting page or a sales call. Yes to all seven is a secure host for a small site. Two or more silences are a reason to keep looking.
- Does each site or service run in its own isolated runtime, not a shared web server?
- Are certificates issued and renewed automatically for custom domains, with HTTP redirected to HTTPS?
- Which runtime versions are offered, and are end-of-life versions retired?
- Are database backups automatic, visible, and restorable from the dashboard?
- Is the database private by default, reachable only from my services?
- Are secrets set as environment variables rather than files?
- Does the account support two-factor authentication, team roles, and a deploy history with rollback?
RunxBuild answers yes to those seven by construction: every service, database and WordPress site runs in its own runtime, custom domains get automatic certificates, managed MySQL and Postgres instances have scheduled backups and private networking, secrets are environment variables, and teams, deploy history and rollback are in the dashboard. A small business site on managed WordPress starts at $3 a month on the Starter plan; a web service on the Dev plan is $4. The managed WordPress post covers what managed actually means for the patching item on the list.
How this fits the rest of the stack
Secure hosting for a small site is seven checkable properties, and a host either has them or it does not. Isolation, automatic TLS, patching, restorable backups, a private database, secrets as environment variables, and accounts with two-factor and a deploy history. Check them once, then spend the rest of the security budget on the things the host cannot do for you: strong passwords, updated plugins, and not clicking the email. The RunxBuild hosting calculator shows what a site with a private database and backups costs beside a plain static one, so the security properties are a line item rather than an upsell.
Useful related references:
- WordPress Malware Removal: Clean It Properly or Do It Again Next Week
- SSL Cert Renewal: ACME, Certbot, and the 47-Day Reality
- PostgreSQL Backup: pg_dump, pg_basebackup, and WAL Archiving
- Database network security on RunxBuild
FAQ
What is secure web hosting?
Hosting where the site runs in an isolated environment, is served over automatically renewed TLS, runs on patched software, is backed up in a way that can be restored from the dashboard, keeps the database off the public internet, and is administered through accounts with two-factor authentication and a deploy history. A host that provides those properties is secure; one that lists acronyms without them is not.
Is shared hosting secure?
It can be adequate for a static brochure site, but the isolation is weak: many sites share one web server and one machine, so a compromised neighbour is a risk to you. For anything with a database, logins or payments, prefer hosting where each site runs in its own container or virtual machine.
Does an SSL certificate make my site secure?
It makes the connection between the visitor and the site private and proves the site’s identity. It does nothing about a vulnerable plugin, a weak admin password or an exposed database. TLS is the baseline every site needs; it is not the whole of security.
How often should a website be backed up?
The database daily at minimum, and before any risky change such as a major update or migration. Files less often if they live in a repository. What matters more than frequency is that you have restored from a backup at least once and know how long it takes.
Do I need a web application firewall for a small site?
Usually not as a first priority. Isolation, patching, a private database and strong account security prevent far more incidents on small sites than a WAF does. A WAF becomes worthwhile when the site takes payments, has public forms under attack, or runs software you cannot patch quickly.