An experiment in autonomous engineering
Cloud coding agents work in sandboxes: clone the repo, hope for the best. That holds for simple projects and breaks on real ones. Flicker forks your entire environment — app, database, backing services, secrets — into a true testing environment, then feeds the agent the context it needs to ship like your team would.
$ flicker branch ensure --ref pr-241 --ttl 2h › forking Postgres from main … done › resolving env preview/pr-241 … 12 secrets › rewiring DATABASE_URL · MEILI_URL · S3_ENDPOINT › deploying app … running Environment "pr-241" live → https://foodfeed-pr-241.flickercloud.com reaps in 2h00m
The industry's answer to agents in the cloud is a sandbox: an isolated box with a clone of your repo. That's short-sighted. Real products aren't a repo — they're a running app, a database full of production-shaped data, a search index, a time-series store, a sibling service the app calls. An agent that can't stand that up can't actually run your code, so it can't actually verify its work.
The sandbox
The environment fork
Describe your stack once. From then on, one call forks the whole thing for a branch, a pull request, or an agent run: a copy-on-write Postgres branch, the deployed app, its own scoped secrets, and every dependent service, rewired to point at each other. Break it, seed it, drop a table — nothing else is touched, and it tears itself down on a TTL.
Its own database, app, secrets, and services. An agent can be reckless here, and prod's secrets never reach it — refused at write time.
Copy-on-write: a fork shares its parent's blocks until they diverge, so even a large database forks in under a minute and stores only the diff. Idle forks scale to zero.
One idempotent command, re-runs converge, and every environment carries a TTL and reaps itself. A crashed run never leaks a database or its cost.
Anatomy of a fork
The Postgres branch is a copy-on-write clone at the storage layer: it shares its parent's blocks and stores only what diverges. Backing services with persistent volumes — your search index, your queue — fork the same way, so the environment starts with real, production-shaped data.
Config lives in named environment scopes that inherit: set a key once on a parent, override it on one child. The fork gets its own resolved scope, and a preview or dev environment can never inherit from production — refused at write time, not caught in review.
Managed connection keys — DATABASE_URL, MEILI_URL, S3_ENDPOINT — are regenerated with fresh credentials so every piece points at its forked sibling, never back at prod. Nothing is copied by hand, so nothing points at the wrong place.
The app rolls out into the fork with the branch's code and sealed config, and gets its own URL. An agent — or you — can now exercise the change end to end against the whole stack, then let the TTL reap it.
A real environment lets an agent verify its work. To do the right work, it needs what your team knows — and a queue of work worth doing. Tickets are the intake, and anyone can file them: your users through suggestions, your team, or the agents themselves. From there, agentic RAG assembles each run's context — the ticket, your business documents, the codebase, and the memory of every run before — and a standardized agent config makes sure every agent plays by your rules.
every phase leaves a durable trace · gates pause for a person, then the line keeps moving
One command wires a feedback endpoint into your deployed app, so bug reports and feature requests from real users land in a project inbox — screenshot attached, near-duplicates merged instead of piling up. Triage groups them into real tickets, links every report to the ticket that resolves it, and writes the reporter-facing answer. The factory's intake is your actual users.
Work lives as recursive tickets with append-only documents — contracts, plans, review, release evidence — and searchable memory across all of it. Users file them through suggestions, teammates file them directly, and agents file them for each other. Whoever wrote it, an agent picks work up from the system of record, not from a chat transcript.
A context window is small; what your company knows is not. Agentic RAG is how the factory bridges that — not a one-shot lookup, but an agent that searches, reads, and follows the links between tickets, business documents in your buckets, and the codebase until it has what the task needs. Hybrid retrieval underneath — semantic search fused with full-text — and honest results: a superseded decision comes back marked historical with what replaced it, never passed off as current.
And it isn't only for agent runs: chat with it directly to ask what your own org knows, or expose it as an API and put a grounded assistant inside your product.
Read the docs: retrievalEvery repo grows its own AGENTS.md, CLAUDE.md, and cursor rules — hand-written, drifting, contradicting each other. Flicker replaces that with one versioned org library of rules, skills, and tool specs. Compose profiles from it, select one per repo or per person, and flicker harness sync renders it into whatever each agent actually reads — a generated AGENTS.md, Claude Code, Codex, and more. Change a rule once and every agent in the org — not just the devs' favorite — follows your business guidelines on its next run.
Read the docs: agent config› "Search ignores typos" — a user, from your app › suggestion #118 open · screenshot attached · duplicate: false $ /flicker-triage › 7 open reports → 2 groups → ticket #129 "tolerate typos in search" › #118 accepted · linked to #129 · reply drafted for the reporter
$ flicker memory search "checkout conflict" --json › #42 task_contract v3 · current › #31 decision "single checkout worker" · historical → #42 $ flicker harness sync › rendered AGENTS.md · 14 rules · 6 skills
› What did we decide about the checkout flow? hybrid search tickets · docs · repo … 5 passages One worker owns the checkout transaction; the earlier per-cart lock was superseded in #42. grounded in #42 task_contract · checkout.ex
First-party skills for Claude Code, Pi, and Codex run the delivery loop — plan, implement, test, release — against a real environment, with real context. Each step lands on a ticket as a versioned document, so the next run (human or agent) picks up from the record. /flicker-ship runs the whole loop autonomously within safety rails; danger zones escalate to you.
View the public skills on GitHubplan
contract
implement
branch · PR
test
real env
release
merge
Every stage verified against a forked environment, not a sandbox.
› /flicker-ship 128 branch → PR #41 → env forked → review clean → tests green merged → deployed
Forking an environment only works if the platform runs the environment. So Flicker is also real infrastructure — built as the means to the end above, not as another cloud to sell you.
Stock, isolated PostgreSQL with your extensions, real psql and pg_dump, continuous backups, and a weekly restore drill that proves point-in-time recovery against real data.
Rolling, health-gated cutovers with an immutable image history and one-click rollback. DATABASE_URL is wired automatically — you never set it.
Deploy lifecycle & rollbackInheriting environment scopes, write-only restricted keys, and an immutable SecretBundle sealed at every deploy. A preview can never inherit production.
Meilisearch, ClickHouse, Qdrant, RabbitMQ, and more from a curated catalog — credentials generated, volumes provisioned, connection keys injected. They re-fork with every branch.
Verify a domain with DKIM and SPF, then POST /mail/send from any app. Every message and its delivery state in one searchable log.
A single static binary runs the same idempotent commands on your laptop, in CI, and inside an agent loop. A failed step exits non-zero, so nothing hides a failure.
Full CLI referenceNone of this is a secret — the backend exists to run the experiment, not to be one. Workloads run on dedicated hardware, not marked-up hyperscaler compute, orchestrated by Kubernetes with the scheduler owning placement.
bare metal, owned, not resold cloud
declarative data plane · rolling cutovers
operator-managed Postgres clusters
what makes a fork ≈ 0 bytes
control plane · LiveView dashboard
one static CLI binary, laptop and CI
TLS terminate · wake branches on connect
edge relay → cell, no exposed ports
hybrid retrieval, in Postgres
Every org gets a public showcase page: publish your projects, tell the story of what they do, and point people at the live thing — running on the same platform that built it. The factory ends where software should: in front of users.
Bring an app, fork its whole environment, and hand real work to an agent that can actually verify what it built. That's the point — everything else is plumbing. Much of this runs in production today; the rest is the vision, being built in the open on the platform itself.