From Planning to Production

Overview

Your team and your agents always have the full story of your product development lifecycle. Fly captures decisions, releases, deployments, and distributions as you work.

flowchart LR
    A[Plan & Develop] --> B[Release]
    B --> C[Deploy to Runtime]
    B --> D[Distribute]

Plan and Develop — capture context as you work

As your team plans and develops with coding agents, Fly turns the decisions you make into shared context for every coding agent on your team. Your product builds up a layer of accumulated knowledge: the trade-offs, the approaches, the reasoning behind your choices. Every agent on your team draws from it.

From the next coding session forward, every agent on your team has the new context. Whether they’re working on auth, payments, or anything else, they draw from the decisions your team just made.

This context lives in Decision Records, attached to the releases they shaped.

How decisions become Decision Records

Fly captures your coding conversations in the background. When a release is created, Fly reviews the conversations that led up to it and identifies the substantive decisions: trade-offs weighed, approaches debated, choices made. Each becomes a Decision Record attached to the release.

They emerge from the work you were already doing.

See Decision Records → for the entity model.

Release — every push tells a story

Every push that produces an artifact creates a Fly release. The release captures everything about what shipped, in a form your team and your agents can query later.

What a release contains, and why

  • The artifact — the package, image, or binary you produced
  • Source links (PRs, commits, author) — so the release traces back to its code origins
  • AI-generated summary — a plain-language description that enables semantic search later
  • Decision Records — links to the planning conversations that shaped this release
  • Workflow run — the CI run or terminal command that produced it, for full provenance

Each piece does a lifecycle job. Source links anchor the release to its code. The summary makes it searchable. Decision Records carry the why. The workflow run is the audit trail.

How releases are triggered

Once jfrog/fly-action@v1 is in your workflow, every push that produces an artifact creates a release. Most production releases run through CI.

Search by content, not by version

The releases you accumulate become a searchable history. Prompt your coding agent or browse in Fly Web. Ask in plain language:

  • “Find the release where I fixed the login bug.”
  • “What’s the latest release with auth changes?”
  • “Show me all releases from payment-service this week.”

Fly matches semantically against PR titles, commit messages, the AI summary, and linked Decision Records. You don’t need to remember version numbers.

See Releases → for the entity model, status states, and management operations.

Deploy to Runtime — know what’s running

When a release lands in a runtime environment, Fly captures it as a deployment event. You stop guessing what’s running and start asking.

What’s a deployment event, and why it matters

A deployment event is created when a release lands in a connected runtime environment. The event captures:

  • The image — exactly which tag was pulled
  • The environment — which runtime (staging, production, etc.)
  • The release — links back to the Fly release that produced the image
  • When — timestamp of the pull
  • Who — the user or system that triggered the deploy

Each event ties a running container back to the release record, and through the release to the PRs, commits, and decisions behind it.

How deployments are tracked

Tracking is automatic once your runtime environment is connected. You don’t instrument your CD or add steps. The mechanism: image pulls from your Fly Registry leave a server-side trace, and Fly correlates each pull to a release.

This means your existing CD keeps working: kubectl apply, GitOps, ArgoCD, Helm. Whatever pulls an image gets tracked.

Multi-environment patterns

Connect each runtime environment to Fly (e.g. staging, production, eu-prod). Each gets its own deployment history. For any release, you see:

  • Which environments it has reached
  • When it landed in each one
  • Who deployed it
  • What was previously running there

Ask “is the auth fix live in production?” or “show me deployments to staging in the last 24 hours.”

See Runtime Environments → for the environment model and connection setup.

Distribute — reach your customers

Distribute a release to make it publicly accessible outside your team. Fly keeps a full audit trail of who distributed what, when.

What’s in the audit trail, and why

For every distribution event, Fly captures:

  • Who distributed it — the user or system that triggered the distribution
  • What — the release and artifact distributed
  • When — timestamp
  • Public access state — whether the version is currently public

The audit trail lets compliance, security, and product teams answer who got what, and when. Public access can be revoked; the revocation is in the audit trail too.

How to distribute

In your CI. Add a distribute step after your build step. Every successful push distributes the release automatically. See CI → for a full workflow example.

Via your coding agent. Ask “Distribute this version publicly.”

In Fly Web. Open a release, select the artifact you want to distribute, and click Distribute.

See Distribution → for distribution targets, public URL configuration, and management.

Next steps