[{"data":1,"prerenderedAt":279},["ShallowReactive",2],{"blog-\u002Fblog\u002Fwhy-every-task-needs-a-preview-url":3},{"id":4,"title":5,"author":6,"body":7,"cover":263,"description":264,"draft":265,"extension":266,"meta":267,"navigation":268,"path":269,"publishedAt":270,"seo":271,"stem":272,"summary":273,"tags":274,"updatedAt":277,"__hash__":278},"blog\u002Fblog\u002Fwhy-every-task-needs-a-preview-url.md","PR Preview Deployments: Why Every Task Needs One","Veflow team",{"type":8,"value":9,"toc":252},"minimark",[10,19,22,29,34,37,70,73,83,87,93,96,99,103,106,111,114,119,122,127,130,134,141,147,150,170,177,181,184,187,216,222,226,229],[11,12,13,14,18],"p",{},"There's a moment in every PR review where you read the diff, the change looks reasonable, and a small voice asks: ",[15,16,17],"em",{},"\"but does it actually work?\""," PR preview deployments exist to answer that question — a live URL tied to the pull request, so you can click through the actual change instead of approving a diff on faith.",[11,20,21],{},"Most of the time, you ignore the voice. You squash-merge, watch CI go green, and move on. Sometimes the voice was right and you find out in production at 11pm.",[11,23,24,25],{},"We think the voice is right more often than it gets credit for, especially when an AI agent wrote the diff. And we think the fix is small: ",[26,27,28],"strong",{},"every task should ship with a URL that opens the running change.",[30,31,33],"h2",{"id":32},"what-pr-preview-deployments-actually-mean-done-right","What PR preview deployments actually mean, done right",[11,35,36],{},"The pattern is already familiar from frontend deploys — Vercel and Netlify have shipped per-PR previews for years. The version that matters for AI-coded workflows is a stricter take:",[38,39,40,47,58,64],"ol",{},[41,42,43,46],"li",{},[26,44,45],{},"The URL exists by the time you'd want to click it."," Not behind a manual approval. Not behind a passing CI suite. The preview is among the first artefacts of the PR, not the last.",[41,48,49,52,53,57],{},[26,50,51],{},"The URL is stable for the life of the PR."," Every push refreshes the same address. The link you paste in a message early in the PR keeps working at the end. Veflow keys the preview to the task — ",[54,55,56],"code",{},"\u003Cteam-slug>-\u003Ctask-id>.preview.veflow.ai"," — so it doesn't move.",[41,59,60,63],{},[26,61,62],{},"The URL runs the whole app."," Not the changed component in isolation. Not a screenshot. The actual app, with the change applied, in something close to production conditions.",[41,65,66,69],{},[26,67,68],{},"The URL is reachable from the task."," One click from the brief, not three from a deploy dashboard.",[11,71,72],{},"This isn't a CI feature or a deploy feature. It's a workspace feature — and that's the bit most products miss.",[74,75,80],"media",{"aspect":76,"hint":77,"kind":78,"src":79},"aspect-[16\u002F9]","A Veflow task pane with the preview URL pinned in the topbar, status banner showing 'live preview is up', diff visible below","Screenshot","\u002Fblog\u002Finline\u002Ftask-with-preview.png",[11,81,82],{},"What \"preview per task\" looks like in practice — URL, live status, and the diff in one frame.",[30,84,86],{"id":85},"why-this-is-more-important-for-ai-written-code-than-human-written-code","Why this is more important for AI-written code than human-written code",[11,88,89,90],{},"When a human writes code, the writer has already run it locally. The mental model is: ",[15,91,92],{},"\"I saw it work on my machine; the PR is asking the reviewer to confirm it works on theirs.\"",[11,94,95],{},"When an agent writes code, there is no \"the writer ran it locally.\" The agent ran the tests it wrote, against the cases it thought of. The reviewer doesn't get the writer's lived experience of \"yeah, I clicked through the form, it submits.\"",[11,97,98],{},"A preview URL is how the reviewer recovers that experience. You click the link, you click through the form, you find out. Without it, every AI-generated PR is being approved on the strength of a transcript.",[30,100,102],{"id":101},"what-changes-when-you-have-it","What changes when you have it",[11,104,105],{},"Three things, in our experience.",[11,107,108],{},[26,109,110],{},"1. You catch a class of bugs that tests don't.",[11,112,113],{},"Tests verify the cases you thought of. Previews surface the cases you didn't — the weird empty state, the layout that breaks at 320px, the loading spinner that flashes on a 200ms connection, the dropdown that opens behind the modal. None of that shows up in a diff. All of it shows up in a preview.",[11,115,116],{},[26,117,118],{},"2. You stop asking the agent for screenshots.",[11,120,121],{},"A surprising amount of \"show me what this looks like\" friction with AI coding tools is teams trying to recover preview semantics without a preview. The agent generates a screenshot; the screenshot doesn't reflect interactive state; the team asks for another; the agent generates a different screenshot. A URL fixes this.",[11,123,124],{},[26,125,126],{},"3. Review becomes faster, not slower.",[11,128,129],{},"Counter-intuitive, but real. When the preview is one click away, reviewers stop \"saving it for later\" because they don't need to reproduce locally. The PR closes faster because the question \"does it work?\" gets answered in the same sitting.",[30,131,133],{"id":132},"show-every-preview-the-pr-carries-not-just-ours","Show every preview the PR carries, not just ours",[11,135,136,137,140],{},"Plenty of teams already wire Vercel, Netlify, or Render previews to their PRs. When an agent opens a PR into a repo set up that way, ",[15,138,139],{},"replacing"," those previews with our own would be the wrong move — the team's existing infra produces the URL they already trust, in a domain they've already configured. We'd just be shouting over it.",[11,142,143,144],{},"So Veflow does something simpler: ",[26,145,146],{},"it shows all of them, side by side, and lets you pick.",[11,148,149],{},"The mechanics:",[38,151,152,158,164],{},[41,153,154,157],{},[26,155,156],{},"We listen for preview comments on the PR over a GitHub webhook."," The moment Vercel, Netlify, Cloudflare Pages, Render, Chromatic — any of the known preview providers — posts or edits a comment with a URL, the URL appears in the task. No polling, no timeout, no \"we'll look in three minutes.\"",[41,159,160,163],{},[26,161,162],{},"Every preview lives in a dropdown on the task's preview banner."," One row per source, each with the bot that posted it, when it landed, and a click to open. The reviewer picks whichever one matches what they're reviewing — the app, the design system, the docs site.",[41,165,166,169],{},[26,167,168],{},"Veflow's own preview shows up as one row among the others."," It's there as a fallback for repos that don't have external preview infrastructure, and as a backup if an external preview build fails. It's never positioned as the \"canonical\" preview when the PR already has its own.",[74,171,174],{"aspect":76,"hint":172,"kind":78,"src":173},"A Veflow task banner with the source dropdown open: Vercel, Netlify, Chromatic, and Veflow each shown as a separate preview the reviewer can open, with the bot identity and time-since-post","\u002Fblog\u002Finline\u002Fpreview-source-banner.png",[11,175,176],{},"The dropdown is the picker — every preview the PR carries, in one place.",[30,178,180],{"id":179},"what-it-takes-to-ship","What it takes to ship",[11,182,183],{},"Most products don't have preview-per-task because preview infrastructure is genuinely hard.",[11,185,186],{},"You need:",[188,189,190,193,196,199,209],"ul",{},[41,191,192],{},"A way to provision an isolated runtime per branch in seconds.",[41,194,195],{},"A URL scheme that survives rebuilds.",[41,197,198],{},"An idle-down story so previews don't pile up indefinitely — ours sleeps after about thirty minutes of inactivity and can be brought back from the task with one click.",[41,200,201,202,205,206,208],{},"A scope decision about what kinds of projects you actually serve. Veflow's preview container runs browser-facing web projects — anything that boots with ",[54,203,204],{},"npm run dev"," and serves on a port. Mobile builds, native desktop apps, background workers without an HTTP surface, and anything that needs a build step we can't drive from ",[54,207,204],{}," aren't supported in the preview — they still open PRs, they just don't get a Veflow-hosted URL. (If your team's CI ships an external preview for one of those, the dropdown picks it up anyway.)",[41,210,211,212,215],{},"The judgement to ",[15,213,214],{},"not"," shout over preview infrastructure the team already has, and a way to surface what they do have without picking a fight about which URL is \"the\" URL.",[11,217,218,219],{},"We built all of this into Veflow because every other shortcut we considered chipped away at the property that mattered: ",[15,220,221],{},"the reviewer sees the actual change running, every time.",[30,223,225],{"id":224},"how-to-start-using-it-today","How to start using it today",[11,227,228],{},"If you're already on Veflow, the loop is already on. Three rules to know:",[38,230,231,240,246],{},[41,232,233,236,237,239],{},[26,234,235],{},"The preview comes up after the agent opens the PR."," Not before. The agent finishes its work, opens the PR, and the same container the agent ran in rolls into ",[54,238,204],{}," to serve the preview. First boot is usually 30–120 seconds — the banner tells you which phase the container is in (cloning, installing, starting) instead of leaving you guessing.",[41,241,242,245],{},[26,243,244],{},"External previews land automatically."," If the repo has Vercel, Netlify, Cloudflare Pages, Render, or Chromatic wired up, you don't configure anything — Veflow picks up their PR comments over a webhook and they show up in the dropdown the moment they're posted. The list updates live as more arrive.",[41,247,248,251],{},[26,249,250],{},"The URL is the task's URL."," It's keyed to the task, not the run, not the branch. Every push refreshes the same address. Stop the preview from the task to free the container; restart from the same button when you need it back.",{"title":253,"searchDepth":254,"depth":254,"links":255},"",3,[256,258,259,260,261,262],{"id":32,"depth":257,"text":33},2,{"id":85,"depth":257,"text":86},{"id":101,"depth":257,"text":102},{"id":132,"depth":257,"text":133},{"id":179,"depth":257,"text":180},{"id":224,"depth":257,"text":225},"\u002Fblog\u002Fwhy-every-task-needs-a-preview-url.png","There's a moment in every PR review where you read the diff, the change looks reasonable, and a small voice asks: \"but does it actually work?\" PR preview deployments exist to answer that question — a live URL tied to the pull request, so you can click through the actual change instead of approving a diff on faith.",false,"md",{},true,"\u002Fblog\u002Fwhy-every-task-needs-a-preview-url","2026-06-03",{"title":5,"description":264},"blog\u002Fwhy-every-task-needs-a-preview-url","PR preview deployments give every pull request a live URL to click — here's why that matters even more when an AI agent wrote the code.",[275,276],"product","philosophy",null,"l8WUb3FI37WWpoHtcNlj8LwgE3EBoNwdFo-O4ZoC9aE",1785474881798]