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
- Section: developer-notes
-
@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 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 • 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
-
@vibecodr • Feb 1, 2026 • DEVELOPER NOTES
Devlog -Vibecodr 1.1.0 (“Source & Cuts”)
I’ve been sitting on this update because it’s the kind of release that’s hard to describe without sounding like a changelog robot. But this one deserves a real post. So: I’m calling this push Vibecodr 1.1.0. Not because everything is “done.” Not because it’s “perfect.” But because this release changes how it feels to build here. V1 was: the loop exists — create → publish → play → remix. 1.1.0 is: the loop gets memory. It gets lineage. It gets a workflow that doesn’t fall apart the second you want to iterate like a real builder. The emotional truth of 1.1.0 Up until now, Vibecodr has been… powerful, but kind of feral. You could make something, ship it, remix it, even automate stuff with Pulses — but there was this underlying vibe of: “Cool… but how do I keep this connected to my real work?” “How do I update without fear?” “How do I go back if I break it?” “How do I stop treating publishing like a one-way door?” 1.1.0 is me answering those questions properly. What shipped (in plain, human English) 1) Source is real now (GitHub App–backed) You can link a GitHub repo to a project without handing Vibecodr your personal tokens. Install the Vibecodr GitHub App (user or org) Pick a repo + branch + root folder Sync pulls it into a draft capsule Nothing auto-publishes. Nothing “mysteriously goes live.” This is important because it keeps the trust boundary clean: your repo stays your repo, Vibecodr stays a runtime + studio + publishing layer, and you don’t have to do weird credential gymnastics to connect the two. Behind the scenes, this also meant building the boring but necessary backbone: webhooks (signed), idempotency, push coalescing, safe zipball fetch paths, D1 tables, feature flags — all the stuff you don’t notice until it’s missing and everything breaks. 2) Cuts: version history that doesn’t punish you This is my favorite part of the release because it changes the psychology of shipping. Cuts are Vibecodr’s version history: you can see past versions of a vibe, and you can “revert” without rewriting history. Not “delete and pray.” Not “upload a new thing and lose the old thing.” More like: append-only, git-revert style. And it’s wired into the places you’ll actually use it: Player now has an author-only Versions tab Settings has a Versions page Embeds can be pinned to a specific cut (so sharing can be stable even while you keep iterating) This is one of those features that makes a platform feel less like a toy and more like a home. 3) Pulses got more “normal” (Node.js compatibility) I’ve been slowly pushing Pulses toward “feels like server-side code you already understand” while still keeping the sandbox story intact. 1.1.0 upgrades Pulses with Node.js compatibility support, including: node:http / node:https node:fs as a virtual temp filesystem (not a full disk, not a footgun — but enough to support real patterns) And the docs now spell this out clearly, because the worst thing a platform can do is imply something works and let you discover the edge cases the painful way. 4) More obvious “edit my existing vibe” entry points Small change, big UX impact: From the Player you can go Manage → Open in Studio From Settings → Versions you can jump straight into Studio It sounds trivial, but it reduces the friction of actually iterating. You shouldn’t have to hunt for your own work. 5) Docs got updated where they needed to Not “marketing docs.” Real docs. Pulses Node compatibility (what works, what doesn’t) Source + Versions flows Where to manage versions How to open Studio for an existing vibe The stuff you won’t notice (but you’ll feel) This release also includes a bunch of cleanup that’s basically me trying to make Vibecodr stop tripping over itself. Internal tokens centralized in Secrets Store and bound across workers (less drift, fewer “why is staging different?” problems) Outbound alerting moved behind internal-api with dedupe + sane routing Immutable caching for artifact bundle + manifest paths so runtimes start faster and cold loads hurt less Studio file loading fixes (no more weird “blank file” situations) Path normalization hardened across server/client/shared utilities (less “this worked yesterday but not today” energy) Runtime error events and admin error lookup got unified so debugging isn’t archaeology None of that is sexy. It is, however, the difference between “cool demo” and “I trust this.” Why I’m calling this 1.1.0 Because it’s not just more features — it’s a shift. V1 proved the concept. 1.1.0 makes it sustainable. Source linking means your work can live in the world the way you already work. Cuts means you can ship without fear. Node-ish Pulses means server-side power feels less alien. The backend hardening means I’m not asking people to build on vibes alone. What I want from you (if you’re here reading this) If you’ve been building on Vibecodr quietly… or remixing things but not publishing… or waiting because you don’t want to ship something you can’t update… This release is me saying: you can breathe a little now. Ship the weird thing. Ship the half-finished thing. Ship the thing you think only three people will care about. Because those three people are the entire point. That’s Vibecodr 1.1.0. — Braden
-
@vibecodr • Jan 23, 2026 • DEVELOPER NOTES
Devlog 002 — v1.0.1 (or: I love correctness and I hate how much work it takes to get there)
I want to talk about something that doesn’t usually show up in dev logs. I love correctness in code. I love when invariants are real. I love when invalid states are hard to represent. I love when the compiler, the linter, and the runtime all agree on what the system actually is. I love sleeping at night knowing that if something breaks, it’ll break loudly and close to the source. What I absolutely do not love is the labor it takes to get there. This release, v1.0.1, is mostly about paying that cost. After shipping v1.0.0 and opening Vibecodr up to real people, I tightened a lot of the screws. Stricter TypeScript settings. More explicit boundaries. Fewer “this probably won’t be undefined” assumptions. Less trusting my past self. More making the code prove things. That turned into… a lot of work. At one point I had over a hundred files touched, not because features were changing, but because the system was finally being forced to tell the truth about itself. Optional didn’t mean optional. Records didn’t mean structured data. Passing undefined around wasn’t harmless. Index signatures weren’t contracts. All the little lies you can get away with when you’re moving fast showed up at once. And here’s the honest part: if I didn’t care about correctness, I could’ve turned the flags off and been done in five minutes. But Vibecodr isn’t a throwaway project. It’s a platform where other people’s code runs, where authentication, automation, embeds, runtimes, and dispatch boundaries actually matter. I don’t want to debug “how did this become undefined” at 2am six months from now. I don’t want contributors to accidentally break things silently. I don’t want users to pay the price for my shortcuts. So I did the unglamorous thing. v1.0.1 includes a lot of hardening work that you won’t see directly: stricter, more honest TypeScript contracts cleaner handling of optional vs omitted data fewer stale closures and accidental re-renders more explicit runtime message parsing tighter boundaries between UI, runtime, and workers better guarantees around Pulses, routing, and dispatch None of this adds a shiny feature banner. None of it makes a great screenshot. Most of it is invisible when it’s done right. But it changes the shape of the system. On top of that foundation work, this release also shipped real, visible progress: Conversations is no longer a placeholder — it’s a real place now, with threads, voting, sections, moderation controls, and a UI that actually feels usable. Storage v2 continued to evolve into a real asset workflow instead of “just upload some files.” Player, Studio, and routing picked up a lot of stability and performance fixes that remove subtle friction and weird edge cases. All of that sits on top of the correctness work. That’s the point. I’m not pretending I enjoy the grind. I don’t. I enjoy the result. I enjoy when the system pushes back and says “no, you need to be explicit.” I enjoy the calm that comes after the chaos when everything finally lines up. v1.0.1 is that kind of release. It’s me choosing trust over speed, even when speed would be easier. It’s me building the kind of foundation I wish more tools had. And yeah — it’s me using every tool available (including AI) to get through the boring parts without burning out. If you’re using Vibecodr and nothing feels different today, that’s okay. That means it worked. The real payoff is in what doesn’t break next. Onward. — Braden