Public conversation snapshot
Follow the community thread graph.
Vibecodr conversations collect launch notes, feedback, architecture questions, and discussion around runnable web apps. This fallback keeps the public thread index linkable even when the SPA shell is not executing.
- Hottest
-
@vibecodr • Mar 18, 2026 • Technical updates
Runtime Bump 1.31
Runtime now can request MIDI access from users
-
@vibecodr • Mar 13, 2026 • Technical updates
NEW FEAT: BUMP IT
I've been working on a better way to update apps on Vibecodr without accidentally turning one project into a pile of duplicate listings. BUMP IT is now the canonical way to publish a new version of an existing app. Instead of making a brand new top-level post every time you improve something, BUMP IT keeps the same app identity, ships the latest version live, and preserves your version history underneath it. The goal is simple: one app can grow over time, your old cuts still exist, and updating an app feels like continuing the same project instead of starting over every time. If you’re the owner of an app, you’ll now see BUMP IT in the right places. Open it, jump straight into Studio update mode, and ship the next version.
-
@vibecodr • Mar 12, 2026 • Technical updates
runtime bump v 0.1.28
v0.1.28 is a stability-focused runtime upgrade for HTML vibes. We tightened the contract between compilation and playback so published HTML runs from a normalized bundle with explicit runtime metadata instead of depending on brittle browser-time behavior. The runtime now handles import maps and module preloads more deliberately, resolves relative assets against the actual artifact bundle, and surfaces execution-plan drift as structured runtime failures instead of opaque breakage. The result is a runtime that is stricter than older versions, but much more predictable across Studio previews, published vibes, and VXBE runtime hosts.
-
@vibecodr • Mar 30, 2026 • DEVELOPER NOTES
Runtime Bump! V 0.2.13 (mostly quiet changes)
From v0.2.4 to v0.2.13, most of the work was about making the runtime boot path more reliable, tightening frame security, and reducing bootstrap complexity without breaking existing embeds. v0.2.4 focused on launch correctness. We cleaned up launch-contract normalization, tightened React runtime readiness/error handling, and republished the immutable runtime asset set so runtime startup behavior was more predictable. v0.2.5 was the first big structural shift in this range. We split vanity frame delivery into a policy envelope plus a dedicated frame-loader, added the asset plumbing and route coverage to support that model, and effectively moved runtime boot into a cleaner staged bootstrap flow. v0.2.6 hardened the delivery path around vanity frame state and published artifact warming. This release was less about visible runtime features and more about making frame-backed delivery and cache behavior safer and more dependable under real traffic. v0.2.7 tightened how frame config gets transported. Instead of leaning on looser bootstrap state, the runtime moved to signed header-only frame-config state, added a hard timeout around config fetches, and tightened fallback behavior for grant-backed frames. This reduced ambiguity in startup and improved failure behavior. v0.2.8 closed a CSP/security gap by removing nonce exposure from the DOM. The frame loader now reads its nonce from the executing script instead of leaving it visible in markup, which is a cleaner and safer boot model. v0.2.9 tightened frame-state lifecycle handling. Signed frame state is cleared as soon as bootstrap hands it off, verified tokens now require frameOrigin, and the loader/API path got regression coverage. This was mainly about reducing token/state linger and making the trust boundary stricter. v0.2.10 fixed a real startup issue: a frame boot deadlock. The runtime now loads the React globals module through a blob-backed module URL so vanity/runtime frames can continue through guard, bridge, and runtime boot without stalling. There was no v0.2.11 runtime release in the repo history. v0.2.12 focused on hardening runtime guardrails. The main themes were safer link behavior in the guard layer, tighter fallback SEO scope, and better checks around runtime scroll/link policy. This release was about reducing edge-case leakage while keeping runtime behavior predictable. v0.2.13 was mostly about simplifying and speeding up bootstrap. We first regenerated the runtime bundle, then changed the vanity frame path to inline frame config directly into the shell so startup requires fewer network hops. The old frame-config endpoint stayed in place as a backward-compatible fallback. Follow-up fixes then tightened the frame-loader and vanity bundle behavior around that new inline path. In plain terms Across this whole range, the runtime got: a more structured boot pipeline a dedicated frame-loader in the published asset set fewer fragile startup paths stricter frame-state and nonce handling fewer bootstrap network hops better fallback behavior when frames or config loading go wrong
-
@vibecodr • Mar 28, 2026 • DEVELOPER NOTES
User-facing change! SEO Optimization
Your Work Deserves to Be Found Most platforms treat the stuff you build as feed content. You publish something, it lives in a timeline for a few hours, and then it's gone. Buried under the next wave of posts. Search engines never see it. The public web never knows it existed. I didn't want that for Vibecodr. If you ship something real here, whether that's a runnable app, a devlog, or a deep conversation thread, I think the open web should be able to find it, understand what it is, and send people to it. Not to a login wall. Not to a blank shell that says "content loads client-side." To the actual thing you made. Every public surface is a real page When a search engine crawls Vibecodr, it doesn't hit a single-page app and bounce. I intercept bot traffic at the edge and serve back a fully rendered snapshot of whatever public entity lives at that URL. Real titles, descriptions, images, structured data, visible content. Not a hollow SPA shell. This works across six types of public pages. Runnable app pages are the strongest showcase surface. If your vibe is a public app, its `/player` page becomes a full product listing: canonical URL, author attribution, engagement stats, tags, topic links, and `SoftwareApplication` structured data. Search engines read it as a live product, not a social media post. Standard post pages cover non-app content. Devlogs, launch notes, write-ups. These get `Article` structured data so search engines can distinguish editorial content from runnable products. Profile pages are indexed as creator hubs. Your display name, bio, about section, links, recent public work, all rendered for crawlers. A lot of discovery starts with the person, not the individual piece of work. If you're building interesting things consistently, your profile accumulates search value over time. Tags turn clusters of related work into discoverable shelves. Every tag gets its own indexed hub collecting matching public posts with their titles, snippets, and author info. Topic pages are the algorithmic curated version of tags. Thematic hubs with cover images, ranked lists of public vibes, and `CollectionPage` structured data. Entire categories of work become indexable destinations. Conversation threads are the secondary discovery layer. Public discussions get indexed with their titles, content, authors, and tags. Sometimes the thing people find first isn't the app itself. It's the thread where people are talking about it. You control what search engines see There are two layers of customization in this system, and the split is deliberate. The direct layer is what you'd expect. In the publish flow, you can set explicit SEO metadata for your posts: title, description, share image, plus separate overrides for Open Graph and X cards. On your profile, you can set default SEO fields and a brand suffix that carries across everything you publish. These aren't afterthought fields buried in settings. They're part of the publish experience because I think they matter. The indirect layer is more interesting. Search-facing surfaces across Vibecodr are also shaped by the real structure of your public work: - The tags you choose determine which tag and topic hubs your work appears in. - Whether something is a runnable app or a standard post changes the structured data type search engines receive. - Your profile content, pinned work, and recent public posts all feed into how your creator page renders for crawlers. - The quality of your titles and descriptions compounds outward into every discovery surface your work touches. So SEO on Vibecodr isn't a disconnected form you fill out once and forget. It grows out of the actual product you built, the context around it, and the identity behind it. Why I built it this way The goal was never "more pages in Google." The goal is that when you build something on Vibecodr, the public web can understand what it is. A runnable vibe should look like a runnable product. A creator profile should look like a body of work. A topic page should feel like a living scene, not a dead archive. If you publish public work here, the platform projects the thing you actually made. Not a generic page with some meta tags and hope for the best. That's a better foundation. And it's yours from the moment you hit publish.
-
@vibecodr • Mar 24, 2026 • Technical updates
Runtime Bump! V 0.2.4
We’ve been doing a pretty deep pass on the runtime lately, mostly focused on making it feel less fragile and more honest about what’s actually happening under the hood. The biggest change is that runtime launch is now driven by a cleaner manifest-backed contract instead of a bunch of scattered client-side assumptions. That means public and auth-pending launches behave much better while auth is still resolving, runtime sessions stay alive through permission changes, and focused/player surfaces come up more reliably without weird focus or warmup glitches. We also tightened up manifest + mirror handling so public runtime assets converge faster and stay more consistent once they’re live. On the product side, we aligned the “link-visible” behavior across the player, feed, and focused overlay, which gets rid of a bunch of edge-case weirdness around what should be viewable, remixable, or just hidden from homepage discovery. We also cleaned up same-origin /api/* runtime routing so backend access follows the same visibility rules as the rest of the public runtime surface. A lot of this work is invisible when it’s working, but that’s kind of the point: fewer brittle launches, fewer confusing state mismatches, and a runtime that feels steadier when people actually use it.
-
@vibecodr • Feb 14, 2026 • Technical updates
runtime update v 0.1.21 minor update
Downloads got smarter. The runtime now mediates downloads through an action-based approval flow instead of blanket permissions, and handles approved blob/data downloads locally inside the iframe. Also squashed a race condition where a download would get approved but never actually fire — turns out the iframe policy needed a beat to propagate before the click would go through
-
@vibecodr • Feb 14, 2026 • Technical updates
runtime update v0.1.19
This round was mostly about tightening isolation and making capability handling more consistent in edge cases. I hardened URL resolution inside sandboxed iframes so things don’t break when window.location ends up as about:srcdoc. Popup requests, link navigation, and download flows now go through a consistent absolute URL resolver. It sounds small, but it closes a class of subtle sandbox issues. Download handling is also cleaner. Programmatic downloads (like <a download.click() flows) are now intercepted properly, and blob/data URLs go through a safer conversion path. Whether a file is static or dynamically generated, the capability prompt behaves the same way. I also bumped the runtime to v0.1.19 and rolled the new bundle set, refreshed cache busting, and aligned the runtime index so the hardening changes are actually what’s running in production. On the HTML runtime side, external scripts now execute through a safer fetch+blob flow with improved module specifier handling. This makes CSP behavior inside sandboxed frames more predictable and less fragile. Test coverage around script replay was expanded as part of that. No breaking changes. Just structural tightening so the runtime behaves consistently under isolation and doesn’t rely on lucky assumptions. Less visible work, more integrity under the hood.
-
@vibecodr • Mar 20, 2026 • DEVELOPER NOTES
User facing update: Analytics on runs
Runs should now update every 10 seconds while still keeping the same safety protocols in place that prevent gaming the system and keeping n+1 errors out of the way :)
-
@vibecodr • Mar 11, 2026 • Technical updates
Runtime bump v1.23
We just bumped the runtime to v0.1.23 and tightened a few things that make the live player feel a lot more reliable. The biggest change is that sharing is now single-flight across the app, so repeated taps on Share no longer trip the browser’s “earlier share has not yet completed” error or spam false failure telemetry. On the HTML runtime side, we also cleaned up how third-party scripts are handled: old Ahrefs and Cloudflare beacon snippets get stripped out, raw cdn.tailwindcss.com scripts are removed, and HTML vibes now consistently rely on Vibecodr’s self-hosted Tailwind runtime instead of a cross-origin CDN fetch that the sandbox can’t load anyway. We also added a serve-time safety pass for legacy HTML bundles, which means older published vibes can benefit from those fixes without needing a manual republish. And because the Tailwind runtime is self-hosted here, we removed the misleading upstream CDN warning from the shipped runtime asset so the console reflects what the platform is actually doing now: fewer false errors, cleaner runtime behavior, and much more predictable HTML vibe execution.
-
@vibecodr • Jan 24, 2026 • Suggestions
How can I improve Vibecodr for you?
When I started building Vibecodr, I was really just trying to answer a question I kept asking myself: why is it so hard to deploy things? Once I got some real momentum there, another realization hit me. You can deploy projects all day, but if there’s no community to experience them with you, it eventually starts to feel kind of empty. Let’s be honest, most of us don’t have thousands of followers on X or Threads ready to interact with everything we make. We build things that matter to us, and then they just… sit there. That gap is why Vibecodr exists. At this point I’ve been building this for months, and I’m getting to the stage where I really need input from the people who would actually use it. I want to know what would make this something you’d come back to every day. What do you wish existed? What feels missing? What do you hate or find frustrating? No suggestion is too small. My goal is to grow this little space into something genuinely useful and meaningful for all of us, and the only way that happens is if you help shape it. Anywho, thank you as always, -Braden
-
@vibecodr • Jan 21, 2026 • DEVELOPER NOTES
Developers Log - 001 (finally)
Someone gave me a great idea: we should maintain a dev log so people can see what’s happening, what’s being built, what’s changing… because so much of Vibecodr has been happening “behind the scenes”. And honestly, this post is also me forcing myself to stop hiding behind “I’m still working on it” as a permanent state. The funny part is: writing Devlog 1 immediately forces the thing I’ve been side‑stepping… a version number. Which feels way more intimidating than it should. I’ve been building Vibecodr for about 4 months. Most days it’s been 10+ hours. There are 867 commits on GitHub. And for a long time that was my “devlog”: a pile of commits, notes scattered across files, and whatever was in my head at 2am. So I’m calling this moment Devlog 1, and (for my own sanity) this era is basically V1. Not “perfect”. Not “finished”. Just: the platform is now a real thing you can use end‑to‑end. That matters. Why I built Vibecodr I’m going to keep this real and not romanticize it. At some point recently I made a Reddit post that was basically me saying: I’m looking for community. I’m looking for the kind of people who build weird stuff because they can’t not build it. The kind of people who think interactive code can be art. The kind of people who still get excited when something in the browser feels alive. The replies were helpful, but the underlying truth hit me: everyone is scattered. Tons of talent, tons of creativity… but no obvious “home” that feels like our home. So I stopped searching and started building the place I wanted to exist. Vibecodr, to me, is not “a website with posts”. It’s a way to make creative code shareable like a song is shareable. Not “clone the repo.” Not “run npm install.” Not “it works on my machine.” Just… click → it runs → you feel something → you remix it → you make it yours. That’s the whole idea. Everything else is scaffolding. What Vibecodr actually is right now (in plain English) Vibecodr is a social platform for interactive web experiences. A “Vibe” is a post that can contain a runnable project (“Capsule”). Capsules are client‑side apps that run in a sandboxed iframe on their own domain. That separation is intentional. It’s part of the safety story. (This also enables embedding without handing your browser storage/cookies to random code.) Capsules have real constraints and guardrails: file limits, bundle size limits, boot timeouts, safe defaults. You can import npm packages directly and the platform resolves them through a CDN pipeline (so you don’t need to wire up bundlers just to make something playful). And when you need server-side power, you don’t hack secrets into client code. You use Pulses. Pulses are server-side scripts deployed on Cloudflare Workers for Platforms. They support secrets (write-only, never leaked back), allowed-host restrictions, quotas, grants for execution, and all the boring-but-essential stuff that makes “server-side automation” safe enough to offer to strangers. Then Triggers sit on top: cron, runtime events, manual fire, HTTP webhooks. Triggers can call webhooks, Discord webhooks, and can execute pulses. Everything is rate-limited and quota’d, because otherwise the platform becomes a liability. That’s the platform. Now… what’s actually “done” enough to call V1? The V1 milestones (aka: what exists today) I’m not going to list every tiny change. This is the “if you’re new here, this is what Vibecodr can do right now” list. Creation & publishing Studio exists as a real workspace: create a new capsule, edit files, run it, and publish. Remix flow exists: you can start from someone else’s work (or your own) and fork it into a new direction. Import pipeline exists: you can bring in code from GitHub or a ZIP upload, it gets analyzed, safety-checked, bundled with esbuild, and stored as an artifact the runtime can load. Playing & sharing Player exists as a real product, not a demo: immersive mode, console, stats, run tracking, mobile layout, “arcade” vibes. Embeds exist in a way I actually trust: they run on a separate origin, with sandboxing, and support “live” embeds or pinned snapshot embeds. Social & discovery Feeds exist (Following / Discovery / For You), and they’re not random. The ranking is built around the stuff that matters for this platform: not just likes, but real interaction signals like runs, completions, remixes, shares. The goal is that “things people actually play” rise, not just things people scroll past. Search exists, and it’s real search (not a fake filter). Automation & server-side power Pulses are real: create, edit, deploy, run; manage secrets safely; archive/restore to manage limits. Triggers are real: runtime event / webhook / cron / manual, and they can execute actions (webhook / Discord / pulse execution). (Email is intentionally not enabled yet — it exists in the schema, but I’m not shipping it until it’s actually done properly.) Safety, trust, and the unsexy work This is the part nobody sees, but it’s most of the work if you want a platform where strangers run code. Capsule attachment and remix rules are strict. Ownership rules, quarantine rules, published-only rules. No weird loopholes where private stuff accidentally becomes public because a post did something unexpected. Embeds are isolated by design (separate origin), not “hope and vibes”. Rate limiting exists. Quotas exist. Budget enforcement exists. Security hardening has been a constant theme: stronger protection against the usual web attack categories (XSS/SSRF/etc), safer fetch patterns, safer file handling, safer logging, safer defaults. Admin/ops (because this can’t be a toy forever) There are real admin surfaces for moderation/flagging, analytics, errors, and operational maintenance. A lot of the platform has tests specifically around safety and abuse edges, because those are the edges that actually matter. The part I don’t want to gloss over V1 is not “done”. But it is real. It is a full loop: create → publish → play → share → remix. Plus the server-side half (pulses + triggers) that turns a vibe from “cool interactive thing” into “something that can actually do work”. And I want to say this plainly: I built this because I didn’t want to keep building alone. I don’t want the only proof of progress to be a commit graph. I want to build where people can actually touch the work, respond to it, remix it, and make it feel alive. What happens next I’m going to keep this devlog human. Not corporate. Not fake-polished. If something breaks, I’ll say it broke. If something ships, I’ll say what it actually unlocked. And if you’re reading this and thinking “I’m one of those people, I’ve been looking for this too” — then please make something. Even something tiny. Especially something tiny. Post it. Let me see it. Let me feature it. Let’s turn Vibecodr into the place we were all trying to find. That’s Devlog 1. — Braden