Demos, repros, docs, reports, and agent output.

Deploy static output to a public URL.

WGW Deploy turns a local folder or single file into two links: a live URL for sharing and a pinned revision for exact reviews. No Git push, no hosting project, no dashboard detour.

Read docs

wgw-deploy

$ npx wgw-deploy --dir ./dist
✔ Project matched
✔ Static assets prepared
✔ Unchanged files skipped
✔ Deploy ready

project   bright-field-mqstr7zz
revision  26704cb219eb67f3
live      bright-field-mqstr7zz.wgw.lol
pinned    bright-field-mqstr7zz--26704cb219eb67f3.wgw.lol

How it works

Build output is not finished until someone else can open it. WGW Deploy makes the handoff a URL, not a repo instruction or a zip file.

Use the live URL when reviewers should see the newest deploy. Use the pinned URL when the exact snapshot matters.

Build

Produce static output: dist, build, public, generated docs, or a single HTML file.

Deploy

Run wgw-deploy from the project or point it at the folder you want online.

Share latest

Use the live URL when the next deploy should replace what reviewers see.

Pin evidence

Use the pinned URL when the exact deployed files need to survive later updates.

What you get

One deploy produces the two URLs teams actually need: one that moves forward, and one that never moves. Static serving stays separate from the deploy API.

Static output in

Deploy a directory or one file from whatever produced it: Vite, Astro, exported Next.js, generated docs, reports, or dashboards.

Live URL

Each local project gets a stable URL that moves to the newest deploy.

Pinned revision

Every deploy also gets an immutable URL for reviews, evals, bug reports, and handoffs.

Custom domains

Start on a wgw.lol subdomain, then map your own hostname when the artifact needs a real address.

Cloudflare asset serving

Static files are served from Cloudflare assets. The deploy API is not in the page request path.

Delete when done

Temporary previews can stay temporary. Remove the project when the review, repro, or handoff is finished.

Where it fits

Use it when the work is only useful if someone can inspect it now. Demos, repros, docs, dashboards, reports, and agent results all fit the same deploy path.

Put a demo in the thread

Build the app, deploy the output folder, and paste the live URL where the review is already happening. No repo access, localhost tunnel, or hosting project required.

Freeze a repro

Use the pinned revision when a bug report needs exact files. Later deploys can update the live URL without rewriting the evidence.

Publish generated docs

Put generated docs, reports, coverage pages, or static dashboards online without creating a separate site for each artifact.

Return agent work as a URL

Let a coding agent publish its generated page, repro, docs, or report and hand back something a human can open immediately.

Two links, two jobs.

The live URL belongs in pull requests, chat threads, docs, and client notes. It always opens the newest deploy for that project.

The pinned URL never changes. Use it when a bug report, design review, eval, or agent run needs to point at exact files, not "whatever was latest that day."

Agents produce pages, repros, docs, traces, screenshots, and apps. They need a deploy path they can call from a tool, without inventing a release process.

wgw-deploy gives agents llms.txt, a Skill, and a small CLI surface. One command and the output is live on the CDN.

Agents can deploy too.

llms.txt

Plain product context for language models.

Skill

Instructions for when to deploy and which command to run.

CLI

A small command surface that works from the agent's working directory.

Pinned URLs

A durable artifact for exact reviews, evals, bug reports, and handoffs.

Open source when you need to run it yourself.

wgw-deploy is FSL-1.1-ALv2. Read it, modify it, run it privately, and self-host it on your own Cloudflare account.

The license has a do-not-compete clause for offering wgw-deploy itself as a competing hosted deploy service. The code converts to Apache-2.0 after two years.