Production lifecycle

A draft is not the app coworkers use.

Garden treats agent-generated code as a change proposal. Source is committed, repaired against a release contract, built into a private draft, and made live only through an explicit publish action.

Audience: app owners and operatorsScope: current pilotUpdated: August 4, 2026

The lifecycle, step by step

1. Bring in source

The owner uploads or connects an existing application. Garden creates or uses a Git-backed application record; saving source does not make a release.

2. Repair and explain

The workbench agent checks the application against Garden's release contract, makes reviewable commits, and attaches a repair report that records checks and remaining exposures.

3. Create a private draft

A draft captures an exact commit and an immutable runtime specification before launch. It receives a private draft URL. If a live release already exists, it continues serving coworkers unchanged.

4. Publish deliberately

The owner publishes an identified draft. Garden changes the live release only after the publish succeeds and records who performed the action.

5. Change without overwriting live

A later edit produces another draft. The current live release remains available while the owner tests the new one and reviews its repair evidence.

6. Roll back code

Garden creates a new release action that reuses the most recently published superseded image. It does not rebuild that image from changing source or dependencies.

7. Recover data separately

Code rollback does not restore deleted or incompatible records. Application data recovery requires its own backup, restore, compatibility, and decision process.

8. Archive or hand off

Archiving stops app URLs while retaining supported source, release metadata, images, data, buckets, and secrets. Unarchive restores a retained image as a private draft; going live remains explicit.

A durable release record

Every action that can change what runs starts with a release record. A release identifies its reason, target, source lineage, prior release, and immutable runtime inputs. This keeps retry and rollback from silently reading whatever configuration happens to be current later.

Committed sourceExact Git revision
Private draftTest without moving live
LiveCoworker-facing revision
SupersededRetained rollback candidate
Failure behavior

A failed build, health check, or publish is recorded as a failed release. It does not turn a draft into a live app or erase the previous live release.

Ownership after the original builder leaves

The durable handoff is the collection of source, current and prior releases, runtime configuration references, attached resources, repair evidence, app purpose, and operating history. Garden keeps these boundaries visible so the replacement owner does not need the original chat transcript to understand what coworkers use.

Business context

An app brief names its purpose, users, important workflows, data, and known operating boundaries.

Technical identity

Git revision, image identity, runtime specification, and release lineage identify what is actually running.

Safe next action

The owner can see whether an app is waiting, unreleased, draft ready, live, or needs attention before choosing an action.

Recovery path

Release history supports code rollback; database restore and forward recovery remain separately owned procedures.

Current limits

Verify before relying on Garden
  • The pilot supports draft to live; it does not provide general multi-stage promotion or per-application approval workflows.
  • General team RBAC is outside the current pilot. Google access and application authorization still require deliberate design and testing.
  • Rollback reuses a prior application image. It does not reverse database migrations or restore application records.
  • Garden can repair applications that meet its current release contract; it is not general migration tooling for every framework or architecture.
  • Successful release controls do not replace application-specific security, workflow, restore, and operational testing.

This page describes the current design-partner pilot and separates product behavior from application-specific responsibilities. Send product questions or corrections to hello@gardenai.ai.