Alfred BuilderOps Console

Alfred is an operational assistant for solo builders. A one-person product still runs on a cloud account, a CI, two app stores, an error tracker and a database - and nobody is watching all of them at once. Alfred connects to each one read-only, discovers what is actually running, proposes the alerts the builder never set up, and evaluates them every five minutes.

"Built for solo builders - not enterprises."

No AWS or Azure SDK: AWS requests are signed with a hand-written SigV4 signer, which keeps the dependency surface of a credential-handling app small.

One Pooled App, Two Data Planes

Two Provider Contracts

Clouds implement one CloudProvider interface - listComputeServices, listVirtualMachines, listManagedDatabases, listRegistries, getCostBreakdown, listBudgets, health - so the Infra pages are cloud-agnostic. SaaS tools implement a single SaaSConnector.fetch(), registered in one index. Adding an integration is one module, not a new page.

src/
├── app/(app)/          # console pages: infra, mobile, observability, app-ops, alerts
├── app/api/            # auth, health, cron/{evaluate,cost-snapshot,demo-refresh}
├── lib/cloud/          # CloudProvider: gcp, aws (SigV4), azure + discovery + token minting
├── lib/connectors/     # 17 SaaS connectors behind one SaaSConnector contract
├── lib/appdata/        # read-only reader for the builder's own Postgres
├── lib/vault/          # envelope encryption, Cloud KMS wrap/unwrap
├── lib/alerts/         # rules, metrics, engine, delivery channels, uptime probe
└── lib/db/, lib/tenant/  # tenant-scoped Prisma client + AsyncLocalStorage context

Alfred is one pooled application with isolated data. Isolation is enforced by the database, not by remembering a WHERE clause:

Envelope Encryption

The AAD binding means a ciphertext copied into another tenant's row will not decrypt. The vault table itself sits under forced RLS.

For GCP and AWS the builder grants access instead of pasting a key. Alfred mints short-lived credentials on demand, so there is no long-lived cloud key to steal.

20 read-only integrations, plus a read-only connection to the app's own database:

The App Data Plane

The builder's own Postgres is read through a connection string and a schema mapping - no SDK and no change to the builder's app. Each read opens a fresh client inside BEGIN TRANSACTION READ ONLY, with 8-second statement and connect timeouts, and re-runs the SSRF check on the target host. Identifiers are mapped and quoted, values are always parameterized, and every list is capped at 500 rows.

From Scan to Proposed Rules

Only rules the engine can actually evaluate are ever proposed - a checkbox never promises a check that doesn't exist.

The Engine

Each tenant is evaluated under a Postgres advisory lock, so overlapping runs cannot double-fire. Notifications go out only after the transaction commits, to Telegram and the in-app feed.

Testing

257 passing tests in 45 files (Vitest, run Sep 27, 2026). Three more are integration tests against a live Postgres; they skip themselves when none is reachable, so the suite is green on any machine without Docker. Typecheck, lint and the full suite form the gate before every release, and a release is an explicit, owner-approved step - pushing code never deploys it.