How Churchill works

You do not need to know how Churchill enforces integrity under the hood to operate it well. You do need to recognize the handful of pieces that make up a deployment and understand the lifecycle a host goes through from first pairing to steady-state protection. This page covers both.

The pieces

Churchill is made up of a few cooperating components. Some run on each protected host, one runs off-host as your control plane, and one is the console you work in.

Component	Where it runs	What it does for you
Protected application	On the host	The workload you want to keep safe. A lightweight sentinel watches it from the inside while it runs.
In-process sentinel	Inside the protected application	Watches the application from within its own memory for signs of tampering and can stop it instantly if something is wrong.
Host sentinel	On the host	The on-host guardian. Watches the host and the protected process from the outside and can terminate a compromised process from outside it.
chrlctl (Churchill Host CLI)	On the host	The host-side command-line tool. It pairs the host with your control plane and discovers the application you want to protect, so an operator can review the result before anything deploys.
Control plane	Off-host	Collects heartbeats and evidence from every host, holds each host’s approved baseline, publishes signed protection bundles, and dispatches lockdown and recovery commands.
Churchill dashboard	Your browser	The operator console where you enroll hosts, register applications, watch the fleet, review evidence and lockdowns, and manage governance.

A useful way to think about it: the protected application and its in-process sentinel are the workload being defended, the host sentinel is the guard standing next to it on the same host, the control plane is the off-host headquarters that every guard reports to, and the dashboard is your window into all of it.

Two sentinels, watching each other

A protected host is defended by two sentinels at once: the in-process sentinel inside the application, and the host sentinel outside it. They monitor each other as well as the application, so neither can be quietly disabled without the other noticing.

How a host comes under protection

Bringing a host under protection is two distinct stages, enrollment and deployment, with a CAB approval gate between them. Pairing a host does not by itself start protection. Nothing deploys until the CAB has approved what was discovered.

1. Issue a one-time provisioning code. In the dashboard, the Register application wizard issues a single-use code for the host you want to bring in. See Onboarding.

2. Run chrlctl on the host. A host administrator runs chrlctl register with the code. On a terminal chrlctl walks them through the applications it discovered, the files to monitor, and whether to record interactive logins, then registers nothing until they confirm a summary. The host pairs outbound and generates its own identity key. Churchill never dials into your host. chrlctl then uploads the configuration (the service unit, the binary hash, and the paths to monitor) for review.

3. Review and approve. Back in the dashboard, you review the discovered configuration and submit it as a change request. The CAB approves it before anything deploys. No protection reaches a host on a single person’s say-so. See The CAB.

4. Protection deploys on the next poll. After approval, the host picks up a signed protection bundle on its next poll. The poller runs continuously and polls about every 15 seconds, so the wait is short. It verifies every signature and hash in the bundle, then loads it into a read-only in-memory runtime. Protection starts there. The configuration the CAB approved is the enforced baseline. The runtime’s memory baselines lock the first time the application reports in.

What lands on disk

Enrollment writes a small set of persistent artifacts to the host: its identity, its certificate, the tenant it joined, a copy of chrlctl itself, and the poller service. The protection runtime itself lives only in memory. Nothing of it survives a reboot.

The ongoing loop

Once protection is live, the same loop runs for as long as the host is enrolled:

• Heartbeats. The host checks in with the control plane about every half-second. You see this as live health across the dashboard. See the Dashboard overview.
• Continuous integrity monitoring. Both sentinels keep measuring the application, the host, and each other against the approved baseline.
• Kill and lockdown on verified compromise. If the protected process drifts from its baseline, or either sentinel detects tampering, Churchill terminates the affected process at once. It places the host into lockdown so the host will not silently restart a compromised workload. Lockdown is held by the control plane, not by a file on the host, so a reboot does not clear it. You review the evidence. Once you are satisfied, you unlock the host from the dashboard with a reason. No host access is needed. See Lockdowns.

Where to go next

• To bring a host through this lifecycle yourself, start with Onboarding.
• To learn the console you will do it from, see the Dashboard overview.
• For definitions of the terms used above, see the Glossary.