# Campaign site hosting Source: https://www.fortrabbit.com/use-cases/campaign-site Created: 2026-07-20 Reviewed: 2026-07-20 > Host a site that exists for six weeks — a launch, a conference, a promotion — with per-day billing, a plan for the traffic spike and a defined ending. 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. ## FAQ ### Is there a minimum contract for a short-lived site? **No** — Apps are created and destroyed on demand. Billing is pro-rated and post-paid with a one-day minimum billing period, so a site that runs for 41 days is billed for 41 days. Cancellation takes effect immediately, not at the end of a term. ### How should a campaign be sized for a traffic spike? **Start small, scale up** — Components are booked individually and can be resized while the app runs. The usual approach is to launch on a small PHP plan, watch the first hours, and scale up if the press hit arrives. Because scaling is billed by the day, an oversized week costs a week rather than a month. ### Can a finished campaign be kept online cheaply? **Elsewhere** — fortrabbit hosts PHP applications, not static output. A finished campaign is usually crawled into flat HTML and that snapshot is published on a static host, while the fortrabbit app is deleted. The domain stays registered and points at the snapshot. ### What happens to the domain after the app is deleted? **It survives** — Domain registration is separate from hosting and is unaffected by deleting an app. DNS records can be repointed to wherever the archive lives, or the domain can be redirected to a page on the main site. ### Is a flat-file CMS a good fit here? **Usually yes** — Grav, Kirby, and Statamic keep content in files in the repository, which removes the database from the deployment and makes the whole site reproducible from a Git clone. That matters most at the end, when the site has to be archived or handed on. --- - [Cancel any time](/benefits/cancel-any-time) - [Test domain](/features/test-domain) - [Agent ready](/platform/ai-ready)