Private access
Admin and customer access should be scoped to the sites people are meant to manage.
Protect what you have made.
Access, backups and recovery planned from day one, so your site can get on with its job.
BUILT AROUND YOUR SITE
Practical safeguards.
Backups with a purpose
A backup matters when it can be restored. We agree what is backed up and how recovery is checked.
Careful changes
Updates and migrations need checks and a route back, especially on busy WordPress sites.
Media boundaries
Public images and private files need different delivery rules; we plan that before offloading content.
LAYERS, NOT LUCK
Several checks before anything reaches your site.
No single setting keeps a site safe. We stack independent protections, so one gap is never the whole story.
- Sites sit behind Cloudflare, with managed firewall rules, application-layer DDoS protection and HTTPS enforced end to end.
- Fully proxied sites refuse any connection that did not come through Cloudflare, so the edge cannot be bypassed.
- Visitor addresses are only trusted from Cloudflare’s published network, so rate limits and bans see the real visitor and cannot be fooled with a forged header.
- Two firewalls, the cloud provider’s and the server’s own, keep internal services such as caches, databases and admin backends off the public internet.
- Repeated failed logins are banned automatically, and operating-system security updates install themselves.
- Shared code is read-only to every site, and nothing sensitive, from config files to database dumps, is ever served from a site’s root.
- Databases, media and server disks each have their own backups, and we test restores rather than assume them.
A RECOVERY PLAN, NOT A BADGE
We agree what a restore has to bring back.
For a publishing site, recent posts and uploads matter. For a shop, orders and customer records change throughout the day. We discuss those differences before agreeing backup coverage, retention and a recovery route for each accepted site.
When a change could affect visitors, we plan a check and a way back. No setup removes every risk; the useful question is how we will notice a problem, who makes the decision and what can be restored. See how we plan a move →
CUSTOMER LOGIN
Invitation first.
Customer login is not live on this public site. We handle hosting enquiries directly during beta. We will issue customer accounts by invitation once we have tested that each customer can reach only their own resources, then link the panel here.
FROM THE BLOG
Security advice you can use today.
Some of what we do is worth doing on any server. We share it, commands included.
LET’S TALK
Tell us about your site.
We’ll review what you need and give you a clear answer about fit, scope and the next step.
HOW ISOLATION WORKS
Each site in its own lane.
- Every site runs as its own Unix user with its own PHP-FPM pool, so one site cannot read another’s files or config.
- Sites never hold AWS keys. Media uploads go through a host broker that checks the calling site at the kernel level and only writes to that site’s own storage prefix.
- Sites can sit behind Cloudflare, with login rate limits and xmlrpc blocked where it isn’t needed.
- Changes to live sites go through Git, so every edit has an author, a time and a way back.
- The customer panel stays closed until automated tests prove each tenant only sees its own sites. We’d rather launch late than leak.
Want the detail? See how the platform is built →