Project hosting for the day you hit the front page.
An open-source project site is quiet for months and then takes a year of traffic in an afternoon, usually because somebody else posted the link.
Everything a project site asks of a host.
Docs, downloads and a traffic pattern that is entirely out of your hands.
A spike nobody scheduled
Traffic is flat until the project is on the front page of somewhere, and that is not on anyone's calendar. Scaling is automatic rather than something you request while it is happening.
Release binaries from the edge
Artefacts are the bandwidth on these sites, and serving them through PHP is how a launch takes the site down at the moment most people are looking at it.
Docs cached hard, purged on release
Documentation changes on release days and almost never in between, which is close to the ideal caching profile - long lifetimes with a deliberate purge.
Version URLs that keep working
Links to old releases live in issue threads and other people's blog posts indefinitely. Breaking them breaks documentation you do not control.
Embeds after first paint
Comment widgets and issue trackers load after the page renders, so a third-party service having a bad day does not slow a page about to meet ten thousand people.
Watch the launch, not the average.
For a project site the only interesting hour of the quarter is the one after a release goes out. Everything else is background.
- Live traffic and download rate
- Alert on origin errors during a spike
- One-click admin login
- Restore any daily backup from the dashboard
Twenty minutes after the post went up.
Almost all of that traffic wants the same three pages and one file. Handled properly it is the most cacheable surge there is.
What we change for an open-source project site
These differ from a standard WordPress site on the same plan, and each follows from traffic you do not control arriving without warning.
| Setting | What we do | Why |
|---|---|---|
| Scaling trigger | Automatic, with no approval step | A front-page spike is over before a support ticket about it would be read, so reacting manually is not a strategy. |
| Release artefacts | Edge-served with byte-range and resume support | Binaries are the bandwidth on a project site, and pushing them through PHP is how a launch takes down the page announcing it. |
| Documentation pages | Long cache lifetimes with a deliberate purge on release | Docs change on release days and almost never otherwise, which is the easiest caching profile any site can have. |
| Version archive | Kept at permanent URLs indefinitely | Old release links live in issue threads and other people's writing forever, and breaking them breaks documentation you have no way to update. |
| Third-party embeds | Loaded after first paint | Comment and issue widgets should not be able to delay a page that is about to be read by ten thousand people at once. |
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 if we end up on the front page of Hacker News?
Can I host release binaries on the site?
Will links to old releases keep working?
Do we need a separate docs platform?
Does a comment widget slow the page down?
Put your project site on a host that expects the launch.
Free migration, scaling with no approval step, and release files served from the edge.