Course hosting for the week the cart opens.
You sell for five days a year. The site is quiet for the other three hundred and sixty, and none of that matters if it falls over on day one.
One week decides the year.
A course business is a spike business, and everything below is about the few hours when the spike arrives.
A cart that holds when the email goes out
Launch traffic arrives within minutes of a send and lands on the checkout, which is the one page that cannot be cached. Capacity is reserved for that page rather than for the site around it.
Drip content that releases on schedule
Week three unlocks on the date the student was promised, not on the next page load. Release runs on a real scheduler, so a cohort that goes quiet still progresses.
Lesson video that never touches PHP
A student watching a forty-minute lesson would otherwise hold a worker for forty minutes. Video is served away from the application entirely.
Enrolled students, all at once
A cohort starts together and works through the same lesson in the same week, so load concentrates on a handful of URLs rather than spreading across the course.
Launch-day mistakes are recoverable
The riskiest edits happen hours before the cart opens. Daily restore points mean a wrong pricing change is undone rather than debugged live.
Quiet, then everything.
Sizing a course site on its average traffic is sizing it for the wrong day. The only figure that matters is concurrent checkouts in the first hour.
- Checkout capacity reserved for launch windows
- Drip release driven by system cron
- Video delivered away from the application
- Restore points covering pre-launch changes
Checkout under a send.
The measure is not page speed on a normal day. It is whether the checkout completes while everyone who opened the email is trying to buy.
What we change for course creators
The traffic shape is a spike on a known date, and every row is about surviving it rather than about the quiet months.
| Setting | What we do | Why |
|---|---|---|
| Checkout capacity | Reserved for known launch windows | Launch traffic lands on the one page that can never be cached, within minutes of an email being sent, on a date you already know. |
| Drip scheduling | Released by system cron rather than by page views | Content promised for a specific date has to unlock on that date even for students who did not visit, which WordPress's own scheduler cannot guarantee. |
| Lesson video | Served away from the application entirely | A student watching a long lesson would hold a PHP worker for its full duration, so a modest cohort can exhaust the pool by studying. |
| Cohort load | Planned around shared progression rather than spread | Students who start together reach the same lesson in the same week, so demand concentrates on a few URLs instead of distributing across the course. |
| Pre-launch restore points | Taken ahead of the cart opening | Pricing and access rules are edited under time pressure in the final hours, which is the worst possible moment to be debugging one. |
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.
Will the site survive my launch?
Do drip schedules release reliably?
Where should lesson videos live?
What if I break something the night before launch?
Open the cart with confidence.
Move the course across. Migration is free, students included.