It starts with a Postgres database, and deepens from there. Branch it like code, fork a whole environment for any pull request, deploy the app that runs on it, and hand the work to an agent. One platform, from the database up.
$ 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
Every project begins with stock, isolated PostgreSQL on dedicated compute. Not a fork, not a rewrite. Your extensions, real psql, and real pg_dump just work. Continuous backups give you point-in-time recovery, proven by an automated weekly restore drill.
$ flicker database create app › provisioning Postgres … ready $ flicker ext enable vector › extension enabled · connect with a standard string $ psql "$DATABASE_URL" -c '\dx'
Fork a database with copy-on-write: a branch shares its parent's blocks until you change them, so even a large database forks quickly and stores only the diff. No logical dump, nothing copied up front. Reset re-forks from the parent, and you can fork from any branch, not just main. Idle branches scale to zero, so a spare branch costs almost nothing.
Describe your stack once. From then on, one call in CI forks the whole thing for a pull request: a copy-on-write Postgres branch, the deployed app, its own scoped secrets, and every dependent service, rewired to point at each other. Live in about a minute, and it tears itself down when the PR closes.
Its own database, app, secrets, and services. Break it, seed it, drop a table. Nothing else is touched, and prod's secrets never reach it.
One idempotent command per GitHub event. Re-runs converge instead of duplicating, so a retried job never makes a mess.
Every environment carries a TTL and reaps itself. Even if CI crashes, you never leak a preview database, a secret bundle, or its cost.
An environment holds more than data. It holds your secrets, in named scopes that inherit. Set a key once on a parent; override it on one child and only that child diverges. A preview or dev environment may never inherit from production, refused at write time. Restricted secrets are write-only, and every deploy seals an immutable bundle, so you always know exactly what config shipped.
Inheritance
12 keys resolved · sealed at cutover · audit of record
An app and a database in the same project auto-wire DATABASE_URL. You never set it. Cutover is a rolling update: the new version only takes traffic once it's up, so a failed release leaves the current one serving. Every deploy stamps its exact image in an immutable history you can roll back to. No nginx, no deploy YAML.
Read the docs: deploy lifecycle & rollbackBuilding
Dockerfile · build secrets
Release
release_command · migrations
Running
rolling cutover · new version up
Succeeded
https://foodfeed.app — live
Deploy a search engine, cache, or object store from a curated catalog. Flicker generates the credentials, provisions a persistent volume, and injects a canonical set of connection keys into your app. No URL to copy, no secret to paste. And they re-fork with every branch.
MEILI_URL · MEILI_MASTER_KEY
CLICKHOUSE_URL · USER · PASSWORD
QDRANT_URL · QDRANT_API_KEY
AMQP · management
persistent volume
MYSQL_URL · USER
dashboards · volume
17 in the catalog
Flicker Tickets are recursive work items with four states and named transitions, carrying append-only documents (contracts, review, release) and searchable memory across every ticket. So a person or an agent picks work up from the system of record instead of reconstructing it from chat.
Read the docs: the Tickets model$ flicker ticket create "Implement checkout" › created ticket #42 in backlog $ flicker ticket document write 42 task_contract › wrote task_contract v1 $ flicker memory search "checkout conflict" --json › source_class: current_document
First-party skills for Claude Code, Pi, and Codex run the delivery loop as automated workflows: plan, implement, test, release. Each step lands on a ticket as a versioned document, every decision searchable in memory, so the next run picks up from the record. /flicker-ship runs the whole loop autonomously within safety rails.
View the public skills on GitHubplan
contract
implement
branch · PR
test
review
release
merge
/flicker-ship runs every stage. Danger zones escalate to you.
› /flicker-ship 128 branch → PR #41 → review clean → tests green merged → deployed
Verify a sending domain with DKIM and SPF, then POST /mail/send from any app. No separate email provider to bolt on. Every message and its delivery state lands in one searchable log.
$ curl -s .../api/v1/mail/send \ -d from=noreply@acme.com -d to=jo@acme.com \ -d subject=Welcome -d text=Welcome › from noreply@acme.com (DKIM ok) › queued msg_8f3a1c … sent
Give any service a volume that survives every deploy and re-forks with a branch. Then point the assistant at your buckets, a git repo, or your project's tickets. Flicker embeds them into a private knowledge base and answers with hybrid retrieval (pgvector semantic search fused with Postgres full-text via Reciprocal Rank Fusion), grounded in your own content, not the model's guess.
Read the docs: the assistant & retrieval› How does branch reset keep the connection string working? hybrid search buckets · repo · tickets … 5 passages · RRF Reset re-forks the branch from its parent and rotates its endpoint credentials, so the same connection string keeps working, with no app change needed. grounded in branch.ex · env-secrets-and-connectivity.md
A single static binary runs the same commands on your laptop and in CI: branch a full environment with a TTL, deploy, set versioned secrets, toggle extensions. Idempotent, and a failed step exits non-zero, so a pipeline never leaks a preview or hides a failure.
Full CLI reference & getting startedon: pull_request steps: # full env for this PR — app + data + secrets, auto-expires - run: flicker branch ensure --ref pr-$PR --ttl 2h -y - run: ./test.sh # test against the branch - run: flicker deploy --from-local - run: flicker branch destroy --ref pr-$PR -y
Start with a database, branch a full environment for any pull request, deploy the app on it, and track the work in Tickets. One CLI or the dashboard.