News hosting for traffic that arrives without warning.
A publication's worst day and its best day are the same day. The story goes wide, the traffic arrives in minutes, and the newsroom still needs to publish the follow-up.
Publish into a spike, not against it.
Two things decide whether a big day goes well: how much the edge absorbs, and how quickly a correction reaches readers.
The spike hits the edge, not PHP
An article that goes wide is one page requested by everybody. Served from the edge cache, that is one render and then bandwidth - the origin barely notices the difference between a thousand readers and a hundred thousand.
Corrections go live immediately
Publishing or editing an article purges exactly that article and the pages listing it, rather than the whole site. A correction is visible in seconds without throwing away every warm cache entry you have.
Editors keep working during the spike
wp-admin is never cached, so it competes with front-end traffic for PHP. Worker allocation leaves headroom for the newsroom, so the next story does not wait for the last one to stop trending.
Media that does not eat the origin
Images and video are served from the edge with range requests. A photo essay is bandwidth at the edge rather than PHP workers at the origin.
Yesterday's edition, recoverable
Daily backups of database and uploads, so a botched bulk edit across an archive is a restore rather than an editorial incident.
The dashboard stays boring on a big day.
You find out a story went wide from your analytics, not from your hosting. That is the entire objective.
- Cache hit rate visible while it matters
- Purge a single article or a section
- Per-site resource view during a spike
- One-click access to fix something quickly
A hundred thousand readers, one render.
News traffic is the easiest kind to serve and the easiest kind to get wrong: everybody wants the same page at the same moment, which is exactly what a cache is for.
What we change for publishers
News load is spiky, anonymous and repetitive. That combination is unusually kind to a cache, provided the purge behaviour is right.
| Setting | What we do | Why |
|---|---|---|
| Edge cache TTL | Long for articles, short for listings | An article rarely changes after publication; the front page changes every time an editor touches it. |
| Purge scope | The article and the pages that list it | Purging the whole site on every publish throws away warm cache during the exact hour it is most valuable. |
| Admin capacity | Headroom reserved outside the front-end pool | wp-admin cannot be cached, so without reserved capacity the newsroom slows down precisely when it is busiest. |
| Media delivery | Edge-served with range requests | Photo and video-heavy articles would otherwise tie up origin workers streaming files. |
| Comment traffic | Treated as uncached writes | Comment posting is the one high-volume write on a news site and needs to bypass cache without dragging the article with it. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
What happens when one article goes viral?
How quickly does an edit appear?
Can editors keep publishing during a traffic spike?
Do you handle large archives?
Be ready for the day the story goes wide.
Start in minutes, or let us migrate the publication across - free on every plan.