--- title: Embeds Guide | Vibecodr Docs description: Embed vibes across sites safely with live-vs-exact artifact behavior, VXBE frame delivery, and sandbox constraints that preserve trust. canonical: https://vibecodr.space/docs/embeds --- # Embeds Guide Embeds extend a vibe beyond vibecodr.space while preserving sandbox boundaries, canonical identity, live-vs-exact artifact behavior, and performance expectations. Marker: Distribution playbook for secure and stable cross-site vibe embeds. ## Implementation focus Use this before enabling external distribution so embed behavior matches trust and publication policy. ## Expected outcomes - Deploy embeds without weakening sandbox isolation. - Keep canonical app identity across first-party and third-party surfaces. - Understand pinned versus live behavior for shared experiences. ## Embeds (Pinned and Live) Embeds let you place a vibe on another site using a sandboxed iframe. Vibecodr provides the embed code so the runnable surface stays isolated from Vibecodr cookies, local storage, owner tools, and private source. If a vibe also has a claimed vanity URL and you explicitly allow public or allowlisted embeds, that vanity page can be framed directly. Allowing an embed changes where the vibe may appear; it does not make the third-party host a trusted platform surface. Pinned Default Choose an exact embed when the host page needs a fixed published cut. The embed does not move forward unless you copy a new exact embed. Live Optional Choose a live embed when the host page should keep following the vibe's newest published version after BUMP IT updates. ### Get an embed code 1. Open a vibe in the player. 2. Choose Embed, then select Pinned or Live. 3. Copy the snippet Vibecodr gives you, including its sandbox and allow settings. ### What the snippet should include A good embed snippet includes a descriptive title, stable dimensions, lazy loading, and the sandbox and allow settings Vibecodr provides for embeds. Some compatibility snippets include device, payment, or clipboard permission tokens so a vibe that asks for those features is not blocked at the iframe boundary before Vibecodr can show its own prompt. Those tokens do not silently approve access: the runtime still asks the viewer through Vibecodr's capability prompt, and the browser may still show its own permission prompt. - Use a human-readable iframe title that names the vibe. - Set an explicit width and height, or responsive CSS from the host page. - Keep the copied sandbox and permission settings intact; they are part of the supported embed compatibility path. - Do not add camera, microphone, location, payment, or clipboard access on your own. If a vibe needs one of those features, let Vibecodr's runtime permission flow request and gate it. ### Embed allowlist External embeds are off by default. Enable them in [Settings > Embed Settings](/settings/embed), [Pulses > Embedding](/pulses?tab=embedding) or the Studio Config panel. The allowlist controls which external sites can host the outer wrapper on `embed.vxbe.space`. If the vibe has a claimed vanity URL, the same setting also controls which external sites may frame that vanity page directly. This changes supported embed ancestry, not source visibility, owner controls, or who can read private project material. - Origins must be HTTPS and origin-only (no path/query). - Add exact origins like `https://example.com`. - Use wildcard subdomains like `*.example.com` when needed. - First-party surfaces keep working even when external embeds stay off. - Embeds respect visibility and policy; revoked or private vibes show a safe failure. ### Structured embed metadata Some CMS and publishing tools can discover structured embed metadata from a Vibecodr share URL. Use the host product's add-by-URL flow when it supports that pattern, and prefer Vibecodr's copied embed code when the host asks for raw HTML. If a host cannot discover the embed automatically, copy the embed snippet from Vibecodr instead of hand-building request URLs. ## Caching and Delivery Vibecodr keeps the fast stuff on direct public hosts and keeps the sensitive stuff on the policy-aware lane. That means public experiences feel snappy without turning previews, private work, or gated artifact delivery into generic CDN objects. - Embed wrappers revalidate quickly enough that publishes, moderation changes, and live pointer updates can show up without making private work public. - Public dependency files, avatars, thumbnails, and eligible published runtime files use public delivery lanes. Drafts, private work, and gated artifacts stay behind policy-aware delivery. - Vibecodr uses edge caching and tiered cache paths so public reads stay fast without making private work public. - Pulse responses are not cached unless you decide to send your own `Cache-Control` headers. ## Structured route body ### Embed identity Embeds let a vibe travel outside Vibecodr while preserving its app identity, sandbox policy, and release behavior. The embed should still connect back to the canonical public app instead of becoming an orphaned copy. Live embeds can follow the current Drop, while exact embeds can pin a specific artifact. The right choice depends on whether the host wants the newest version or an immutable reference. - Use live behavior when the host expects updates to flow through. - Use exact artifact behavior when documentation, tutorials, or audits need reproducibility. - Preserve sandbox and frame boundaries even when the embed is distributed widely. ### Safety expectations Embedded code is still user-authored runtime content, so it must stay isolated. Embed delivery should not weaken CSP, frame, CORS, CORP, or sandbox assumptions to accommodate a third-party host. External distribution should increase reach without increasing trust. - Keep runtime execution inside the intended frame boundary. - Do not expose owner-only source or backend metadata through embed markup. - Keep canonical links and attribution visible enough for viewers and crawlers. ### Example and read next Example: a customer wants to place a vibe in a docs site. Use a live embed when updates should follow the current Drop, and use an exact artifact reference when the docs need reproducible behavior. Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system. - Read next: [Source & Versions](/docs/source) - Read next: [BUMP IT](/docs/bump-it) - Read next: [Approved CDNs](/docs/approved-cdns) - Read next: [Vibes & Pulses](/docs/vibes-pulses) ## Related documentation - [/docs/source](https://vibecodr.space/docs/source/index.md) - [/docs/bump-it](https://vibecodr.space/docs/bump-it/index.md) - [/docs/approved-cdns](https://vibecodr.space/docs/approved-cdns/index.md) - [/docs/vibes-pulses](https://vibecodr.space/docs/vibes-pulses/index.md)