Argus

Sign in page. Uses Firebase Authentication.
Main admin dashboard. Here you can view the important stuff at a glance.
*cmd k* allows you to directly search instead of endless browsing. It also supports arrow keys and enter so no need for mouse ;)
We used Dokploy to deploy our application on a Digital Ocean Droplet using HTTPS secured by Let’s Encrypt.
Records page has search filters you can apply.
Each record has a full history log for maximum tracability.
Events are attached to records, here's where you can view all of them.
Employee dashboard view - record has intent message missing, you can update it directly in the dashboard.
Employee dashboard view - Explained records have intent documented.
Employee dashboard view - Resolved records no longer pose a threat, kept for posterity.
We used Digital Ocean to simulate the emergency manual fixes a data center engineer might make.
Argus in action: reviewing a Terraform deployment before it undoes an emergency fix.

Inspiration

NMC² asked us to help data center teams stay one step ahead of missed warnings, unclear handoffs, and the wrong information at the wrong time. When we talked at the sponsor fair, an NMC² engineer pointed us toward infrastructure as code (IaC). Digging in, we found one failure that hits all three: drift.

Drift happens when someone changes infrastructure outside of Terraform. The most dangerous case is an emergency fix: during an incident, an engineer fixes the problem by hand in the cloud console. The live system now works, but the Terraform code still describes the old, broken setup. At the next shift, an engineer runs a routine terraform apply, Terraform "corrects" the drift, and the outage comes right back. Engineering teams have written about exactly this, like Razorpay's post on Terraform drift.

A missed warning: the plan does show the change, but it looks like any other line in the diff. Nothing marks it as a live fix someone depended on.
An unclear handoff: the reason for the fix lives with the engineer who made it, in their head or a Slack thread, not with the next person on shift.
The wrong information at the wrong time: even when the reason is written down somewhere, it isn't in front of the engineer at the one moment it matters: right before they apply.

And when a deploy does fail, the team has to piece together who changed what, and why, after the fact.

This hit close to home. In our internships and team projects using Git, we've all opened a file and asked, "What is this, and why did someone change it?" Why a change was made can matter just as much as the change itself.

Drift detection tools can already tell you that something changed. We wanted to capture why, and make sure people had to acknowledge that before acting. So Argus doesn't just warn: it pauses the apply, shows the engineer why the fix was made, and requires them to decide what to do with it. Every apply that would undo a manual fix becomes a deliberate choice, recorded with a reason, so the team always knows it was intentional.

What it does

Argus sits between engineers and terraform apply. It records why each manual change was made, stops any deploy that would undo one, and keeps a shared history of every decision. Engineers use the argus command line tool and a web app; team leads use an admin view.

Catch the change. argus scan runs a read-only Terraform refresh and compares the live infrastructure with what Terraform expects. When it finds a manual change, like a firewall port opened by hand during an incident, it asks the engineer one question while it's fresh: why was this needed?
Hand it off. The web app shows the next engineer every open manual change with its reason, who reported it, and when it was detected. A change nobody explained is flagged as "Needs a reason" instead of being left blank.
Pause the apply. Engineers deploy with argus apply instead of terraform apply. Argus builds the real Terraform plan and checks it against every recorded change. If the plan would undo one, Terraform does not run. The engineer sees the change, how long ago it was made, the reason (or "No reason recorded"), and any earlier decisions about it.
Force a decision. The engineer must choose what happens, with a short rationale for anything other than cancelling:
- Keep: nothing is applied, and Argus prints the exact Terraform edit that would make the fix permanent.
- Revert: apply the reviewed plan and undo the change on purpose.
- Defer or cancel: apply nothing for now.
- Override: apply anyway, with the override recorded.

The decision is saved and tied to that exact plan before Terraform starts. If the plan changes, it needs a fresh review.

Record the outcome. Every scan, reason, decision and deploy result goes into an append-only history on Tiger Cloud, shared by the CLI and the web app. A deploy that dies halfway is shown as Unknown, never Success.
Review and investigate. Admins get an overview of open changes, missing reasons and recent deploy outcomes, a timeline for each record (change, then reason, then decision, then outcome), and a ⌘K palette to jump to any record, resource or person. People are a filter for investigating, never a score.
Close the loop. A record only closes after argus recheck proves the live infrastructure, Terraform state and code agree again.

Argus fails safe. If it can't verify a plan, it says VERIFICATION UNAVAILABLE instead of reporting "no conflicts", and it never applies anything a human didn't explicitly choose.

How we built it

Backend: Python and FastAPI. The argus CLI is the only part that runs Terraform; the web app never does.
Shared history: Tiger Cloud (PostgreSQL/TimescaleDB) holds an append-only event history, so the CLI, the API and every engineer see one timeline. SQLite is used for local development.
Detection: a read-only Terraform refresh shows what changed in the live infrastructure; a normal Terraform plan shows what the next deploy would do. Argus matches the two to find deploys that would undo a manual change.
Infrastructure: a real DigitalOcean firewall managed by Terraform. Sanitized captures from real runs are replayed as tests.
Frontend: React, TypeScript and Vite, designed in Claude around NMC²'s black, white and blue, with separate employee and admin views.
Identity: Firebase Google sign-in, with admin access enforced on the server.
Deployment: Docker and Dokploy, live at argus.artificial.cloud.
Quality: test-first on both sides, plus docs tests that fail if our docs claim more than the code does.

Try it live at argus.artificial.cloud: sign in with any Google account to see the engineer view. The admin view is limited to our team accounts.

Challenges we ran into

Real Terraform is messier than the docs. The DigitalOcean provider stores some empty lists as null in state but [] live, so every record looked drifted forever. We only caught it by testing against real infrastructure.
Getting the UI right took iteration. Claude Code is great at writing code, but the first draft of each UI element was always a little off, so we kept refining the design and giving it feedback until it matched what we wanted.
Terraform and DigitalOcean were new to us. Setting up Terraform and connecting it to DigitalOcean took a lot of time and effort.

Accomplishments that we're proud of

The full loop works! argus scan detects manual changes and asks why they were made, and argus apply stops any deploy that would undo one until the engineer makes an informed decision.
The UI looks great. We matched it closely to NMC²'s look and theme.
The ⌘K command palette makes finding any record, resource or person fast and feels great to use.
We built all of this in a day with only two people!

What we learned

We learned a lot. Infrastructure as code was new to both of us, and neither of us had used Terraform before. We learned about the problems infrastructure and operations teams face, like drift, how the different Terraform commands work, and exactly where drift comes in. Most of all, we learned that knowing what changed isn't enough: the reason behind a change is what the next person actually needs.

What's next for Argus

More resource types beyond firewall rules.
A CI gate so the guarded path can't be skipped.
Gemini-drafted shift handoff notes that cite the records they used and can never approve anything.
Linking incidents to deploys to find which changes keep causing downtime, with humans reviewing every finding.