> ## Documentation Index > Fetch the complete documentation index at: https://docs.frontic.com/llms.txt > Use this file to discover all available pages before exploring further. # Release Control > [!NOTE] > > Release Control is available on the **Plus plan**. See [Billing & > Plans](https://docs.frontic.com/admin/billing-and-plans.md) for details. Release Control keeps two things apart: **where you edit** and **what your shop reads**. You edit in the **workspace**. Your frontend reads an **API version** through the [Fetch API](https://docs.frontic.com/reference/fetch-api.md). Releasing a version is the path from one to the other: you preview a version, deploy your frontend against it and test it, then publish it. API versions are per project. Each project has one workspace, its own develop and public versions, and a preview version while you release one. Every version serves that whole project: storage schemas, syncs, blocks, listings, pages and project settings move together. You never version a single block or endpoint. **releases/release-control-hero** Release Control on the project dashboard, showing develop state, preview slot, and available actions ![Release Control on the project dashboard, showing develop state, preview slot, and available actions](https://mintcdn.com/frontic/hS7rYTW0C-o2HHTZ/images/releases/release-control-hero-light.png?fit=max\&auto=format\&n=hS7rYTW0C-o2HHTZ\&q=85\&s=dce52433edbc326bf78e16f642cedb0c) ## The workspace The workspace is your project as you edit it. Every change you make in the Frontic app, through Buddy, in Studio or via MCP lands there at once. There is one workspace per project, and it is the only place you edit. ## API versions With Release Control, the Fetch API always serves two API versions of a project: > [card] Develop version > > The workspace as it is now. It changes with every edit and can > break at any moment: for development only. > [card] Public version > > What your customers see. It changes only when you publish, and > never breaks from a workspace edit. A **preview version** exists only while you release. When you [preview a version](#release-a-version), Frontic takes a snapshot of the workspace the moment you trigger its build. It holds still while the workspace moves on, so you can deploy and test against it. When you publish it, it becomes the public version. You keep editing the workspace, and each API version shows it from a different moment: the develop version shows it now, the public version from when you last published, and a preview version from when you created it. ## Release a version **1. Change the workspace** You, Buddy, the Studio chat or an MCP agent change something: add a field to a storage, rewrite a sync mapping, adjust a listing filter, add a page. The develop version shows the change at once, and Frontic reprocesses the data that depends on it. Developers can build against the develop version right away with `frontic generate develop`. Customers see nothing. **2. Preview a version** When the workspace is ready for testing, preview a version. Frontic snapshots the workspace into a new preview version with its own [version key](#version-keys) and processes your data with it. A new preview version replaces the old one, and the old key stops working the moment the new build starts. **3. Deploy and test against the preview** Run `frontic generate preview` to generate a [Client SDK](https://docs.frontic.com/reference/client-sdk.md) that carries the preview's version key, then build, merge and deploy your frontend with it and test the deployed app. What you test is exactly what you publish. **4. Publish the version** When the deployed app passes, publish the version. It becomes the public version at once, so the app you tested is already live on it, with no redeploy. Publishing is irreversible. [Release Flow](https://docs.frontic.com/releases/release-flow.md) covers each step in detail and the deploy order. [What's in an API Version](https://docs.frontic.com/releases/what-flows-through.md) lists what a version carries and what it shares. ## Version keys Each API version has a **version key**, sent in the `fs-version` header. A Client SDK carries the key of the version it was generated against, so your frontend reads the version it was built for. By default, the Fetch API serves the public version. Only a request with a valid version key reads another version, such as the develop version or a preview version. Without Release Control, or before the first publish, the public version is served straight from your workspace, so workspace changes take effect at once. See [How the Fetch API picks a version](https://docs.frontic.com/releases/release-flow.md#how-the-fetch-api-picks-a-version). ## Drafts > [!NOTE] > > Drafts are in active development, and specifics may change before general availability. Unlike the rest of Release Control, drafts are planned to be **exclusive to the Scale plan**. For changes that need more isolation than the workspace offers, Frontic is introducing **drafts**: short-lived snapshots of the workspace where you prepare work without changing the workspace for the rest of the team. Each draft has its own version key and a random sample of up to 100 records from each feed, so you can build a frontend against it with `frontic generate draft ` and iterate end to end. Several drafts can exist side by side. A draft merges back into the workspace, and you choose a side for each conflict. From there it follows the normal path: preview a version, then publish it. The path forward: pairing Release Control with [Studio](https://docs.frontic.com/studio/frontic-studio.md) and the [Experience Designer](https://docs.frontic.com/designer/overview.md), so a change, the frontend code that depends on it and the release that ships it all move together through one workflow. ## Pairs with your codebase Release Control maps 1:1 to the codebase that consumes your project. Your repo's deploy pipeline drives the frontend; Release Control drives the API versions. Preview a version, build the frontend against it, publish and deploy: the two pipelines move in lockstep. The forthcoming GitHub integration deepens this with PR tracking, automatic releases and release state surfaced on PRs. See [Core Concepts](https://docs.frontic.com/essentials/core-concepts.md#project-and-team) for why one project should pair with one codebase. ## Related > [card] [What's in an API Version](https://docs.frontic.com/releases/what-flows-through.md) > > What an API version carries - storages, syncs, API surface, project > settings - and what all versions share. > [card] [Release Flow](https://docs.frontic.com/releases/release-flow.md) > > Preview a version, publish it, version keys and how the Fetch API > picks a version. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.