A whole site's structure in one JSON file

A JumpStart file is a site's structure written as JSON: a collections block listing reserved and custom collections, the schemas they use, an objects array of real records, and a factory array that generates content instead of storing it. Export one from a site, read it, edit it in a text editor, commit it alongside your templates, and import it somewhere else.

Reserved collections can be listed as a plain id or as an object carrying overrides, so a blog can arrive already configured — an entry of {"id": "blog", "url": "/blog/{id}", "sortBy": "date:desc"} keeps the built-in schema binding while setting the public URL pattern and the default sort at the same time.

The factory array is what keeps a starter file small. Rather than forty near-identical blog posts, one block asks for a count and a set of Faker rules — sentence, paragraphs, date, boolean, numberBetween(1, 100), tags(1, 5) — and the importer generates them on the way in. Image and file fields are skipped during factory generation, so nothing you seed depends on a binary that was never there.

Which is the honest limitation, and the docs lead with it: JumpStart is not a backup. Image, gallery, file and depot values are normalised and referenced, but the binaries themselves are not embedded. A JumpStart round trip returns your structure and your text and none of your uploads. When you need a complete copy of a collection, use its Export to Zip instead.

You can run it three ways: from Admin → Utilities → JumpStart, where checklists narrow the export to particular schemas and collections and toggles add objects and templates; from the command line with tcms jumpstart:export and tcms jumpstart:import; or by POSTing a definition to /import/jumpstart. The importer skips objects that already exist, which is exactly why the bundled Site Builder starters ship their pages and demo content as JumpStart files — re-running one never clobbers what an editor has changed since.