Site lockdown

The same host also carries Host containment

The host you enrol here is the same host Host containment arms on — one enrolment, two independent protections. Site lockdown puts your web server into read-only mode through its proxy; Host containment can kill the process attributed to that host's own CRITICAL ransomware alert and isolate its network. Each is armed, disarmed, priced, and consented separately; neither turns the other on.

What it protects — and what it does not

Site lockdown protects HTTP traffic through the proxy you installed the template on, nothing more. When the flag file is present, the proxy serves a static 503 page for every route except one operator IP you allow-list; when it is absent, traffic passes through normally.

• SSH, databases, and any other listener on the host are untouched — lockdown does not firewall the box, it changes what one proxy answers with.
• An attacker who already has root on the host can delete the flag file directly and undo a lock without going through Sentinelleai at all — this is a response tool for a proxy-level incident, not a guarantee against a fully compromised host.
• This is not the platform's own lockdown — see Lockdown & inline protection for what protects Sentinelleai itself. Site lockdown protects a server you run; that page describes ours.

What you need

• The Sentinelleai host agent installed on the server in front of the site.
• Caddy or nginx as the reverse proxy in front of that site.
• One operator IP you want to keep reaching the site during a lock.
• A flag path on a local disk the agent can create and remove (default /var/lib/sentinelle/lockdown.flag).

Enrol, install, verify, rehearse, arm

1. 1

   Enrol the host

   Give the host a label, a flag path, and which proxy it runs. Enrolling generates a dedicated agent key for this one host, shown exactly once — copy it into the agent's config immediately, it is never shown again.
2. 2

   Install the proxy template

   Apply the matching template from ops/site-lockdown/<caddy|nginx>: it adds the flag-file check and the allow-listed operator IP in front of your existing site config.
3. 3

   Verify

   Queue a verification pass. The agent runs four passive checks (V1–V4) on its next poll and reports them back — nothing here writes the flag file.
4. 4

   Rehearse

   With an acknowledgement, queue a rehearsal: the site goes read-only through the proxy for a few seconds while the agent confirms the flag file is actually honoured, then removes it automatically. This is the one step that is deliberately disruptive, on purpose, before you ever need the real thing under pressure.
5. 5

   Arm

   Once verified and rehearsed, arm the host. Arming does not lock anything by itself — it only makes the host eligible to receive an Engage command (and, if enabled, its own local trigger).

The four verification checks

V1–V4 are passive and self-reported by the agent on its next poll — nothing about verification writes the flag file or touches live traffic. A check the agent could not resolve reads unknown, never rounded up to a pass.

Verification passes only when V1, V2 and V3 all read pass. V4 is reported alongside them as supporting evidence that the template was actually applied, but a proxy config the agent cannot introspect does not by itself fail verification.

What can engage a lock

• Your Engage command. From this page, with a reason and an acknowledgement. The agent picks it up on its next poll (roughly every 30 seconds by default) and writes the flag file.
• The agent's own local trigger — optional, off by default. If you turn it on for a host, that host's own CRITICAL ransomware alert engages lockdown on the same host without waiting for you to click anything. Turning it off requires the same reason-and-acknowledgement step as any other action that reduces a protection.

After a lock

Visitors get a 503 with a Retry-After header instead of your site; the allow-listed operator IP still reaches it normally. You investigate on your own time — the lock does not expire and nothing about it tries to fix anything for you. When you are ready, you release it, either from here or with rm of the flag file directly over SSH. Every step — engage, release, verify, rehearse, arm, disarm, the local trigger — is recorded with receipts in the same append-only ledger every other protective action uses; see the evidence ledger.

Engaging a lock also triggers the customer report flow: a short notice goes out right away, and the full signed report follows after a hold window, with the consent you signed for Site lockdown attached to it. See Reports sent to you for the notice, the hold, and how an operator can add a note or skip a delivery.

Consent at subscription

Subscribing to Site lockdown requires signing a consent the first time, the same as Auto-pause: a typed phrase confirming you read the instructions on this page, recorded against your identity before checkout will proceed. See Plans & billing for what is recorded and where.

Pricing structure

Site lockdown is billed per host per month, sold as a standalone add-on — it is not included in the general bundle, because it can take your own production site offline on your behalf, so enrolling it is always an explicit, deliberate choice. See pricing for current figures.

What it stops short of

• It protects HTTP through the one proxy you installed the template on — not SSH, not a database, not any other listener on the host.
• Root access on the host can remove the flag file directly, bypassing Sentinelleai entirely.
• It never releases a lock on its own — no auto-expiry, no automatic recovery. That decision is always yours.
• A rehearsal makes the real site read-only for a few seconds by design, so you see the actual behaviour before you ever need it for real.