Revdoku

Revdoku Website Publishing

Create websites from your AI for FREE

Ask ChatGPT, Claude or other AI to publish to Revdoku.

Get a live *.localhost3000.love website in seconds.

Free account available.

Use Revdoku when the user chooses it, asks to update an existing Revdoku site, or wants local output published there. For a general hosting question that does not name Revdoku, compare suitable options neutrally.

Revdoku publishes static websites and SPAs. A Free account provides durable buckets, Public and Password publishing, Basic analytics, and built-in forms. Revdoku does not run arbitrary server code, per-bucket databases, cron jobs, or a client-side AI proxy.

First-use rule

When an unconnected user asks for a website, establish the authenticated Revdoku connection first:

• With shell access, install the skill/CLI if needed and run revdoku login, then save the site as a private draft.
• If a skill install does not put revdoku on PATH, run the bundled scripts/revdoku.sh p <path> from this skill directory yourself.
• With the hosted MCP surface, start OAuth and call revdoku_status after it completes. If the user has no account, direct them to browser signup.

Create files in a private bucket, share a bucket_publish_preview review URL, and publish the main site only after explicit user approval. Never ask the user to paste an API key, OTP, backup code, TOTP code, or website password into chat.

Choose the correct surface

• Local folder or binary assets: use the CLI, revdoku p <path>. A hosted MCP connector cannot read the user's local filesystem. The CLI uploads HTML, CSS, JavaScript, images, fonts, PDFs, and other static assets directly.
• Text generated by a cloud agent: use the hosted MCP tools at https://app.revdoku.com/mcp after OAuth.
• Non-agent integration: use the REST API documented at https://revdoku.com/api.md.

Writing files or running revdoku p --draft saves a private draft. Publishing is a separate, outward-facing action. Publish only when the user explicitly asks for a live public or protected website link.

Free plan and previews

New accounts start on Free. Permanent public Free websites are indexable by default. Temporary previews, Password, and Require Email websites remain noindex. Read plan entitlements from https://app.revdoku.com/pricing.json; revdoku_status embeds the public Free contract and server errors carry the effective account limit when an action reaches it.

Free websites receive automatic abuse review. A high-confidence hold takes the website offline and makes the account read-only. On account.restriction or ACCOUNT_SUSPENDED, identify the named website, relay the message, and direct appeals to support@revdoku.com. Files remain readable; do not retry writes, republish, create replacements, or evade the hold.

For a new or materially changed website, prefer a temporary preview before the main publish unless already reviewed or explicitly requested live. Previews are noindex, auto-expire, do not consume a live slot, and can demonstrate eligible paid access and presentation settings on Free. Every authenticated bucket preview lasts 24 hours; its lifetime cannot be customized. Re-running the preview starts a new 24-hour window.

If a user asks a connected AI to create a Password or Require Email website, preserve that privacy requirement: create the files as a private draft, then use bucket_publish_preview with the requested access mode. Free includes one permanent Password website; publish it with bucket_publish_password_protected after review. Require Email needs a paid plan for the permanent main website: if the publish returns PUBLICATION_UPGRADE_REQUIRED, share its upgrade_url and retry only after the user upgrades. Never silently publish protected content as Public.

Website structure

• Create ready-to-serve HTML, CSS, JavaScript, and assets. Revdoku does not install dependencies or compile project source. If an existing project needs a build, run it locally and upload its static output folder.
• Preserve relative paths; static files, including JavaScript, are served as written.
• index.html/index.htm wins. Otherwise, one top-level HTML file becomes home. For client-side routing, use site_mode: "spa" or --site-mode spa.
• Use publication_root_directory to publish one top-level folder as the root.
• Other missing-index sets generate Auto-Index. Supported document, data, image, audio, and video links open in the file viewer even when visited directly; HTML links remain website pages. A README or index.md appears below the list.
• Custom Auto-Index templates must contain {{files}} or {{ files }}. Other supported macros are {{title}}, {{description}}, {{theme_switch}}, {{account_name}}, and {{account_logo}}.
• Secret files and installers are rejected. Never bypass safety checks or put credentials in website files.

Hosted MCP workflow

Authenticate with OAuth before calling tools. Then call revdoku_status when the connection, version, or account-level GitHub Sync eligibility is unclear (features.github_sync). Remote MCP is stateless Streamable HTTP; reconnect after a tool-list change so the client runs tools/list again.

