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.
Production lifecycle
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.
The owner uploads or connects an existing application. Garden creates or uses a Git-backed application record; saving source does not make a release.
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.
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.
The owner publishes an identified draft. Garden changes the live release only after the publish succeeds and records who performed the action.
A later edit produces another draft. The current live release remains available while the owner tests the new one and reviews its repair evidence.
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.
Code rollback does not restore deleted or incompatible records. Application data recovery requires its own backup, restore, compatibility, and decision process.
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.
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.
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.
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.
An app brief names its purpose, users, important workflows, data, and known operating boundaries.
Git revision, image identity, runtime specification, and release lineage identify what is actually running.
The owner can see whether an app is waiting, unreleased, draft ready, live, or needs attention before choosing an action.
Release history supports code rollback; database restore and forward recovery remain separately owned procedures.
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.