How Zevonix protects the websites it manages. This describes the controls we operate, not the configuration behind them. A security page should build confidence without drawing a map.
We do not claim to be unbreakable. No hosting provider can. What follows is what we actually do, so you can judge it against your own risk. Where we have a limitation, it is stated.
On this page
1. Isolation
Each customer's websites run on their own virtual server. We do not place multiple customers on one machine. A compromise of one customer's site cannot read another customer's files, database or backups, because they are not on the same host.
Within a server, each site runs under its own system user with its own database credentials.
2. Access control
- Administrative access to our management console requires two-factor authentication. This is enforced, not optional.
- Customer portal accounts must use a second factor. It is prompted on first sign-in and becomes mandatory 48 hours later. An account that ignores it can still reach its own security settings, and nothing else.
- That second factor may be an authenticator app with recovery codes, or a passkey. A passkey is held by the device that created it, released only after a biometric or device PIN, and will not sign for any other website, so it cannot be phished, reused or replayed. A passkey can also replace the password entirely.
- Server access is key-based only, from a restricted set of addresses. Password authentication for administrative access is disabled.
- Connections verify the server's host key against the one recorded when it was enrolled, and refuse to proceed on a mismatch, so a substituted machine is rejected before any credential is sent.
- Passwords are hashed. Two-factor secrets, recovery codes and provider credentials are encrypted at rest.
3. Network and edge
Traffic reaches your site through Cloudflare, which provides TLS termination, certificate management, DDoS absorption and bot filtering before a request reaches the server. Origin servers do not expose administrative interfaces to the public internet, and firewall rules are applied at both the provider and host level.
Blocking is shared across the estate. An IP address that attacks one site on our network is refused at the edge for every site on it, rather than only on the server that saw the attempt, so an attacker who probes one customer loses reach to all of them.
Requests from a small number of countries are refused at the edge, currently China and Russia. This removes a large share of automated attack traffic before it reaches any server. If your site has legitimate visitors in a blocked country, tell us and we will lift the restriction for your domain.
Managed servers send outbound transactional mail only. They do not accept inbound mail, which removes an entire category of exposure.
4. Patching
Operating-system security updates are applied on a scheduled basis under policies that:
- scan every managed server daily for outstanding updates;
- take a server snapshot before applying anything, and refuse to patch if that snapshot cannot be taken;
- apply updates to a canary server first and halt the entire rollout if it fails, rather than continuing into the fleet;
- run inside a maintenance window, with urgent maintenance permitted outside it where a security risk requires.
5. Malware detection
Managed servers are scanned on a schedule using signature databases that include third-party web-malware signatures. Detections are reviewed by a person before action is taken. Third-party signature sets produce false positives, and deleting a customer's file on an unverified match is its own kind of incident.
6. Backups
- Backups are encrypted before they leave the server and stored with a separate provider, so the machine being compromised does not compromise its own backups.
- Databases are dumped individually, alongside the file system, so a single site or database can be restored without rolling back everything else.
- Each server's backups are held in a dedicated storage location with credentials scoped to that location alone.
- Retention follows your Service Summary. Backups are a recovery tool, not an archive.
7. Application security
Our own management console and customer portal are separate applications on separate machines, with separate credentials and separate session cookies. The portal holds only a projection of your data, and holds no credentials to the systems that manage your server.
Where the portal lets you act on your own site, such as refreshing or publishing a staging environment, the instruction is recorded on the portal and collected by the management system on its own outbound schedule. The management system accepts no inbound connection from the portal, and re-checks against its own records that the account asking owns the website in question rather than taking the portal's word for it. A compromise of the portal would therefore yield a request queue, not the fleet.
Both enforce HTTPS with HSTS, set a content security policy using per-request nonces, mark session cookies secure and HTTP-only, encrypt session contents, and put a bot challenge in front of sign-in and password-reset forms. Dependencies are audited and updated for known vulnerabilities.
Staging environments
Where a website has a staging environment, it is a full copy of that site, files and database, on the same server, under its own system user and its own database. It answers only on
its own hostname, never on your domain, and is served with headers and a robots.txt that
instruct search engines not to index it.
The limitation, stated plainly: a staging site is reachable by anyone who knows its address. It is not password-protected by default. Treat it as unlisted rather than private, and tell us if you want access restricted for a particular site.
8. Incident response
If we become aware of a material security incident affecting data within our control, we will notify affected customers as required by applicable law and by the circumstances, with the detail we have at the time, and update as the picture develops.
Where a site is actively compromised, our first duty is to stop the harm, which may mean isolating the site before we have a full explanation. We tell you what we did and why.
9. What we do not cover
Being straightforward about the edges matters more than a longer list of controls:
- We do not warrant compliance with PCI DSS, HIPAA, SOC 2 or similar frameworks unless separately contracted in writing.
- We do not audit your application code, your plugins, or content you or your developers publish.
- We cannot protect against credentials you disclose, or against software with no available fix.
- Availability is on commercially reasonable efforts; there is no numerical uptime guarantee unless your Service Summary states one.
Reporting a vulnerability
If you believe you have found a security issue affecting Zevonix or a site we host, please tell us at [email protected] before disclosing it publicly. We will acknowledge your report and keep you informed while we investigate.