Public release flow
Publish and Share
Publishing is the moment editable work becomes a public, runnable thing people can open. This guide covers the release checklist, public metadata, links, embeds, and distribution choices that make the result understandable.
User-facing publication and distribution guide for Vibecodr apps.
Implementation focus
Use this page before sending a Vibecodr link to users, teammates, agents, or external audiences.
Expected outcomes
- Publish a runnable app with clear public metadata.
- Choose between player links, live embeds, and exact-cut references.
- Keep public copy focused on what viewers can safely use.
- Avoid leaking private source, secrets, logs, or platform setup into release notes.
Publish the thing people will open
Publishing turns your editable work into a public, runnable release. The important pieces are the app itself, the public post that explains it, and the live route people can open, share, embed, bookmark, and come back to later.
A good publish flow is practical: preview the app, confirm the title and description, choose visibility, add media when it helps people understand the project, and make sure any backend behavior works through documented Vibecodr capabilities before the link leaves your hands.
- Use Composer when the project is quick and self-contained.
- Use Studio when you need files, assets, imports, Pulses, or release control.
- Use clear metadata so feeds, search, link previews, and agents understand what the app does.
- Use BUMP IT for later updates to the same public app identity.
Share, embed, and distribute intentionally
A Vibecodr publish is more than a one-time post. The same work can appear in the feed, on a player page, in a profile, inside an embed, in search, and in external link previews. Those surfaces should agree about what the project is and what a viewer can safely do with it.
For teams, decide whether a link should follow the current live Drop or stay pinned to an exact cut. Live links are best for active apps. Exact references are best for tutorials, documentation, audits, and demos where behavior must not drift underneath the reader.
- Share the player page when you want people to open the current app.
- Use embed docs when the app needs to live on another site.
- Use creator SEO fields when external discovery matters.
- Keep private source, secrets, logs, and owner-only setup out of public descriptions.
Task example and next paths
Example: you finished a playable demo, want a clean public link, and need link previews to explain it clearly. Preview the app, publish with useful metadata, then share the player page or embed it depending on where the audience will open it.
Use the related paths below as the next reading order. They are generated from the same route metadata that powers public HTML, markdown aliases, sitemap coverage, and docs navigation, so users and agents see one consistent documentation graph.
- Related path: /docs/composer
- Related path: /docs/studio
- Related path: /docs/embeds
- Related path: /docs/seo-discovery