Publishing puts a recipe or pack in the marketplace, under your name. A pack is how you ship your own ingredients together with the recipes that use them. Browsing and installing never need an account. Publishing needs a free one, because your name needs an owner. What you publish is the JSON itself, and anyone can read it. That openness is how the marketplace earns trust.
#Before you publish
Finish first. Test against your own server. For an ingredient pack, use the Pack editor to save, review, preview, and install it on your server. Only then open the cloud publish flow. The metadata makes the listing, so get it right:
- Name, description, tags. How people find it.
- Platforms and variant group. Lets copies of one recipe for other platforms fold into one marketplace card.
- Execution scope. Badges that say where the recipe can run.
- Provenance flag. If you opt out of timeline links, people who install are shown that.
- Fork lineage. A published fork shows what it came from.
#Submit a recipe for review
The publish screen takes one exported JSON object. It checks it and sends it in. It is not an editor. Load a Kitchen handoff if your build offers one. Or upload the exported file. Or paste the object. Then:
- Confirm the artifact type is recipe.
- Confirm the namespace. Your local slug becomes
publisher/slug. - Checks run. They find schema errors. They apply the marketplace gates. They also warn about packs it needs that are missing. Each problem is listed by field.
- Submit. The slug is saved for you while the review is pending.
#Review
What you sent in is pending until it is approved, rejected, or you cancel it. Approval makes the live listing. A rejection shows its reason and its time. Fix it in the Kitchen and send it again. The record is the status, the reason, and the time. Nothing is hidden. Was it rejected or dropped? Then its saved slug expires. Nobody can squat a name that way. Track all of it on the dashboard's Submissions page.
#Publish a pack manifest
Packs do not go through the recipe review queue. They use a separate,
direct path. The publisher you are signed in as must match the manifest's
publisher. Recued checks the pack envelope and every by-value
composition. A valid manifest is then published. It shows up in the
dashboard activity feed.
Direct publishing does not make a pack trusted. It does not make it a first-party pack that is already installed for everyone. It does not prove that every outside pin will resolve on the server of the person who installs it. Installing still looks up the pinned versions. It still shows the permission and connection choices. And it still stops safely on an invalid composition. See the pack manifest reference for the two manifest versions and what each one checks.
#Versions
A new recipe version goes through review again. A new pack version goes through the direct pack path and its checks again. Listings keep their version history. People who install can stay pinned to a version instead of following updates by themselves.
#Forks
A fork is your own copy of someone's recipe. Forks are first-class. There is a clear line between private and public:
- Local forks stay on your own setup. They are private. They run under the credential scope of the author of the original ingredient. That scope is the box that holds the secret keys.
- Published forks become their own thing. They get your publisher
handle and your own credential scope. They show
fork_of, which points back to the original.
Credential scope is per publisher and per install. So two recipes with the same name from other publishers never share secrets.
#Unpublishing
Where the rules allow, you can take a listing down from the dashboard. You can also put it back. Taking it down removes the listing from the marketplace. It does not reach into servers that already installed the content. Installs are local copies.
#Related
- Account and dashboard. Your handle, and where you track what you sent in.
- Authoring recipes. Writing the thing you are about to publish.
- Authoring ingredient packs. Building, reviewing, previewing, and installing your own capability on your server.
- Recipes and packs. How listings are browsed and installed.
- Pack manifest. The shape of a direct publish bundle, the packs it needs, and what it shows at install.