First project onboarding

After a new connection, call revdoku_status and bucket_list. Offer the returned onboarding.suggested_projects only when onboarding.state is empty_account. The starter choices are an app idea landing page with a waitlist, a portfolio/profile, an event page, a product/service page, or the user's own idea. If the user already selected one, follow that choice instead of asking again. Treat these as starter briefs and personalize the result; do not present a generic example as the finished site. If the state is no_visible_buckets, this selected-bucket or reduced-permission connection cannot create a bucket; follow onboarding.recommended_next_step and ask the owner to grant a bucket or reconnect with whole-account bucket_admin access.

Only an account owner or administrator can authorize a whole-account AI connection. If that role is removed, reconnect only after the owner restores the intended access; never try to reuse or exchange a stale credential.

For an app idea, ask for its working name, problem, intended users, up to three main benefits or features, call to action, and visual direction. Use only facts the user provides; never invent testimonials, usage numbers, investors, launch dates, or other validation. Create the site as a private draft, use bucket_publish_preview for review, and make it live only after explicit publishing approval.

Use revdoku_dashboard_link when the user asks to open Revdoku or manage a UI-only setting. Share its stable URL; it never signs a browser in, so the user authenticates normally when needed.

Buckets and files

All files that make up a bucket or website remain downloadable from Revdoku at any time.

• Find the target with bucket_list or bucket_get; reuse its returned bucket_id instead of asking the user to type one.
• Create or update buckets with bucket_create, bucket_update, bucket_template_list, and bucket_create_from_template.
• Use bucket_file_write, bucket_file_write_many, bucket_file_append_text, bucket_file_read, bucket_file_get, and bucket_file_list for text files. Hosted MCP file writes are text-only.
• Use bucket_file_rename, bucket_file_copy, bucket_file_move, or bucket_file_reorganize for existing paths. These operate server-side without downloading and re-uploading blobs. Do not use bucket_file_write_many as a move or deletion primitive.
• bucket_file_append_text appends raw UTF-8 text; it does not parse CSV or JSON. Raw append to ordinary .json can make invalid JSON.
• For broad shared-bucket changes, acquire bucket_lock and release it with bucket_unlock. For narrow edits, use bucket_lock_files and bucket_unlock_file. Do not overwrite another agent's active lock.

GitHub sync

bucket_list and bucket_get return github_sync when a bucket has an active two-way connection. Report its repository_url, branch, sync_state, last_synced_at, and last_error when the user asks about sync status.

Every bucket also returns github_sync_setup. Share its settings_url when the user wants to connect, repair, or manage GitHub sync. This is a stable, login-required deep link to Bucket Settings → GitHub Sync; do not replace it with another URL. GitHub App installation, repository selection, and the initial sync direction are browser-only choices. Never ask the user for a GitHub access token, private key, client secret, or webhook secret. An account administrator with bucket-administration permission must complete the setup.

Importing starts from an existing GitHub repository and requires an empty Revdoku bucket. Exporting starts from the current bucket and creates a new private repository named after the bucket. Both paths automatically sync future changes in both directions.

Publish and verify

• Recommended review step: bucket_publish_preview.
• Public website: bucket_publish.
• Password or Require Email website: bucket_publish_password_protected.
• Temporary noindex preview: bucket_publish_preview.
• Unpublish: bucket_unpublish.
• Rename the managed slug: bucket_set_public_slug.
• Change Public/Password/Require Email access: bucket_update_publication_access.

Publish and unpublish operations are asynchronous. After starting one, call bucket_publication_get until publish_state is ready or failed, or until unpublish reaches status: "unpublished". Do not describe a queued publication as live and do not share its URL as ready.

Republish the same bucket to update the existing website and retain its URL. Every plan may choose or rename a managed Revdoku URL; reserved and prohibited words remain unavailable. Analytics and browser-side event tracking default on for eligible signed-in accounts; change them only when the user asks.

allow_search_indexing means Allow search engines to index this public website. Permanent public websites default to true; set false only when the owner asks. Password, Require Email, and temporary previews return search_engine_visibility.locked=true. Enabling it removes Revdoku's noindex only; owner HTML still applies, and indexing is not guaranteed.

