Skip to main content

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.

A Frontic release is more than an API version bump. It’s a snapshot of the entire project configuration at a single moment, bundled and shipped as one unit. This page lists exactly what’s in that snapshot so you know what’s frozen, what’s promoted, and what you’re testing when you work with a preview.

​
What’s included

Storage schemas

Field definitions, types, translatable/scoped flags, shared-across-variants flags, composite configurations. If you add, rename, remove, or change the type of a field, the new schema goes in the snapshot.

Syncs

Every sync configuration — source feed, target storage, and the Value Composer mappings that transform one into the other. A Composer expression change is a release-worthy change.

Blocks

Block definitions: parameters, fields, storage connections, nested blocks, variant list configurations, variant field rollups. Anything you’d touch in the API Builder.

Listings

Listing definitions: filters, sorts, search configuration, pagination, facets, and the per-item block shape.

Pages & Routing

Page definitions, slug field assignments, withdrawal actions, conflict resolution strategies, menu structures, the full generated URL set.

Project settings

Scopes, regions, locales, domain mappings, data types. The axes that shape Request Context for every API response.
Plus anything else that affects the shape or content of an API response — if it changes what your frontend sees, it’s in the release.

​
What’s not included

Releases are about project configuration. The data pipeline — source systems and the feeds flowing out of them — sits outside release control:
  • Data feeds — the raw records pushed in by your connectors (Shopify, Shopware, a PIM, a CMS). Feeds are team-level and always-on; they flow into Frontic independently of release state. A product update in Shopify lands in the feed layer immediately, regardless of which release is currently public.
  • Ingest credentials — connector authentication lives in project settings but is stage-invariant. Promoting a release doesn’t rotate credentials.
  • Context Base content — Skills, Rules, and Commands are a separate surface from the Stack and don’t flow through releases. They apply instantly to the next conversation with Buddy or Studio.
  • Admin-level state — organizations, teams, members, billing. These live above the project boundary and aren’t affected by releases.

​
What about the data?

Project data — storage records, block outputs, listing indices, generated URLs — is tied to the release it’s served under, not because it’s copied into the release bundle, but because each release is a full project clone with its own pipeline run. When you create a preview, Frontic clones the current develop project end-to-end (storages, syncs, blocks, listings, pages, project settings) and re-runs the pipeline against the clone. The cloned project gets its own data set, shaped by its own configuration. That’s why each version stays internally consistent: its schema, sync mappings, records, and API responses all match each other by construction. All three version stages run their pipelines continuously against the same shared feeds. A product update landing in the feed layer flows into develop, preview, and public in parallel — each processed through its own cloned configuration. Changing configuration in develop re-processes develop’s records. Promoting a preview makes that preview’s cloned project the new public; because the preview has been staying live all along, promotion doesn’t trigger a rebuild — it just flips which cloned project is the default. Feeds are shared across versions; everything downstream (storages, records, block indices) is per-version.

Releases

The three version stages (develop / preview / public) and how changes flow through them.

Release Flow

Create a preview, promote to public, manage version tokens, handle fallback.