Runs in the browser
A vibe is meant to be opened, not just looked at.
People can interact with it immediately instead of landing on a static preview or screenshot.
Vibecodr basics
What's a vibe? A runnable web experience attached to a post.
A vibe is the thing people can actually open, play with, tweak, remix, and share on Vibecodr. It is not a screenshot and it is not just a code snippet. It is the client-side experience itself. Technically, it runs in the browser inside a sandboxed iframe on a separate runtime host.
Sandboxed and isolated
The runtime is separated from Vibecodr's own storage and cookies.
That separation is the point: vibes stay interactive without getting trusted platform access.
Supports params
A vibe can be tuned at runtime without becoming a different product.
Params let the same experience adapt to context, links, and embeds.
Remixable
A vibe is built to be forked into someone else's next version.
The object people open is the same object they can remix into their own work.
Shareable
A vibe moves across feed, player, profile, and embed surfaces.
It behaves like both an app-like experience and a social object attached to a post, and BUMP IT keeps future versions on that same social object.
Where vibes show up
A vibe is both an app-like experience and a social object.
Vibes are attached to posts, which means they can show up across the feed, discover and profile surfaces, the full-screen player, and embeds without turning into a different product each time.
Feed
Vibes show up where people scroll and discover new work.
A vibe is attached to a post, so it can appear as part of the feed instead of living on an isolated demo island.
Discover + profiles
The same vibe can be reopened from discovery and creator surfaces.
It stays legible as a social object while remaining runnable when someone actually opens it.
Player
The full-screen player is where the vibe gets room to breathe.
That is the focused surface for actually running, interacting with, and tuning the experience.
Embeds
Vibes can travel onto other sites without losing the runtime model.
They remain runnable and isolated when carried into embed surfaces.
How vibes run
The runtime story is crisp: browser, sandbox, separate host, postMessage.
Vibes run entirely in the browser. They load inside a sandboxed iframe on a separate runtime origin and talk to the host through postMessage. There is no server-side Node.js runtime hiding behind the term.
Isolation model
Sandboxed iframe plus cross-origin runtime host.
The isolation exists to keep Vibecodr storage, cookies, and trusted platform state out of reach while still letting the experience run as real software.
Host bridge
The iframe and host coordinate through postMessage.
Params, runtime coordination, and host communication move through that message bridge instead of sharing a trusted backend environment.
What vibes are good at
Interactive, configurable, social, remixable.
The point of a vibe is not that it is "frontend-only." The point is that it is the part of the project people can actually interact with and pass around.
Interactive
Playable demos, tools, toys, explainers, and experiments.
A vibe is good at anything where the point is to interact with the software directly in the browser.
Configurable
Params let one vibe adapt to different contexts.
A vibe can respond to runtime parameters without pretending to be a separate backend system.
Social
It is attached to a post, so distribution is built in.
Publishing a vibe also makes it something people can discover, reopen, and share across Vibecodr surfaces.
Remixable
The best vibes invite someone else to make the next version.
The remix path is part of the product model, not an afterthought bolted on later.
Where the line is
Trust comes from being explicit about what a vibe does not do by itself.
Vibes are powerful, but they are still the client-side part of the project. Secrets, databases, and other protected resources belong in Pulses or other backend systems.
No direct secrets or storage
A vibe does not get D1, R2, KV, Durable Objects, or platform secrets by itself.
That boundary keeps trusted resources out of the client-side runtime and prevents marketing copy from overclaiming what a vibe can do.
Browser-origin network model
External calls come from the browser and stay constrained by runtime policy.
The runtime CSP and iframe isolation limit what the client-side experience can touch directly.
No server-side Node runtime
A vibe is not a hidden full-stack app running on the server.
It is the client-side experience. If you need trusted backend execution, that is exactly where Pulses come in.
When to add a pulse
Keep the vibe clear first. Add Pulses when you need backend power.
A vibe is the client-side experience. A Pulse is what you add for trusted work like secrets, storage writes, OAuth connections, automations, or other backend execution. When both exist together, that becomes a Combo.
See them live
Discover
Browse runnable vibes as they appear in the feed and discovery surfaces.
Build one
Studio
Create the client-side experience, preview it live, and publish from the same workspace.
Trust model
How it works
See the iframe isolation model, runtime host, and postMessage bridge in plain terms.
Add backend power
Power of Pulses
Understand what changes when a vibe grows into a vibe-plus-Pulse architecture.
Infrastructure
Cloudflare Workers guide
See how the trusted backend side maps onto Pulses and Workers-powered execution.
Operate the backend
Pulses
Manage the server-side functions you add when the project needs trusted work.
Upgrade path
Start with the vibe. Layer in Pulses only when the project needs trusted work.
That is the clean mental model: the vibe is what runs in the browser, the Pulse is the backend extension, and together they form the full-stack Combo shape.
FAQ
Questions? We'll keep the answers concrete.
Does a vibe run on the server?
No. A vibe runs entirely in the browser inside a sandboxed iframe. Vibecodr does not give vibes a server-side Node.js runtime.
Can a vibe access secrets directly?
No. Vibes do not get direct access to secrets, D1, R2, KV, Durable Objects, or platform cookies. Trusted work has to go through a Pulse.
Can I remix someone else's vibe?
Yes. Remixing is a first-class part of the product. A vibe is designed to be something people can open, tweak, fork, and publish into their own version.
How do updates work after I publish?
Use BUMP IT to publish the next version of the same vibe. Vibecodr creates a new cut, keeps the same canonical app post, and preserves older cuts for rollback or pinned embeds.
Can I add backend logic later?
Yes. Start with the client-side vibe, then add a Pulse when you need trusted backend work. If the project has both, it becomes a Combo.