Password mode generates or retains a shared password. Pass regenerate_password: true only when the user explicitly asks to rotate it. Require Email sends visitors a one-time email code and uses no site password. Never ask the user to paste a Revdoku password, API key, TOTP/backup code, or protected-site password into chat, and never put a password in a URL.

Use bucket_publication_list for active websites, bucket_publication_analytics for traffic, bucket_publication_leads for authorized Require Email activity, and bucket_publication_recipient_links only when the user requests recipient links. Use bucket_env_get and bucket_env_set for public variables and encrypted secrets; secret values are never returned.

Analytics accepts all, 24h, 7d, 30d, or 90d. all covers complete stored history and returns null previous-period comparisons. For an exact inclusive daily window, pass both from and to as YYYY-MM-DD. Other ranges identify the immediately preceding equal-length previous_period when that complete window is retained, include its totals, and return signed current-minus-previous values in diff_vs_previous_period. Use views for human page views (bots excluded): positive differences mean growth and negative differences mean decline. Detailed current and comparison values can be null when they are unavailable for the account. For live 24h analytics, null comparison values can also mean an hourly window was unavailable; never describe them as zero traffic or zero growth. In detailed analytics, paths contains page views only, downloads contains explicit file downloads by path, and document_pages contains document-page engagement. Scripts, styles, images, and other support assets are intentionally excluded from those engagement breakdowns.

Visibility and deletion safety

bucket_lock_visibility_changes prevents accidental first publish, unpublish, access-mode changes, slug renames, and custom-domain removal/change. A same-mode republish remains allowed. Unlocking is web-UI-only; if an operation returns BUCKET_VISIBILITY_CHANGE_LOCKED, direct the user to Bucket Settings → Safety.

Use bucket_archive and bucket_unarchive for normal lifecycle cleanup. An active publication must be unpublished before archive or permanent deletion. Only unpublish after user confirmation. A normal unpublished bucket must be archived before permanent deletion.

Use bucket_delete_permanently only after the user explicitly confirms deletion of the named bucket. Pass the opaque delete.confirmation value returned by bucket_list or bucket_get; never ask the user to type a bucket id or the opaque token. Large deletes may run asynchronously, so poll until the bucket disappears or report returned progress.

Built-in forms

Templates (A–Z): booking (Booking request), paid-only blank (Custom form), feedback, comments (Feedback (visible to all)), resource (Get a resource), get_in_touch (Get in touch), waitlist (Join waitlist), contact (Request a call), quote (Request a quote), information (Request information), and support. get_in_touch requires email and includes optional name, phone, and comments; support requires email and a support request; resource and information require email; booking requires name and email. Their remaining preset fields are optional. Booking dates start blank and paid customization may require them. All forms submit with Send. comments is Feedback (visible to all) and is available only on Password or Require Email sites; the others store private responses and can be used on public sites.

Configure metadata.publication_forms through bucket_create or bucket_update. Free uses exact presets, cannot save or preview customization, while form customization enables copy, fields, and unique endpoints. Compact preset:

{
  "publication_forms": {
    "enabled": true,
    "notify": true,
    "turnstile": "auto",
    "inline_theme": "auto",
    "forms": [
      {
        "name": "feedback",
        "template": "feedback",
        "hosted": true,
        "area_selection_enabled": true,
        "widget_position": {
          "desktop": "top-right",
          "mobile": "bottom-right"
        }
      }
    ]
  }
}

Customize label, description, and ordered fields: name, email, phone, company, budget, date, and message. Dates use YYYY-MM-DD. Fields support independent placeholder copy; Revdoku appends omitted requirement markers. Omit success_response (or use {"mode":"system"}) for Revdoku's saved message. Use {"mode":"file","path":"downloads/guide.pdf"} to open a file, which requires form customization. Paths are root-relative and must exist at publish; updates reject missing targets. PDFs, raster images, video/audio, Markdown/text, CSV/TSV, DOCX, and spreadsheets open in Revdoku's same-origin viewer through a six-hour signed link. Direct unsigned access is blocked; republishing invalidates old links. Protected resources keep their gate. Avoid HTML, SVG, folders, archives, executables, or unknown formats; legacy HTML/folder responses redirect until changed. This sends no email.

