# Releasing physical AI data & models with LeRobot and Hugging Face

> The twelve steps of a coordinated LeRobot partner release: planning and storage, the v3 dataset format, cards and evidence, launch day, and the week after. With an interactive roadmap and a pre-flight checklist.

- **Authors**: Steven Palma, Nikodem Bartnik, Daniel van Strien
- **Published**: Aug. 27, 2026
- **Template**: article

---

Preparing to open-source a robotics dataset or model is often the culmination of months of hard work. The LeRobot team is here to help you launch it successfully [@lerobot2024].

This is the guide we send you when that conversation starts. It covers the release itself: what to settle before you create a repository, what shape the bytes need to be in, what belongs on the card, who does what on the day, and what keeps the downloads accumulating the week after. None of it has to be worked out on your own. We stay on the channel from the first message to the week after launch.

Twelve steps across five stages. Eight are yours, three we do together, and the review is ours, though you can pull us into any of the rest.

## TL;DR

Tell us early, and tell us the size. Settle the split before you create a repository, because names are important for users. Pack the data the v3 way, say near the top of the card what gap it fills, and if you can, ship one piece of evidence that it works. Send us far more footage than seems reasonable. Upload days early into private repositories, and flip visibility on the day with every link checked while logged out.

None of these has to be a burden, we are here to support you in this exciting release!

*[Interactive visualization: partner-release/release-roadmap.html]*

## 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.

No shared channel yet? Write to [le-robot@huggingface.co](mailto:le-robot@huggingface.co) and we will set one up and introduce you to the people you will be working with.

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](https://huggingface.co/docs/hub/datasets-data-files-configuration) 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](https://huggingface.co/docs/hub/collections) 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.

> Papers, notebooks and other people's training scripts all end up pointing at these names, so they are worth a few minutes up front. If you are undecided, send us the shape of the data on Slack and we will think it through with you.

## 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 [@lerobotDatasetV3Docs]. The layout is what does all of that:

```text
your-org/your-dataset/
├── meta/ info.json · stats.json · tasks.parquet · episodes/
├── data/chunk-000/file-000.parquet ← many episodes
└── videos//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.

*[Interactive visualization: partner-release/packing.html]*

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.

> Raw sensor logs that are not aimed at policy learning are usually better published as ordinary Hub datasets, in Parquet, WebDataset, MCAP or MP4. If you are unsure which side yours falls on, send us a sample episode and we will look at it with you.

Before anything is announced, play a few real episodes in the dataset viewer and the [LeRobot visualizer](https://huggingface.co/spaces/lerobot/visualize_dataset). 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 [@hubRecommendations]. 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 [@uploadGuide]. 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.

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

Moving from S3, GCS or Azure, or shifting more than about 10 TB? Start with the [bucket migration guide](https://docs.google.com/document/d/1g8C8KNZfpZJfVgx1ocuYKzr7-VjajonvZHGE3sMHRgI/edit) before you pull it all down, and ask us if anything in it does not fit your setup.

> Push into the private repositories, then flip visibility on the day. A multi-terabyte transfer takes days, so give it the week before launch. Staging privately needs room for the same data you are about to publish, so tell us the size when you tell us the date and we will make sure the space is there.

## 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 [@datasetCards]: 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.

> Use a real [SPDX licence identifier](https://huggingface.co/docs/hub/repositories-licenses). Apache-2.0 is the `LeRobot` default; if yours is non-commercial, tell us early, because it changes how the community can use the release. Check the licence upstream as well, since third-party footage, purchased assets and simulation assets carry their own constraints, and anything involving people needs a line on consent and anonymisation. If you want to know who is downloading, turn on [gated access](https://huggingface.co/docs/hub/datasets-gated) before release.

### 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.

```python
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](https://huggingface.co/docs/hub/collections). 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.

> Log out and click everything: each repository, the collection, the viewer, the model card. It is the quickest way to know the release looks to everyone else exactly the way it looks to you.

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.

*[Interactive visualization: partner-release/launch-checklist.html]*

## 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](https://huggingface.co/docs/hub/storage-buckets): S3-like object storage under the same organisation and permissions as the rest of your Hub account, at `hf://buckets/` paths [@storageBuckets]. `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](https://huggingface.co/spaces/imstevenpmwork/LeRobot_and_HF_Buckets) walkthrough goes through the advantages in detail, and the [migration guide](https://docs.google.com/document/d/1g8C8KNZfpZJfVgx1ocuYKzr7-VjajonvZHGE3sMHRgI/edit) covers coming from S3, GCS or Azure.

> A bucket can hold a `README.md`, but it has no dataset viewer, no revisions and no gating, so it is not the landing place for the release people are meant to find first. It suits anything too large or too plain for the curated repository.

## Ready when you are

When you are ready to start, open the Slack channel or write to [le-robot@huggingface.co](mailto:le-robot@huggingface.co). Tell us what you are working on even if the date is months away and the data is still being recorded. We would far rather hear from you too early than too late, and we are looking forward to seeing what you have been building.

## Relevant links

### Format and upload

- [LeRobotDataset v3](https://huggingface.co/docs/lerobot/lerobot-dataset-v3), the format, the v2.1 migration and streaming
- [Upload files to the Hub](https://huggingface.co/docs/huggingface_hub/guides/upload), `hf upload` and `upload_folder()`
- [Repository limitations and recommendations](https://huggingface.co/docs/hub/repositories-recommendations), the current file and folder limits
- [LeRobot visualizer](https://huggingface.co/spaces/lerobot/visualize_dataset), for playing your episodes
- [LeRobot on GitHub](https://github.com/huggingface/lerobot), the library and the policies

### Publishing and access

- [Dataset cards](https://huggingface.co/docs/hub/datasets-cards), what belongs in a card
- [Licences on the Hub](https://huggingface.co/docs/hub/repositories-licenses), the SPDX identifiers
- [Gated access](https://huggingface.co/docs/hub/datasets-gated), if you need to know who is downloading
- [Collections](https://huggingface.co/docs/hub/collections), for gathering the pieces on one page

### Storage

- [Storage plans and limits](https://huggingface.co/docs/hub/storage-limits), the current allowances
- [Storage Buckets](https://huggingface.co/docs/hub/storage-buckets), S3-like object storage on the Hub
- [LeRobot and HF Buckets](https://huggingface.co/spaces/imstevenpmwork/LeRobot_and_HF_Buckets), the walkthrough

### This guide

- [llms.txt](/llms.txt), the whole guide as Markdown, for reading offline or handing to an agent

### Talk to us

- [Bucket migration guide](https://docs.google.com/document/d/1g8C8KNZfpZJfVgx1ocuYKzr7-VjajonvZHGE3sMHRgI/edit), for moving from S3, GCS or Azure
- [le-robot@huggingface.co](mailto:le-robot@huggingface.co), for a shared channel or to start a release
- [The LeRobot organisation on the Hub](https://huggingface.co/lerobot), what the team publishes