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 • Jun 10, 2026 • DEVELOPER NOTES
Runtime Bump Log: v0.2.13 to v0.2.92
March 29 to June 10, 2026 It's been a while since the last bump log, v0.2.13, back in late March. Since then the runtime has shipped sixty-plus versions. That's not version inflation. Every one of those numbers is a real, immutable asset bundle that went out to production, because that's how our runtime works: when a vibe loads, it pulls a frozen, checksummed set of runtime files pinned to an exact version. Nothing mutates underneath you. When we fix or improve anything in that layer, the version moves. So here's everything that happened between 0.2.13 and 0.2.92, grouped by what we were actually trying to accomplish, because the version numbers tell you when, but not why. Custom domains grew up, v0.2.14 to v0.2.31 The first big arc of this stretch was making vibes on their own domains, the vanity host lane, as trustworthy and boring-to-boot as vibes inside the feed. Early April was a hardening campaign. We moved the vanity host bootstrap from inlined page logic into a real shipped runtime asset, built and verified through the same pipeline as everything else, v0.2.15 to 0.2.16. Then we rebuilt how the frame starts: the page you get is now a small dynamic envelope that carries the security policy decisions, while a versioned frame-loader.js owns the actual boot sequence: import maps, runtime scripts, and bundle activation. Config no longer rides in spoofable query params. It travels through signed, header-only transport, and the loader reads its CSP nonce from its own script element instead of leaving it sitting in the DOM. Why so much effort on a boot path? Because a runtime that sometimes starts is worse than one that fails honestly. This era also rewrote our health model, v0.2.18. A frame that's merely alive no longer counts as healthy. We require strong functional probes registered ahead of user code, and we fail closed on weak launches instead of letting a half-booted vibe sit there looking fine. Recovery loops got caps and backoff, v0.2.24, so a struggling frame retries gracefully instead of thrashing. Faster opens, stricter bundles, v0.2.32 to v0.2.40 Mid-April was about the first open. We unified who owns "where do this vibe's files come from" across the manifest, vanity, and runtime loaders, started edge-caching immutable public bundles, and made public mirror readiness converge before first open instead of during it, v0.2.32. The practical result: public vibes start faster, and the runtime never has to guess which storage lane an asset belongs to. The strictness mattered just as much as the speed. A series of fixes, v0.2.36 to 0.2.39, locked root-relative assets, the /sprites/player.png kind of path your code naturally writes, firmly inside the vibe's own bundle plane, so an authored URL can never wander out of its sandbox and into our control plane. CSS readiness became a real invariant for both the React and HTML runtimes: a vibe doesn't declare itself interactive while its styles are still in flight, which is the difference between "loaded" and "flashed unstyled garbage, then loaded." The presentation engine: teaching the player how your app wants to be seen, v0.2.41 to v0.2.79 This was the longest and most user-visible campaign of the whole stretch, roughly twenty-five versions across April and early May aimed at one deceptively hard question: when the player shows your vibe, should it letterbox it like a game or flow it like a document? We started by writing the answer down as a shared contract: stage versus document presentation, agreed on by the player, the focused overlay, Studio preview, and custom-domain hosts, v0.2.41. Then reality showed up, one app shape at a time. Fixed-size canvas scenes wrapped in author chrome, v0.2.47 to 0.2.48. Imported Vue and Vite apps that lock page overflow, so their full height is invisible to naive measurement, v0.2.61 to 0.2.66. Yes, six versions in one day. This shape fought back. p5 sketches in global mode, which need their setup and draw functions discovered after script replay, v0.2.58. Responsive canvas wrappers in compact overlays that flapped between modes, v0.2.67 to 0.2.69. Apps that report their settled size only after async framework layout, v0.2.76 to 0.2.77. Each fix followed the same philosophy: measure what the author actually built, reject pathological geometry instead of rendering a centered sliver, v0.2.42, and fail open to document mode when unsure. A scrollable page is always usable; a wrongly letterboxed one isn't. The campaign closed with presentation certification, v0.2.79, turning all those hard-won classifications into a verifiable contract so they can't silently regress. The payoff is invisible when it works, which is the point: your fixed-size game stays a crisp letterboxed stage on a phone and a monitor alike, and your full-page app fills the frame without clipping its bottom controls. Quality-of-life in the same window, v0.2.50 to v0.2.57 A few things shipped between presentation rounds that deserve their own mention. The runtime now consults the bundle manifest to rewrite image requests whose extension doesn't match what was actually uploaded, the classic "code says .png, build shipped .webp" mismatch, before the browser burns a guaranteed 404, v0.2.50. Private vibes got continuity: bundle access grants refresh before they expire and flow into already-mounted frames, so a long session on a private vibe no longer loses runtime state at the grant boundary, v0.2.57. Pulses got their own execution plane, v0.2.70 to v0.2.73 In early May we restructured how Pulses, the backend companions to vibes, meet the public internet. Pulse execution moved onto the vxbe.space plane with dedicated routing and hardened control boundaries between the runtime, dispatch, and the API. We also wrote the invocation limits down publicly, 256 KiB requests and 1 MiB responses, instead of letting people discover them by surprise. The principle: vibes and their backends should live on the user-content origin, cleanly separated from the platform that hosts them. It is the same isolation story the iframe sandbox tells, extended server-side. Making imported HTML behave like it was born here, v0.2.80 to v0.2.90 May's quieter arc was correctness for imported apps. The HTML runtime replays your document's scripts inside the sandboxed frame, and replay has subtle differences from a normal page load. We closed them one by one: module metadata is preserved through replay, v0.2.81; minified bundles get their module imports rewritten correctly, v0.2.82; and scripts that register DOMContentLoaded listeners during replay, which would have fired naturally in normal page order, now get captured and flushed before the runtime declares interactivity, v0.2.83. That last one is the kind of bug users experience as "it just doesn't start," with nothing in the console to explain why. The v0.2.84 to 0.2.90 wave bundled runtime artifact persistence, import-build improvements, and the late-May Pulse invocation and worker platform release. Four bumps landed in a single release window as that platform work converged. 3D, natively, and a quieter console, v0.2.91 to v0.2.92 The newest bumps land two things. First, the runtime now ships its own version-matched copies of the three.js glTF decoders: Draco, KTX2/Basis, and meshopt, v0.2.91. Compressed 3D models decode from first-party, checksummed runtime assets instead of someone else's CDN, which means they keep working under our strict sandbox policies and they're pinned to the exact three.js version they were built for. If you're making 3D vibes, this is the floor that makes serious model compression "just work." Second, the runtime is now silent in production, v0.2.92. The boot-time console logs that helped us develop the runtime are gated behind a dev-only debug flag, so your vibe's console belongs to your code. Small change, real respect: the console is part of your creative surface, not ours. Where this leaves us Eighty versions ago the runtime could load a vibe. Today it can load a vibe on the feed, in the player, in Studio, in an embed, or on your own domain; figure out whether your creation wants to be a stage or a page and present it that way on any screen; replay imported HTML apps with their module semantics, late listeners, and asset paths intact; decode compressed 3D models from first-party assets; keep private state alive across access boundaries; and fail closed, honestly, when something is actually wrong, all while keeping user code in a cross-origin sandbox that never touches the platform it runs on. None of these sixty-plus bumps was a feature checkbox. Each one came from watching a real vibe do something the runtime didn't yet handle gracefully, and refusing to leave it that way. That's the standing commitment: the runtime is the floor every creation on Vibecodr stands on, and we will keep pouring concrete into that floor, version by version, weird edge case by weird edge case, because the best thing we can build for the people making things here is a runtime they never have to think about.
-
@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 • 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 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 • 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 • 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 • 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.