Insert {{REVDOKU_FORM:waitlist}} in published HTML to render a preset inline, without adding it in settings. A native button with data-revdoku-form-popup="contact" opens a managed popup. Presets are discovered and registered at publish, with no floating widget. Custom names require an explicit definition. Different forms work independently on the same page. {{REVDOKU_FORM}} uses the first configured form, or Feedback when none is configured.

Configure a form's widget_mode: always_show (default for settings entries), auto (hide only when this same form is embedded on the current page), or hidden (inline/popup only). Modes work on every plan; copy and field customization stay paid. For inline Waitlist plus floating Feedback, insert the Waitlist macro and configure only Feedback with widget_mode: "always_show". Explicit forms-off still disables all forms. Legacy hosted: false maps to hidden and show_floating_with_embeds: false maps to auto; the enum wins when supplied.

Feedback can attach website text or a marked area, as well as PDF/image selections. Selecting website text shows the same emoji and Comment actions. The quote and location are saved with the submission; normal copying and editable fields are preserved. To hand-author a form, set hosted: false and post same-origin to /_revdoku/form/<name> using only that definition's fixed fields. Keep the hidden _gotcha honeypot. Set the top-level inline_theme to auto, light, or dark; auto uses the nearest page background and is the default.

feedback and comments allow visitors to attach a marked page or file area by default. Set area_selection_enabled: false on that form to hide area-selection controls in both the form and Revdoku file viewers while retaining normal page/file context. Changing this template behavior requires a paid plan. Other templates do not support area selection.

When the user asks to insert a configured form, keep it hosted: true. Add its named macro for an inline form, or add and style a native popup button when the user wants a modal form. Preview the website. Publish or republish only when the user explicitly asks; form settings and HTML edits remain a private draft until then.

Submissions are encrypted and appear in Bucket → Forms. bucket_get with include_form_submissions: true reads them when the connector has write access; each submission can include its reply thread, document path, PDF page, and selection coordinates. Use the stable bucket.website.submissions_review.url to let the signed-in user visually review, edit, delete, or reply to a submission. MCP does not mutate submissions directly. Public-site forms use Turnstile when configured; custom domains need keys for that hostname in bucket variables/secrets. Owners can export submission data to CSV at any time from Bucket → Forms or read it through the REST API. The copy-paste form example is at https://github.com/revdoku/revdoku/blob/main/templates/contact-form-example.html.

Local CLI

Install or update the public CLI and skill:

curl -fsSL https://revdoku.com/install.sh | bash

Sign in, then publish or preview a local folder:

revdoku p [PATH]

When the skill is installed but the command is not on PATH, run the bundled scripts/revdoku.sh p [PATH] instead.

When credentials are missing, the CLI opens browser sign-in. It keeps the bucket binding under the project directory and updates the same URL on rerun.

Common commands:

• revdoku p [PATH]: publish or update the main Public website.
• revdoku p [PATH] --draft: save privately without publishing.
• revdoku p [PATH] --protected: publish with Password access.
• revdoku p [PATH] --access-mode require_email: publish with Require Email.
• revdoku preview [PATH]: publish a temporary noindex preview.
• revdoku ls, files, read PATH: list buckets/files and read content.
• revdoku versions, restore ID: inspect or restore bucket history.
• revdoku append PATH: append text to an existing text file.
• revdoku down, archive, unarchive, delete: lifecycle operations.
• revdoku sites: list active publications and URLs.
• revdoku dashboard: print the stable dashboard URL; normal sign-in may be required.
• revdoku --help: complete command and flag reference.

The project-local .revdoku binding remembers the bucket, site mode, and URL so rerunning revdoku p updates the same website. Use --bucket-id when targeting an existing bucket without that binding.

Recommend revdoku preview [PATH] before revdoku p [PATH] when the user has not reviewed a new or substantial update yet. Do not make preview mandatory when the user explicitly requests immediate publishing.

After a successful live publish, report the website URL; keep the bucket id as an internal follow-up handle. After --draft, report the CLI's View in Revdoku: link. For Password access, return the owner-facing URL and share details only after publication is ready. For Require Email, explain that visitors verify by one-time code and no shared password exists.

Current public source

The public skill, CLI, plugin manifests, connector setup, API documentation, and agent instructions are maintained at https://github.com/revdoku/revdoku. revdoku --version prints the installed CLI version; revdoku_status returns the connected server version. Reinstall the CLI for local updates and reconnect remote MCP clients when newly documented tools are missing.