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. Under the hood, it runs in the browser in a safe runtime environment on a separate host.
The runtime stays separate from Vibecodr's own storage and cookies.
That separation is the whole trick: vibes stay playful and interactive while the platform keeps private resources out of reach.
A vibe can be tuned at runtime without becoming a different product.
Params let the same experience adapt to context, links, and embeds.
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.
A vibe moves across feed, player, profile, and embed surfaces.
It behaves like real software people can open, while still staying attached to one public app people can share, revisit, and follow over time.
Where vibes show up
A vibe is an app people can use and a post people can pass around.
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.
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.
The same vibe can be reopened from discovery and creator surfaces.
It stays easy to recognize as the same project while still being fully runnable when someone opens it.
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.
Vibes can travel onto other sites without losing their shape.
They stay runnable and self-contained when you carry them into embeds.
How vibes run
A vibe runs in the browser, in its own protected place.
Vibes run entirely in the browser. They load in a safe runtime environment on a separate host and talk to the main app through postMessage. There is no server-side Node.js runtime hiding behind the term.
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.
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.
A vibe is the part of the project people can actually open, interact with, and pass around.
Playable demos, tools, toys, explainers, and experiments.
A vibe shines when people are meant to open it, try it, and feel what it does for themselves.
Params let one vibe adapt to different contexts.
A vibe can adapt to where it is opened without pretending to be some entirely different project.
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.
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.
A vibe does not get D1, R2, KV, Durable Objects, or platform secrets by itself.
That boundary keeps trusted resources out of the browser side of the project and keeps the product honest about what a vibe can do on its own.
External calls come from the browser and stay constrained by runtime policy.
Those rules limit what the client-side experience can touch directly, so public code stays in a safe place.
A vibe is not a hidden full-stack app running on the server.
It is the client-side experience. If you need backend help, 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.
Borrow a Pulse
Blueprints
Copy reusable Pulse handlers when a project needs a proven backend starting point.
Trust model
How it works
See how Vibecodr gives projects a safe way to run code in the browser while still letting the host and runtime talk to each other.
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. The thing people open runs in the browser. Publish packages it into an artifact and boots it in a protected playback environment, while any real server-side work lives in Pulses instead.
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, moves the live Drop on the same canonical app post forward, and keeps older cuts around 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.