Municipal hosting for the storm that closes the roads.
A city website is a low-traffic reference site until an emergency, and then it becomes the official source residents and journalists refresh every few minutes.
Everything a city site is legally and practically expected to do.
Publishing obligations, accessibility duties and a traffic profile that is flat until the day it is not.
Emergency traffic absorbed without a call
A weather closure or a boil-water notice drives a year of traffic into an afternoon, and every visitor lands on the same two pages.
Agendas and minutes served from the edge
Municipal sites are mostly PDFs - packets, budgets, minutes. Served from origin they consume bandwidth and worker time for files that never change.
Accessibility that is not left to a plugin
Public sector accessibility duties are met in markup and delivery. Server-rendered HTML that works without JavaScript is the part of that a host is responsible for.
Public records kept for as long as required
Retention schedules outlive any content management system. Backups are held to the period your records policy specifies rather than a default fortnight.
Notices that go live immediately
An emergency notice behind a cache window is misinformation. Publishing purges the affected pages specifically, in seconds, without dropping protection elsewhere.
A small team publishing to an entire town.
Municipal sites are usually maintained by one or two people who have other jobs, and the emergency is exactly when they have least time to fight the platform.
- Targeted purge when a notice publishes
- Backups retained to your records schedule
- One-click admin login
- Restore any daily backup from the dashboard
The night of a closure announcement.
Everybody in the municipality opens the same page within an hour, and half of them are downloading the same PDF from it.
What we change for a municipal site
These differ from a standard WordPress site on the same plan, and each follows from a public body's publishing duties and traffic shape.
| Setting | What we do | Why |
|---|---|---|
| Document delivery | PDFs and agendas served from the edge with range request support | Meeting packets are large, static and downloaded in bursts, so serving them from origin spends worker time and bandwidth on files that have not changed in years. |
| Emergency capacity | Headroom maintained rather than requested during the incident | A closure notice reaches its peak traffic within the hour, and there is nobody available to file a capacity request while the emergency is being managed. |
| Backup retention | Set to the authority's records schedule instead of a rolling default | Public records retention is measured in years and set by statute, which no hosting default is written to satisfy. |
| Notice publishing | Purge scoped to the affected URLs at publish time | A stale emergency notice is actively misleading, and clearing the whole cache during the spike removes the protection keeping the site up. |
| Markup and delivery | Server-rendered HTML that degrades without JavaScript | Accessibility obligations apply to residents on old devices and assistive technology, where a client-rendered page fails completely rather than gracefully. |
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.
Can the site cope with an emergency announcement?
We publish a lot of large PDF agendas. Is that a problem?
How long do you keep backups?
Does hosting help with accessibility obligations?
How fast can we get a closure notice in front of residents?
Host a city website that residents can reach during the emergency.
Free migration, documents from the edge, and retention that matches your records schedule.