Studio Docs

How a Page Ships: Without Shipping Code.

The Lifecycle

Six steps end-to-end. The first two ship through git, PR, and a deploy (your normal SDLC). The next three ship through Studio’s publish: same React, same CMS, no rebuild. Below: where each step lives, who owns it, and what you don’t have to repeat per page.

Vertical five-step lifecycle. CODE phase (steps 1-2, purple): build the React component, register it with Studio, ships through git/PR/deploy, once per component. STUDIO phase (steps 3-5, teal): compose a Section by binding the component to a Content Type schema, compose a Template by dragging Sections and setting a URL pattern, publish, ships through Studio's publish, no rebuild. Outcome: visitors hit the URL and the Template renders the page from real CMS data.

Do It With a Skill

studio-tour walks the with-Studio flow described here, stage by stage.

curl -fsSL https://studio-documentation.contentstackapps.com/install.sh | sh

The Engineering Lifecycle: Side by Side

The Section / Template model changes what each step of building a page looks like. Without Studio, every page’s layout, fetch, and prop-mapping is hand-wired in code. Every layout change ships as a code change. With Studio, two new steps (build Sections and build Templates) turn a page into a composition that authors can rearrange without a deploy.

Development flow without Studio: three stacked steps. Setup (app shell + delivery SDK), Build components (author + Storybook), Build pages per page (hand-wired layout + data fetch + prop mapping). Every layout or field-rename change requires a code change, PR, and redeploy. Development flow with Studio: four stacked steps. Setup adds the Studio SDK plus a canvas route and a single catch-all template route. Build components is unchanged plus a one-line register call. Two new Studio-managed steps follow: build Sections (compose multiple components, bind props to CMS fields, preview live) and build Templates (drop Sections onto a content-type-bound template). Layout, Section swaps, and rebindings become no-code.

The Per-Page Flow: Before / After

Once your team’s engineering lifecycle is in place (above), every individual page moves through this before / after, a two-column decomposition of what a developer actually does per page, with the code that ships in each column.

Two-column comparison of the per-page flow. TODAY, WITHOUT STUDIO: five numbered steps (Content in CMS · Fetch via APIs · Compose page in code · Deploy · Page rendered) alongside a dark code-editor panel showing a hand-wired landing.tsx with hero, feature grid, and CTA. Every layout change loops through git, then PR, then CI, then deploy. WITH CONTENTSTACK STUDIO: six numbered steps (Content in CMS · Connect Studio SDK · Compose page in Studio · Preview · Publish · Renders automatically) alongside a rendered Studio-canvas mockup showing Hero and Feature Grid tiles both marked 'bound' plus a dashed drop zone for any registered component. Layout changes ship through publish, not through git. THE UNLOCK: same React, same CMS, two extra steps in Studio replace an entire deploy cycle.

For the horizontal one-scan version optimized for first-touch readers, see Where Studio fits in your day-to-day flow on the docs home.

What You Do, Side-by-Side

StepWithout StudioWith Studio
SetupApp shell + Delivery SDKApp shell + Delivery SDK + Studio SDK + canvas route + ONE catch-all template route (handles every URL)
Build componentsAuthor + Storybook (isolated, fixtures)Author + Storybook + register in Studio (1-liner or via CLI)
Compose multiple componentsIn code, per pageIn Studio as Sections (reusable, previewable with real data)
Build a pageHand-code layout + data-fetch + prop-mapping per pageBuild a Template once, drop Sections, bind to fields, done
Change page layoutCode change, then PR, then redeployAuthor in Studio, then publish
Re-map a prop to a different CMS fieldCode change, then PR, then redeployClick the binding, pick a different field, then publish
Preview a composed page with real dataBuild + deploy + visit URLOpen the Section/Template canvas, pick a preview entry
Launch a new content type pageNew route + new layout file + new fetcherDrop a new Template against the content type, drop Sections

What Stays the Same

Studio isn’t trying to take over your stack:

  • Your components stay in your repo: same build, same bundler, same deploy
  • Your design system stays sovereign: Studio uses your components, tokens, breakpoints. Not its defaults
  • Contentstack stays Contentstack: entries, content types, locales, publishing, branches, webhooks all work the same way
  • Storybook still does its job: isolated component preview is still its lane
  • Your existing pages keep working: Studio is additive. You can adopt it Section-by-Section, Template-by-Template

When You’d Still Use Code (and Why That’s Fine)

Studio is for layout + composition + binding. Some things are still better done in code:

  • Component implementation itself (Studio doesn’t write components for you: it composes them)
  • App-level concerns (auth, analytics, error boundaries). Studio handles page routing via Template URL patterns + a catch-all, but the surrounding app shell stays in code
  • One-off complex logic inside a component (data transforms, animations, integrations)
  • Server-side data fetching strategy (Studio supports CSR + SSR but you choose the path)

The right way to think about Studio: the layer above components, the layer below the app shell. Everything above stays code. Everything below stays code. The composition in between becomes data.

Two Paths to Onboard

Depending on where you are, pick the onboarding path that matches:

Both lead to the same destination: a Studio-powered app that composes your components against your CMS data, previewable at every step.

Next