Discussion about exporting/importing documents between dev and production servers using Sanity.io

29 replies
Last updated: Jul 20, 2022
is there a quick an dirty way to export a document from a dev server to import to a production server?
AI Update

For a quick and dirty way to move a single document from dev to production, you've got a few options:

Quickest: Using the CLI with GROQ query

You can export a specific document by its ID and import it directly:

# Export a single document
sanity documents query --dataset development "*[_id == 'your-document-id']" > document.ndjson

# Import to production
sanity dataset import document.ndjson production

This creates a small NDJSON file with just that document. If the document references assets (images, files), you'll need to handle those separately or use the full dataset export approach.

GUI Option: Cross Dataset Duplicator Plugin

If you prefer a point-and-click approach, install the Cross Dataset Duplicator plugin:

npm i @sanity/cross-dataset-duplicator

This lets content editors copy documents between datasets directly from the Studio interface without touching the command line. It handles both documents and their associated assets.

Full Dataset Export (overkill but reliable)

If you need everything including assets, you can use the dataset export command:

# Export from dev
sanity dataset export development dev.tar.gz

# Import to production (merges with existing content)
sanity dataset import dev.tar.gz production

This exports the entire dataset, so it's overkill for a single document, but it's the most reliable way to ensure all assets and references come along.

Important notes:

  • Imports merge with existing content by default - they won't overwrite your production dataset
  • The schema definition lives in your code, not in the export, so make sure your production schema supports the document type you're moving
  • If the document has references to other documents, those referenced documents won't be included unless you export them too

For a truly quick one-off, I'd go with the GROQ query approach. For something you'll do regularly, the Cross Dataset Duplicator plugin is worth setting up.

do you mean a specific doc (data only) or a schema?
a specific doc
like i have a document with quite a bit of data entered
and i don't reaaallly want to copy it over manually
check your production 😉 BUT
sanity deploy
before
just hoping for a
sanity dataset export --doc-id {some-doc-id}
or something like that, so i can then
sanity dataset import --missing
not sure what you mean?...
i've got spaces setup, so i have a
staging
dataset and
production
dataset deployed
and i want to copy over a document from staging -> prod
So wait 2 different datasets or did you setup a schema in your code and filled it with data on localhost:3333?Or do you have 2 datasets?
i have two datasets right now:
staging
and
production
. and it has been deployed with
sanity deploy
.
we have a new document on staging that i want to copy over.
that being said, i do still think there is a bit of confusion on my end on the best way to setup a dev -> staging -> prod environment and have it as smooth as possible for devs and content writers.

i've asked it plenty of times here and feel like everybody has a different solution that they implement or recommend


at the moment, using previous advice. we have our "live" project with two datasets:
staging
and
production
. with spaces setup so we have a quick switcher on
our-site.sanity.studio

the content writers add content there.

as for devs (like me) we have our own projects setup and anytime we work on new stuff we export the production dataset and import to the local/personal project: we make changes (ie updating schema, adding/testing with local content)

then when we want to push up to staging i deploy the schema changes to the "live" project. and the content team will create the new page on staging. and here we are ready to push to live, and i want to know if i can just export/import that new document
it seems like there might be "better" way but i haven't been able to wrap my head around it to make it work for our team
Okay crystal clear now :minecraft-diamond: I will investigate for you about the import/export! I just did not understand your question 🙈 but you are doing the right thing especially if you have bigger teams working on all sides. Safety first ☝️If you need some pointers I could try and find a best practice for you, if you share more details about your needs in general
😊💃
ok that'd be great. I will try to write out all the details when i have a few mins
we just made some schema changes. tested them locally on a project with a different id than the live studio. all good
now i want to launch to staging to test it out.

we have spaces setup in our studio to be able to switch between
staging
and
production

i ran
sanity deploy
with these in my
.env.development
file

SANITY_STUDIO_API_PROJECT_ID=project_id
SANITY_STUDIO_API_DATASET=staging
which deploy the desk structure change to BOTH datasets


production
and
staging
when the result i wanted was just on the staging dataset 😞
cc
user J
user T
to the rescue: https://github.com/sanity-io/cross-dataset-duplicator
“This plugin is designed as a convenience for Authors to make small, infrequent content migrations between Datasets.”
Thanks
user E
for this find
so i think this is a great solution, buuuut
user T
could you help me diagnose some issues?
seems like the duplicate from isn't getting populated...
missing projectId... is there a way to set it in .env.development somehow? cuz i don't want to commit the projectId to
sanity.json
The plug-in will require it to be loaded in sanity.json
If your dataset is set to private, there's no risk to leaking data from a projectId alone.
hmm k. thanks for the help.
is there any technical reason that the projectID can't be loaded elsewhere? could i make an issue on github for that?
Just the way the plug-in is configured, it relies on the Spaces config.
Feel free to write up an issue for it :)
🤔 i wonder how/why spaces is working fine for me without the projectID... it must be grabbing it from somewhere... likely the .env file
Mmm… maybe there's more I can look at. Write an issue and I'll follow it up.
already on it
https://github.com/sanity-io/cross-dataset-duplicator/issues/13
lemme know if you need more info/help with the fix
not sure if there is a better spot to chat about this: but i would be interested in contributing to this plugin. is there any special considerations? or just make issues, discussions and PRs?
Would love a PR 😊
I usually use “npm link” to work with plugins in the studio. Let me know if you need more details.
user T
if you have some docs or something for plugin development best practices please let me know. I'm not familiar with
npm link
, i come from php background.
So any tips on the best dev workflow would be great. cheers
There's a guide here in the plug-in starter it's based on
https://www.sanity.io/plugins/sanipack

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?