Install the SDKs: Three Packages, Three Jobs
Studio is a runtime library your app calls, not a service that renders pages for you. That takes three packages, and they stack — each one assumes the one below it is already working.
| Order | Package | What it does |
|---|---|---|
| 1 | Delivery SDK | Reads published content from the CDN. Studio never fetches content itself; it asks this. |
| 2 | Live Preview | Streams draft content in real time, so the canvas shows unpublished edits. |
| 3 | Studio SDK | The editor bridge: studioSdk, <StudioCanvas />, <StudioComponent />, and the registration APIs. |
Do It With a Skill
install-studio does all three: installs the packages, validates your credentials before writing anything, and wires the initializer. It deliberately adds no routes.
understand-installation explains what an install actually adds: three SDKs, one shared init, and two component mounts.
Why the Order is Fixed
Live Preview configures the Delivery SDK — it adds a live_preview block to a stack instance that has to exist first. The Studio SDK then derives its own API host from whichever Delivery stack you hand it, which is why installing it against a half-configured Delivery SDK silently points Studio at the wrong data center.
Install them in order and each step verifies the one before.
What You Have at the End
Three packages installed, one shared initializer, and studioSdk.init running once at the app shell. No routes yet — mounting <StudioCanvas /> and <StudioComponent /> comes next, in Rendering and routes.