Engineered for failure. Deployed on your infrastructure.
On a life-safety platform, the architecture question is not "how fast is it when everything works?" It is "what happens when a process dies mid-escalation, a database fails over, or the WAN drops?" WillowCreek is built so each of those has a boring answer.
One central installation. One compact appliance per site.
No servers in the facilities
The platform installs once, centrally, in your data centre or private cloud. That installation holds everything for every site: the per-site runtimes, the estate console, the databases, shared outbound channels, and an included lab environment for testing rules and rehearsing upgrades before anything touches live operations.
Each site hosts exactly one thing: a compact positioning appliance, not a server, which stays on site because high-volume radio traffic belongs on the site LAN. Site equipment (handsets, paging, fixed duress, security panels) connects locally, so a WAN problem never sits in the alarm path. Adding a site later means adding an appliance and switching it on centrally.
How a deployment runs, step by step →Everything installs centrally on your infrastructure; each site keeps one compact appliance.
One code image
One code image, designed to run cloud, hybrid, on-premises or air-gapped. There is no "lite" build whose gaps you discover during an incident.
An install, not an assembly
One artefact, one command, everything inside it, nothing to wire up on site. Upgrades are the same operation with a newer artefact.
Signed containers on Linux
Signed container images, promoted by digest, running on Linux. No Windows hosts required, anywhere in the stack.
Your hypervisor, or none
VMware, Proxmox, Hyper-V, KVM, Nutanix, or bare metal. x86-64 throughout, ARM64 for edge appliances.
No Kubernetes prerequisite. A Compose file on a virtual machine is a sufficient host. Kubernetes manifests exist for customers whose standards mandate them. The platform doesn't impose an orchestrator on organisations that don't run one.
Redundancy you can prove, not a percentage you must trust
Server-level high availability is really restart high availability, which makes it a software property, not an infrastructure purchase. The platform is built to survive its own death, in three tiers.
Restart-safe
Escalation deadlines live in the database, not in process timers. Any process may die at any instant with nothing lost, skipped or double-fired. A duress mid-escalation survives the restart and resumes at the right tier.
Two-instance-safe
Split-brain is treated as the normal case during a failover, not an exotic one. Every escalation tier is claimed with a conditional database update, so two machines running at once cannot double-escalate.
Honest health
Liveness and readiness are distinct signals; a process that is up but cannot reach its database says so. A source that cannot be read returns unavailable, never a plausible zero.
The restart, walked through
A duress is raised and the ladder starts; the deadline for the next tier is written to the database before anything else happens. Kill the process at the worst possible moment and nothing is owed to a timer that no longer exists. The next instance sweeps the deadlines and the escalation advances exactly where it left off.
Beneath it, a database standby is mandatory at every scale. A single-instance database under a duress workload is a configuration we refuse to deploy. Automatic failover is proven by drill, and backups run on a schedule, are encrypted at rest with AES-256, and are physical copies that preserve the tamper-evident audit chain byte for byte. Every backup carries an integrity manifest checked before any restore, and the restore path has been exercised end to end with the chain verified afterwards, because a backup that has never been restored is a hope, not a backup.
Deadlines live in the database, so a restart interrupts nothing.
Outbound-initiated only
The platform never asks your security team to open a door inward.
No inbound firewall rule
Every connection is initiated outbound over TLS. No inbound rule into the site network is required, so there's no listening service for an attacker to find from outside.
Enumerated egress
The full set of egress destinations is enumerated per deployment, so your firewall team can allow-list precisely rather than open broadly.
Local alarm path
Site equipment connects on the site LAN. The layers above a site can fail, disconnect or be decommissioned without an alarm losing its path to a human.
API-first, and honest about redelivery
If the API cannot perform a function, neither should the user interface. Everything the surfaces do runs through the same interfaces you can use.
- Versioned REST/JSON API with a generated OpenAPI 3.1 description. The documentation is produced from the interface, so it cannot drift from it.
- Server-sent event stream. Applications subscribe; they never poll.
- Webhooks, both directions. Outbound webhooks are HMAC-signed so the receiver can verify origin and integrity. Inbound webhooks are authenticated; anonymous ingest is not a supported configuration.
- Operations interfaces: syslog (RFC 5424), SNMP, and a metrics scrape endpoint for the monitoring stack you already run.
- One canonical event envelope. Every event carries identity, type, version, tenant, site, timestamps, causation and correlation. The same shape on every interface.
- Idempotent redelivery. Delivery is at-least-once and consumers are designed for it: a redelivered event is recognised, not double-processed.
- Graceful degradation, fixed shedding order. Under pressure the platform sheds analytics before operations. Duress ingest and fan-out are never shed.
Put the architecture in front of your infrastructure team
Bring your hypervisor, your firewall standards and your hardest questions. We will show you the failover drill, not a slide about it.