PressRidge Managed WordPress hosting Sign in

How it is built, and what happens when something goes wrong.

PressRidge is managed WordPress and WooCommerce hosting. This page is not a feature list — it is the machine, the failure paths, and every number with the measurement behind it. If you want to know what your neighbour can reach and where your backups live, the answers are here rather than in a sales call.

What you are actually renting

Most hosting pages show you a dashboard. Here is the machine. Every box exists on every node, and the dotted line is the only thing between your site and the one next to it — which is why it is drawn.

Cloudflare edge, host nginx, one rootless container per site with its own identity, shared database and cache reached with per-site credentials, ZFS datasets, encrypted off-node backups, and a separate Control Plane holding every credential. A visitor Browser anywhere Cloudflare edge TLS Full (Strict) · real client IP the node refuses anything else One node · Germany · UK · United States Host nginx one vhost per site · cart, checkout and login bypass the cache · every config tested before it is swapped in Your site PHP-FPM · your own uid cannot write its own code tree Shell sidecar · SSH, SFTP, WP-CLI Own outbound IPv6 address the one you give a payment gateway Another customer Separate container. Separate Unix identity. Separate database credentials. The kernel is the boundary, not a configuration file. And another Rootless containers. Nothing on a node runs as root to serve a page. A site that is broken open reaches exactly what that customer already had. MariaDB & Redis per-site credentials · per-site cache keys a read-only console user for looking ZFS — one dataset per site files and database captured in a single snapshot, so they agree restic · encrypted before it leaves the node nightly, and before anything destructive Off the node Control Plane Holds every credential: Cloudflare, backups, mail. A web node never has one it does not need. Backblaze B2 Object Lock — a snapshot cannot be deleted early, by us or by anyone.

Two things on this drawing are the reason it exists. The dotted line is a real boundary — the kernel, not a setting. And the credentials live on a different machine from the one running your PHP.

What happens when something goes wrong

Stability is not an uptime number on a marketing page. It is what the system does on the day it is wrong, and these are rules the platform enforces on itself.

A broken configuration never reaches the other sites Every config is rendered, tested, and only then swapped in and reloaded. One bad vhost cannot take a node's other sites down with it — the test happens before anything is live.
Nothing destructive runs without a backup that was verified first Not taken and hoped for — verified, before the destructive step is allowed to proceed. If the backup cannot be confirmed, the operation refuses and nothing has happened.
A database is never rolled back automatically Files and code roll back. Data does not, because an automatic rollback silently destroys every order taken since the snapshot. That is a decision a person makes, with the snapshot in front of them.
“Could not tell” never renders as “fine” A check that cannot read its subject says so. A storage provider answering “access denied” is not an empty backup list, and a resolver that will not answer is not a domain with no mail — treating those as all-clear is how outages get missed.
An operation refuses rather than half-doing Moving a site between countries refuses by name when it cannot do it cleanly, before touching anything. A refusal you can read beats a job that fails at step nine.
A node hosts nothing until it passes every readiness check Filesystem, firewall, TLS, isolation, backup wiring. A node that fails one is not allowed a site, and the checks re-run rather than being trusted from the day it was built.
Backups cannot be deleted early — including by us Object Lock at the storage provider. A compromised control plane cannot shorten your retention, which is the scenario a backup exists for in the first place.

What happens when somebody buys something

A checkout is the one request hosting cannot afford to get wrong, and most of what goes wrong is caching. This is the path, in order.

The cache does not answer

Cart, checkout, my-account, login and any request carrying a logged-in cookie skip it entirely — verified by request, not by reading the configuration.

nginx hands it to your container and nobody else’s

One vhost per site, one PHP pool per site, sized from that site’s own plan rather than shared with whoever is busy.

PHP runs as an identity that cannot rewrite your code

The serving process writes uploads, plugins and themes. It cannot write WordPress core or wp-config.php, and a PHP file somebody uploaded will not execute — that returns 403.

The database answers on your credential only

Your user reaches your schema. Another customer’s schema answers access denied — measured between two live sites rather than assumed from the configuration.

The order confirmation is signed as you

Your sending domain has its own DKIM keys and DMARC record, so the mail authenticates as your shop rather than as the hosting company.

Every number, and how it was taken

Figures are readings from the live platform, not targets. Where something has not been measured, it is not on this page.

21.9 ms

Files and database from one instant

how A read lock, one snapshot naming both datasets, unlock — timed by the database server. A control run without the snapshot produced 1753 rows against 1792 files; with it, 811 and 811.

28 s to restore

Backups are restored, not assumed

how A real site restored end to end, timed. One repository here had a block the storage provider served as zero bytes, and the integrity check called it clean twice. Only an actual restore found it.

X-Fleet-Cache: BYPASS

A cached cart is one customer seeing another’s order

how Verified by request on the live edge for cart, checkout, my-account, login and any logged-in cookie.

2048-bit, per domain

Your shop’s mail is signed as your shop

how Each sending domain gets its own DKIM keys and a DMARC record, so an order confirmation authenticates as yours.

What email actually costs

Transactional email is the part of hosting most often sold back to you, so here is the arithmetic in full.

$0.16 per 1,000

What sending costs, at the provider

how Amazon SES list price on the plan this platform uses, for the first 10 million messages a month. That is the whole cost of moving a message; there is no per-domain charge and no per-mailbox charge.

~$0.24 / month

A shop taking 500 orders a month

how Roughly three messages per order — confirmation, shipping, the occasional password reset — is about 1,500 messages, which is twenty-four cents. Transactional email at a shop’s volume is not a real cost.

Which is why it is not metered here Charging per message for something that costs cents a month is a line item that exists to be a line item. Your sites send their transactional mail and nobody counts it.
What you are not being sold This is not a newsletter or campaign service, and it is not a mailbox. There are no inboxes to log into and no marketing sends — those are different products with different economics, and a host that bundles them is charging you for the bulk case whether you use it or not.
Why it is per-domain and not shared Each sending domain gets its own DKIM keys, and each customer’s sending is authorised only for their own domains. Shared sending is cheaper to run and means one stranger’s bad list decides whether your order confirmations arrive.
Hosting pricing is not set There is no price list yet, because there is no signup yet. When there is one, the email arithmetic above is what it will be built on rather than replaced by.

What is not built yet

A page listing only what works is a page you cannot judge. These are the four a competitor leaves off.

Uploading files from the browser You can browse, edit, rename, compress and extract in the panel. Getting bytes from your laptop into a site is SFTP or SSH today.
A vulnerability feed for plugins The panel shows which plugins have updates and verifies their files against what WordPress.org published. It does not know which have known CVEs, so it does not show a “0 vulnerable” number.
Per-customer bounce notifications Bounced and complaining addresses are suppressed automatically and rates are measured per customer. Telling you about an individual bounce is not wired up.
Signup There is no checkout. Sites are set up by hand, on purpose, while the platform is young enough that each one teaches us something.

The panel

Everything above is operated from one place: create a site, add a domain, take and restore a backup, open a database console, read the logs, change PHP, push staging live.

PressRidge is not open for general signup yet. If you run a WooCommerce shop and this page reads as reassuring rather than alarming, we would like to hear from you — early sites get attention no busy host can give.

hello@pressridge.com Open the panel