Campaign site hosting

Every campaign site has a launch date. Few have an end date in the billing.

A launch, a conference, an election, a seasonal promotion. The site exists for six weeks and should stop costing money afterwards. The deadline is external and immovable, which is the fact that shapes every other decision.

# The same shape, many occasions

Campaign sites arrive under different names, but the brief is always a fixed date, a burst of attention around it, and no reason to keep paying once it has passed.

• Launches — a product, an album, a book, a film, a rebrand, an open-source project going public.
• Events — a conference, a festival, a trade fair stand, a hackathon, a program that changes weekly until the day itself.
• Politics and fundraising — an election, a referendum, a petition, a crowdfunding round, a charity appeal with a closing date.
• Retail and seasonal — Black Friday, an advent calendar, a pop-up store, a limited edition that sells out and then needs a page saying so.
• Company moments — an anniversary, a recruiting push, a merger explained on a microsite, an annual report published as a site rather than a PDF.
• Media and teaching — a data investigation, a documentary companion, a scrollytelling piece, a course cohort, a competition with entry and voting phases.

The traffic curve is the same in each case: nothing, then a spike on the announcement, then a long tail that nobody budgets for.

# Built on the test domain, launched on the real one

Every environment comes with a test domain like en-34fdsa.frbit.app, served over HTTPS from the first deploy. The site is built, reviewed, and signed off there while the campaign is still under embargo — no DNS setup, nothing public to find. On launch day, the real domain is added and gets its TLS certificate automatically, usually minutes after DNS resolves.

The announcement spike is handled from the dashboard: each component scales individually, up before the press hit and back down once the curve flattens, with each size billed only for the days it ran.

# Six weeks should cost six weeks

Apps are created and destroyed on demand, billing is pro-rated and post-paid with a one-day minimum, and there's no contract to see out. A site that runs for 41 days is billed for 41 days.

The common failure is the opposite: the launch passes, the team moves on, and a host keeps billing monthly for two years because deleting it was nobody's job.

# Decide the ending at the start

A campaign site ends in one of three ways, and choosing at the start is what makes the ending cheap. It gets archived — crawled to flat HTML and published on a static host, while the app is deleted, since fortrabbit runs PHP applications rather than static output. It gets handed over — ownership and billing move to the client's account while the app stays where it is, nothing redeployed. Or it's destroyed, and billing stops that day.

Domains are registered separately and survive all three, which matters because the domain keeps earning long after the campaign.

# Why fortrabbit?

Because pay-as-you-go, post-paid, cancel-any-time has been the billing model here from the start, and a site with a deadline is where that shows. Build it on the test domain while the campaign is still under embargo, launch it on the real one, scale for the announcement and back down a week later, then end it deliberately. Six weeks costs six weeks — not a two-year contract nobody remembered to cancel.