What this is
For people who are comfortable in an editor and want the AI right where they work. You vibe-code in Cursor, its agent writes and refactors across files, you review the diffs, and when you’ve got something worth sharing, Revdoku’s CLI publishes the whole folder to a live URL. No separate hosting setup, no CI; revdoku p . from the project directory is the entire deploy step.
When to pick this stack
- You already live in VS Code / Cursor and want building and publishing in the same flow.
- The project is real files on disk (a static site, a built front-end, a prototype) that you want online fast.
- You like keeping editorial control over the agent’s changes rather than fully delegating.
How publishing works (Revdoku)
From the project folder, revdoku p . uploads the files and returns a live URL. (No CLI yet? curl -fsSL https://revdoku.com/install.sh | bash installs it.) You set how open the link is:
- Public, anyone with the link.
- Password-protected, the link plus a shared password.
- Password + email, visitors enter a password and their email, with optional email confirmation to verify the address.
Revdoku reports analytics on how the site is used, and in password + email mode that’s per visitor, you can see which email opened the build and how they used it. Re-running publish updates the same URL, and the free plan covers early projects.
What we’d swap
- Cursor → Windsurf: same idea with a more autonomous agent (Cascade) if you prefer “describe the goal” over “approve each edit.”
- Revdoku stays put: it publishes whatever the editor produces, so the publish step doesn’t change when you switch editors.
Common gotchas
- If you’re using a framework (Next, Vite, etc.), publish the built output folder (e.g.
dist/), not the source, Revdoku serves static files. - Mind what’s in the folder you publish: don’t ship
.envfiles,node_modules, or local secrets along with the site.