DEV Community

Cover image for I'm 62 and I built a self-hosted AWS drift detector because I was tired of spreadsheets
ひとし 田畑
ひとし 田畑

Posted on

I'm 62 and I built a self-hosted AWS drift detector because I was tired of spreadsheets

#devops #terraform #showdev #aws

I came to programming late — I didn't get into this world until I was past
35, and I'm 62 now, still writing code every day. This is a "build in public"
post about a tool I just finished, and I'd genuinely love your feedback.

The itch

For years I watched infrastructure teams keep their AWS inventory in
spreadsheets. It always worked — right up until it didn't. Nobody had time to
keep it current, and every single one eventually drifted away from reality.
Middleware EOL was the same story: a hand-maintained list, no alerts, no
dashboard, quietly going stale.

One day I asked the obvious question: we have tfstate, we have boto3 — why are
we still doing this by hand?

What I built

SyncVey is a self-hosted web app that:

  • Inventories your AWS resources into a System → Environment → Asset ledger (EC2, ECS, Lambda, RDS, S3, ALB, VPC, EBS), scanned live via boto3/AssumeRole
  • Detects attribute-level drift between your tfstate and live AWS — including resources someone built by hand in the console that terraform plan never sees
  • Tracks the app/middleware layer per environment and flags end-of-life runtimes

The drift piece is the part I care about most. terraform plan only knows
about resources Terraform already manages. The thing that actually bites teams
is the resource someone spun up by hand in the console — plan is blind to it.
SyncVey diffs your tfstate against the live AWS state, so those show up too.

The stack (and why)

  • Django + htmx + Postgres — server-rendered, no SPA, no Node build step
  • MIT-licensed, no SaaS, no telemetry
  • One docker compose up and your data stays inside your own infrastructure 
git clone https://github.com/MR-TABATA/SyncVey
cd SyncVey
docker compose up
Enter fullscreen mode Exit fullscreen mode

I deliberately leaned on htmx because, for a tool someone has to deploy and
maintain themselves, "no frontend toolchain" matters more than a fancy client.

I'd love your honest take

It's AWS-only for now and very much a solo project, so I'm sure there are rough
edges. I'm not an AWS specialist — I deliberately leaned on things that don't
require me to be one: your tfstate and the live boto3 API as ground truth, all
open source so you can audit every call. If you know AWS better than I do (many
of you will), I'd love for you to tear into the scanner logic.

Does this solve a real problem for you? What's missing? What would stop you
from running it?

Top comments (0)