Releasing physical AI data & models
with LeRobot and Hugging Face

Plan: the decisions worth making first

1. Tell us early (together)

The earlier we hear from you, the more we can do. Get in touch on the shared Slack channel with what you are releasing, why it matters to you, a rough date, and the total size. There is no fixed lead time and no such thing as too early: review and any reformatting take time, and that time is much easier to find weeks out.

Depending on the size of the release and your account tier, a storage add-on might be needed. Send us the number early and we will work out the right setup with you.

2. Decide the split, then create the repositories (you)

The first thing worth settling is what counts as one dataset. Split by embodiment, by task family, or by collection campaign: anything someone might reasonably want to train on without the rest. Keep it whole when people will use the whole thing anyway.

Each repository carries its own card, its own discussion page and its own download count, so splitting spreads those thinner. If the pieces are variants of one collection, configs inside a single repository keep them together while still letting people load one at a time. If they are genuinely separate datasets, split them and gather the pieces into a collection on your organisation page. The Hub’s limits apply per repository either way, so a very large dataset may need splitting regardless. Models are simpler: one repository each.

Create them under your own organisation and keep them private until release day. Everything after this happens where only you and we can see it.

Package: put the data in a shape people can use

3. Use the LeRobot v3 format (you)

The LeRobotDataset v3 format loads in one line, streams from the Hub without downloading, renders in the dataset viewer, and trains with every LeRobot policy (Hugging Face, 2026). The layout is what does all of that:

your-org/your-dataset/
├── meta/    info.json · stats.json · tasks.parquet · episodes/
├── data/chunk-000/file-000.parquet        ← many episodes
└── videos/<cam>/chunk-000/file-000.mp4    ← many episodes

Many episodes go into each file, never one file per episode. The defaults handle it: about 100 MB per Parquet file, 200 MB per MP4, up to 1000 files per chunk folder. Coming from v2.1, convert with convert_dataset_v21_to_v30 before uploading.

Two naming habits make the data usable by someone who was not in the room. Name features by what they are, not by the device that produced them: observation.images.wrist_left instead of observation.images.cam3. And write task strings the way a person would give the instruction, since they end up in the prompt of every policy trained on your data.

Before anything is announced, play a few real episodes in the dataset viewer and the LeRobot visualizer. That is how most people meet your data, and it is usually the moment the release starts to feel real. If something looks off, send us the link and we will work out why.

4. Check the shape, then upload early (you)

A repository has limits on how many files it can hold, how many entries can sit in one folder, and how large any single file can be (Hugging Face, 2026b). Packed chunks stay well clear of all of them, while one file per episode runs into them quickly, which is the practical reason the defaults pack the way they do.

Upload with hf upload, or upload_folder() from Python (Hugging Face, 2026c). It deduplicates chunks before sending, splits a large folder across commits by itself, and resumes if the connection drops. Much of this is easier if the data already sits in HF Storage Buckets: Xet deduplication is shared across the Hub, so data moves quickly between a bucket and a dataset repository without re-uploading what both already have.

hf upload your-org/your-dataset ./your-dataset --repo-type=dataset --private

Document: make it obvious why this exists

5. Write the cards (you)

The dataset card is the README of the repository, and it is what most visitors read (Hugging Face, 2026): what the data is, the robot and the hardware, the tasks, the episode and frame counts, the collection setup, the licence and a citation. A model card adds the training recipe, the eval numbers and a link to the dataset. Put good video or images in both.

Near the top, say what gap it fills:

What is the closest existing dataset, and how is this different?

A new embodiment, a new environment, a modality nobody had, real data where only simulation existed. Answer that in the first screen and everything below it lands better.

Then the things people ask for once they start using it: the collection protocol (hardware, camera placement, what the operators were told, any filtering), the numbers (hours, episode counts and lengths, task distribution, camera views and resolutions), and where the dataset is weak. Being straight about the weak spots builds more trust than another headline number. If you would like a second pair of eyes on a draft card, send it over whenever it is ready.

6. Show that it works, if you can (you)

This one is a nice-to-have rather than a requirement, and of the nice-to-haves it is the one that does the most work. If you can ship something that shows the data in use, do: a baseline model trained on it, results on an established eval suite if one exists for your setting, or a handful of curated episodes in the visualizer covering the ordinary case, a hard case and a failure.

A short usage example helps as much as a trained model, and costs a lot less. A notebook that loads the dataset and plots an action trajectory removes the first hour of friction for everyone who tries it.

from lerobot.datasets import LeRobotDataset

ds = LeRobotDataset("your-org/your-dataset")
sample = ds[0]
print(sample["observation.images.wrist_left"].shape, sample["action"])

Then bundle it: datasets, baseline model, demo and paper in one collection. Tell us what exists and we can help put that page together.

Launch: the day itself

7. Send us footage, as much as you have (you)

On our channels, video posts are consistently the most engaging format, and they drive by far the most traffic to a release. There is no need to edit anything yourself. Send us the raw material and we will make the cut: takes, failed attempts, b-roll, time-lapses, shots of the setup and of the lab. The more we have to work with, the better that cut gets. A short written summary alongside it helps too, with anything we can use in the assets and the social copy.

8. We review it (LeRobot)

While everything is still private, we read through the repository structure, the dataset format, the cards and the metadata, and come back to you with notes.

This is what the lead time from step 1 buys. The notes are usually small things, and with a couple of weeks in hand there is room to work through them together without anyone rushing.

9. Agree the plan (together)

Between us we settle the post copy, which accounts to mention, who publishes first (usually you) and the exact publish time including the timezone. Check that both sides are around that day, so nobody is publishing on their own.

Coordinate with anything else in flight (a paper, a model release, a conference talk) and have everything staged before the announcement goes out, with the repositories filled and the collection assembled.

10. Release day (together)

The day itself is short. You flip the repositories public, then open every link while logged out.

You announce first from your own channels, with @LeRobotHF in the post, and we post from the official LeRobot account with a link to your repository. You are welcome to announce in the LeRobot Discord too, and the team amplifies it wherever we can from there. We will be on the channel that morning if anything needs a quick decision.

Iterate: the weeks after launch day

11. Plan the second wave (you)

A release spikes on day one and is quiet by day three, so it is worth deciding before launch what happens about a week later. It is the cheapest way to get a second run at the same audience, and we are glad to plan it with you.

The follow-ups that work show the data being used rather than announcing it again: a model trained on it with results, a clip of the robot doing the task, a notebook, or a write-up of what you learned collecting it. Watch for other people building on the release and reshare that, since someone else’s fine-tune is more convincing than a second post from you. If it earned real attention, a follow-up blog post is worth the effort, and we are happy to read a draft.

12. Consider moving your infrastructure to Buckets (you)

This last one is not about the release itself. What you publish stays a dataset repository, but everything around it that never needed to be a git repository, from raw captures before processing to training checkpoints, logs and evaluation runs, can move to Storage Buckets: S3-like object storage under the same organisation and permissions as the rest of your Hub account, at hf://buckets/ paths (Hugging Face, 2026). StreamingLeRobotDataset trains straight from one.

Several of the teams we work with have already moved their physical AI data infrastructure across, mostly for what it does to the cost of storing and moving robot data at this scale. Our LeRobot and HF Buckets walkthrough goes through the advantages in detail, and the migration guide covers coming from S3, GCS or Azure.