Campaigns have lifecycles; hosting should respect the ending
An evergreen product landing page may live for years. A campaign landing page exists for a flight of ads, an event registration window, or a seasonal SKU—and then it should go away or park cleanly. This article is about that lifecycle. For general landing-page craft, see static landing page hosting; here the emphasis is spin-up, isolation, measurement hygiene, and teardown.
StaticHost fits because each campaign can be its own site (plan site counts matter), deploys are reversible, and you are not maintaining a WordPress install per promo. Zip or GitHub of prebuilt HTML, HTTPS preview immediately, custom domain cert after DNS verifies, history/rollback. No remote npm, no SPA fallback, no email/cPanel/CDN product/forever-free (trial ~1 day).
Isolate per campaign
Prefer a dedicated StaticHost site (and often a dedicated hostname) per campaign:
go.example.com/spring2026.example.com- Separate deploy history from the evergreen homepage
- Separate teardown without touching core brand pages
Site quotas:
| Plan | Sites | Storage | Price |
|---|---|---|---|
| Starter | 1 | 2 GB | $9/mo |
| Pro | 3 | 10 GB | $30/mo (+ staging) |
| Scale | 10 | 30 GB | $65/mo |
| Business | 30 | 100 GB | $130/mo (+ teams) |
Agencies running parallel flights lean Scale/Business—agencies.
Spin-up runbook
- Freeze creative + copy.
- Build static page (hand HTML, export, or Vite single page).
- Zip contents correctly—zip.
- Deploy; QA on HTTPS preview (UTM links, pixels, forms).
- Add campaign hostname; DNS verify; wait for certificate—custom domain.
- Grep mixed content—SSL.
- Enable ads only after step 6.
- Record the site ID and hostname in the campaign ticket for teardown.
If the page is a history-mode SPA, fix routing before spend—SPA.
During the flight
- Small copy deploys; roll back losing variants via deploy history.
- Staging on Pro for legal review of claims without touching the live ad URL.
- Do not “temporarily” host unrelated content on the campaign hostname.
Teardown runbook
When the campaign ends:
- Pause ads and email drives to the URL.
- Replace the page with a polite sunset (
This offer has ended+ link to evergreen site) or remove the site if the hostname will be retired. - Lower DNS TTLs ahead of hostname retirement; remove DNS when done.
- Delete or archive the StaticHost site so you stop paying for ghost campaigns.
- Export final analytics; keep the last zip in object storage for legal/records if required.
Teardown is part of hosting cost control. Forgotten microsites are how teams accidentally need Business when Starter should have sufficed.
Measurement hygiene
Use unique UTM defaults baked into on-page links. Keep pixels campaign-scoped when vendors allow. Because StaticHost has no built-in edge A/B product, run experiments with external tools or sequential deploys—not mythology.
Worked example: two-week summit registration microsite
Product marketing wants summit.example.com live for fourteen days. Legal must approve claims. Paid social starts Friday noon.
Monday: build a single index.html with schedule anchors (/#speakers). Form posts to a registration SaaS over HTTPS. Zip and deploy to a new StaticHost site on Pro so staging exists.
Tuesday: legal reviews staging HTTPS URL; they reject one superlative. You fix copy, redeploy staging, get Slack approval. Production still shows the safe earlier build.
Wednesday: promote approved build to production; add summit.example.com; create DNS; wait for verification; wait for certificate. Grep for http:// pixels.
Thursday: QA on the custom domain—form, UTM links, mobile. Confirm try_files reality: you did not invent /register as a client route without a file.
Friday noon: ads on. Saturday: headline underperforms; you deploy a variant; Sunday you roll back via deploy history when CTR falls.
Day 15: pause ads; deploy sunset page linking to https://example.com/events; export metrics; delete the StaticHost site next billing cycle if the hostname retires. StaticHost never ran npm, never sent email, and never needed a CDN product for a two-week page with a 120 KB hero.
Failure table: campaign hosting
| Symptom | Likely cause | Fix |
|---|---|---|
| Ads live, cert not ready | Skipped DNS wait | Stop spend; finish verify → cert |
| Legal angry at live claims | Edited production first | Use Pro staging; promote after approval |
| Budget burns on old microsites | No teardown | Sunset + delete sites; right-size plan |
/agenda 404 from QR code | SPA path without file | Real agenda/index.html or hash |
| Form leads missing | Host assumed to mailbox | Form SaaS; test before ads |
| Wrong UTM on all creatives | Links not baked/tested | Preview click-through checklist |
| Nested zip, blank ad landing | site/index.html nesting | Flatten; re-QA on preview |
Extra procedure: campaign ticket template
Use these fields in every campaign hosting ticket:
- Site name / StaticHost site ID
- Hostname(s)
- Plan (and whether staging is required)
- Build source (zip owner or Git artifact branch)
- Form endpoint + analytics property IDs
- Ad start datetime + earliest teardown datetime
- Last known good deploy description
- Sunset destination URL
- Owner for DNS removal
When the flight ends, the ticket already knows what to delete. That is how you stay on Scale ($65) instead of sleepwalking into Business ($130) because twelve dead promos still exist. Evergreen craft remains in the landing page guide; this procedure is the lifecycle wrapper. No forever-free, no cPanel, no email—set those expectations in the same ticket so nobody opens a surprise request mid-flight.
Creative versioning without losing the audit trail
Regulators and brand teams sometimes ask which exact headline ran during a flight. Because StaticHost keeps deploy history, label deploys with ticket IDs (SUMMIT-142-headline-B) in your own notes when you upload. Keep the corresponding zip in object storage for the retention window legal quoted—even after you delete the live site in teardown.
Do not overwrite staging randomly during an active flight without recording what production currently serves. Pro staging is for the next candidate, not a scratchpad that drifts from the ad URL. If you must hot-fix a broken pixel, change only that snippet, redeploy, and note it in the campaign ticket. The host will not run npm mid-flight; your prebuilt artifact discipline is the compliance-friendly path.
FAQ
How is this different from the landing page article?
That guide covers structure and performance of landers generally. This one covers campaign isolation, ad-flight timing, and teardown.
Can one site host many campaigns under paths?
Yes (/promo/spring), but isolation and teardown get messier. Prefer separate sites when quotas allow.
Should campaign pages use the apex domain?
Usually a subdomain keeps risk and cookies cleaner relative to the main app/site.
What about post-campaign SEO URLs?
If the URL earned links, leave a sunset page with a clear next hop instead of hard 404 immediately.
Do I need Git for two-week campaigns?
Zip is enough. Use Git when multiple people ship changes under deadline.