Infrastructure as code answers build time, not runtime
If your servers are provisioned from code, you already have the thing most teams lack: a defined intended state. That solves configuration at build time and makes rebuilds cheap.
It does not tell you that someone SSH-ed in during an incident and left a change behind, that a CVE was published last week against a package your image pinned, or that a process is running from a binary deleted from disk. Those are runtime conditions, and a manifest describing intent cannot detect them.
The reproducibility does help enormously in response: when rebuilding is a pipeline run rather than a project, the fastest remediation for a compromised host is often to replace it. Monitoring is what tells you which host and when.
Drift is the normal case, not an exception
Configuration drift is usually described as a hygiene problem. From a security perspective it is a detection problem: the gap between what your code says the server is and what it actually is now is exactly where compromise hides.
The changes that matter are small and quiet: password authentication re-enabled in an sshd drop-in during a debugging session, a key added to authorized_keys, a firewall rule loosened at 2am and never reverted, a package installed by hand outside the manifest.
File integrity monitoring across the paths where those changes land turns drift from something you discover at the next rebuild into something you see the day it happens.
Containers do not remove the host
Running workloads in containers changes what is on the host but does not remove the host, and the host is still attacked. SSH is still exposed, the kernel and the container runtime still carry CVEs, and the Docker daemon still publishes ports.
The Docker port behaviour is worth singling out because it defeats a firewall people believe is protecting them: published container ports are handled in the DOCKER chain, evaluated before UFW rules, so a port closed in your firewall configuration can still be reachable. Monitoring what is actually listening beats trusting the configuration.
Automation with a rollback, which is the part that matters
Teams comfortable with automation are usually the ones most sceptical of automated remediation, and correctly so: an automatic action that breaks production at 3am is worse than the alert it replaced.
The design that makes it acceptable is bounded blast radius plus verification. Blocking an attacking address is reversible and runs automatically. Deeper remediation depends on the per-server mode, and anything potentially disruptive requires approval regardless. When a fix does run automatically, the result is verified and the change is rolled back on its own if a service broke, with an email explaining what happened.
Your own servers and admin addresses are exempt from blocking, so the automation cannot cut off your access during an incident.
Where it fits alongside what you already run
It is not a metrics or APM system and does not replace Prometheus, Grafana or your logging stack. Those answer whether the service is healthy and fast. This answers whether it is compromised, which is a different question that uptime graphs do not surface.
It is also not a SIEM. If you already run one and have someone tuning it, you have this covered differently. The trade here is a narrower, Linux-shaped scope that arrives tuned and acts by default, without a platform to operate.