Dev Log #2 - From Scaffolding to First Telemetry

Rizzy65 — Fri, 24 Oct 2025 06:46:35 +0000

If Dev Log #1 was about laying bricks, this one is about seeing the first lights turn on (and as a dev, it feels good.) Mirage/Apate went from “neatly stacked parts” to “a system that actually notices and remembers what touches it.” It’s still early to call it alive, but it’s real—and that’s a good feeling.

TL;DR

Shipped: working backbone (API + SSH/HTTP emulators), data persistence (DB + Redis), and a CI that has my back.
First telemetry: login attempts, HTTP pokes, and early session traces.
Lesson: real signals beat perfect plans—ship the simplest believable thing, then iterate.
Next: smoothing the emulators’ “personality,” better dashboards, and a tiny predictive prototype

What changed since Log #1

The API has a heartbeat. You can browse the docs locally (Swagger UI) and poke at endpoints without spelunking through code.
SSH and HTTP emulators are alive. They respond, they log, and they do it in a way that feels “real enough” to keep curious hands around a bit longer.
Data is sticky. Sessions, attempts, and a basic threat score now land in a database, with Redis helping keep things snappy.
The boring-but-critical stuff is there: Docker to run it all, iptables to keep it contained, and CI to tell me when I broke something.

In short: it’s not just a blueprint—it’s a house with lights, doors, and a guestbook, that forgets everything after a while, But I am working on it.

A tiny demo (60 seconds)

Start it up (Docker makes this painless).
Visit the API docs in your browser.
Trigger a simple request to see it flow through.

# bring services up (example)
docker compose up -d

# check API is alive
curl -s http://localhost:8000/health

# explore the interactive docs
# open http://localhost:8000/docs

What you should notice:

Health endpoint is up
Docs are browsable
New events show up as you interact with the emulators

Design notes, without the PhD

Start with “believable enough.” If the emulators feel roughly like a real box, attackers will stay long enough to teach us something.
Keep the core tight. FastAPI for orchestration, Rust for fast/precise network handling, Redis/SQL for state. Fewer moving parts = fewer surprises.
Observe first, outsmart later. The “cognitive” layers will come, but the best training data is real behavior—so step one is to listen well.

What didn’t work (and what I changed)

I tried to over-script the SSH conversation early on. It felt brittle. I pared it back to a realistic baseline, then made room to layer nuance later.
I flirted with Postgres too soon. Switched to a simpler default (SQLite) for local flow, kept the door open for Postgres when it earns its keep.
I wanted dashboards on day one. Reality: get clean events first; pretty plots after. The data is now solid, so charts are next.

What’s next

Make the emulators more “human”: better prompts, more natural delays, fewer tells.
Dashboards that make sense at a glance (Grafana first, then iterate).
A tiny predictive experiment off to the side: can a simple model guess the next command on a toy dataset? Not production—just curiosity with a yardstick.
Safer defaults and more guardrails as I harden the container boundaries.

If you’ve read this far

Thanks. Building Mirage/Apate feels a bit like putting together a stage play: sets, lights, and a story that’s convincing enough for the audience to stay. The first claps (telemetry) are in. Now it’s about deepening the act—slowly, carefully, and with a smile. Hopefully, my drive for this lives on to finish the play.

Repo: Apate (GitHub)
Docs (local when running): Swagger UI
Previous: Dev Log #1 — Field notes from the first brick

Dev Log #1 — Mirage / Apate: Field Notes from the First Brick

Rizzy65 — Sun, 28 Sep 2025 13:57:09 +0000

We spun up the first Mirage container. It looked cocky in docker ps, even served a clean 200. We thought: hell yeah, prod vibes.

Then someone hit the DB. Brick wall. Container “running,” but the service was a wax statue. Lesson #1: process alive ≠ system alive.

Day 0 — Naive boot

What we thought:

Simple ASGI app, SQLite, Alembic migrations.
Compose to glue it, nothing fancy.

What happened:

DB init blocked startup. Import-time schema creation froze everything.
Logs filled with OperationalError.
Container alive, endpoints dead.

Patch:

Lazy DB init, async startup, short timeouts.
Service now boots instantly, even if DB ghosts us.

Caveat: we learned fast—DB fallback isn’t free. Our in-memory SQLite behaves nothing like Postgres. Attackers probing concurrency, types, or isolation will sniff the toy. For now, it’s fine for dev loops, but TODO: move to WAL-backed SQLite with jitter, or a lightweight Postgres sidecar, so Mirage doesn’t leak “cheap decoy.”

Persistence discipline

What we tried:

SQLite file for dev, Postgres later.

Pain:

File collisions on container restart.
Migrations stomping each other, state corruption.

Patch:

Async SQLAlchemy for proper async flow.
Alembic migrations gated behind APATE_USE_ALEMBIC.
Rudimentary file lock to avoid racey migrations.

Caveat: file lock is a band-aid. Real fix: advisory locks in Postgres (later), or one-shot init jobs in Compose/K8s. Note for future self: never trust humans to “just remember the flag.”

Surface tightening

Favicon probes spammed 404 logs → return 204.
Added env-driven CORS.
Sensitive routes gated.

TODOs we spotted mid-flight:

Handle HEAD/OPTIONS consistently.
Add robots.txt + a boring 1x1 favicon instead of “nothing.”
Rate limiting + small randomized latency on select routes, so we don’t look “too perfect.”

Observability, but noisy on purpose

Before: dead silent when things broke.

Now:

/metrics with Prometheus counters (requests, latencies, DB fallback count).
Webhook alerts with dedup/backoff.
Metrics for alert failures themselves.

Self-own: right now, degraded mode leaks via the public health probe (it literally says “fallback engaged”). That’s a fingerprint. Fix queued: external health always boringly “OK,” internal metrics carry the truth.

Testing loop

What we had: slow, flaky tests with external deps.
What we have: 53 async tests run in ~0.5s in-process with ASGI.
What we still need: property-based tests for degraded paths (DB flaps mid-request, migration lock races).

Early wins

Deterministic startup.
Sub-second tests.
Real metrics instead of vibes.

TODOs and risks we logged for later

DB realism: WAL-backed SQLite + jitter, or Postgres-lite sidecar.
Health signals: split readiness/liveness; external = opaque, internal = honest.
Migrations: kill the file lock, replace with advisory locks or init jobs.
Surface polish: HEAD/OPTIONS, robots.txt, rate limiting, fake latency.
Observability polish: structured logs with request IDs, Prometheus histograms + exemplars, maybe traces.
CI gates: ruff, mypy, bandit, pip-audit, safety; pinned deps; multi-arch builds; distroless images.
Config: doc all env vars (DB URL, fallback toggles, alembic flag, origins, alerts).

Closing thought

Honeypots don’t have to be perfect, but they do have to be believable. Right now Mirage boots, degrades, and talks enough to fool a casual scan. But any serious fingerprint will still smell the shortcuts.

The plan: brick it less, make failure louder, make the illusion tighter.

Prod or bait? If they have to stop and wonder, Mirage did its job.

You can check the progress of my work in Github Apate

Or just myself at Rizzy1857

Any and every comment or contribution to make it better will be appreciated.

DEV Community: Rizzy65