Deploy a public page

You built a project. It runs in the Builder. Now somebody else needs to use it: a teammate, a client, your mum, a link on Twitter. The last thing you want is to give them the Builder with all the nodes and wires.

Click Publish. Pick a slug. Weft gives you back a URL at /p/<username>/<slug>. Open it. That is your project, rendered as a clean page, with only the fields you chose to expose and only the outputs you want people to see.

Two kinds of deployments

A deployed page behaves in one of two ways, and the two are mutually exclusive today. Which one you get depends on whether the project has a trigger node.

Manual run. Project with no triggers. The visitor lands on the page, fills in whatever fields you exposed, clicks Run. One execution per click. The result appears on their screen, and each visitor has their own private view. See the visitor sessions section below for how much of that view is remembered across page loads.

Trigger broadcast. Project with at least one trigger (a webhook, a cron schedule, anything that fires without the visitor pressing a button). There is no Run button on the page. Instead, whenever the trigger fires, everyone viewing the page sees the latest result update at roughly the same time. The page polls the server for new trigger-fired runs every three seconds.

A project cannot be both today. Adding a trigger node to a previously manual-run project flips the deployment into broadcast mode on the next publish.

Choosing a slug

The slug is the last part of the URL. It has to be URL-safe (lowercase letters, numbers, dashes) and unique among your published projects. You can change the project later but not the slug: the URL stays stable for people who bookmarked it.

The full URL is /p/<username>/<slug>. On OSS local mode you have one built-in user called local, so the URL is /p/local/<slug>. On WeaveMind Cloud, your username comes from your account and you need to set one before you can publish, the Publish modal will tell you if you have not.

A deployment is a clone, not a snapshot

This is the piece most people expect to work one way and actually works another. When you click Publish, Weft does not freeze a read-only snapshot of your project. It creates an independent clone: a full second project, with its own weft code, its own Loom, its own layout, its own triggers, its own infrastructure state. The builder project you were working in keeps living its life, the new deployment project lives separately.

Practical consequences:

• The builder keeps iterating. Edits in the builder do not touch the deployment. Your Tuesday morning experiment cannot accidentally take down the live demo.
• Re-publishing overwrites the clone. When you click Publish on the same slug again, the deployment's code gets replaced with the current builder state. Anything you edited directly on the deployment (see the next bullet) gets overwritten too. Re-publish means "ship the current builder state, lose any admin tweaks".
• You can edit the deployment directly. Click the Manage button on a deployment row and you open the deployment's own builder. Use this for admin-only fields: the API key on an LlmConfig, the production bot token, things the visitor should never see and the builder project should not store in plain text either.

If you set up an admin-only credential on the deployment and later re-publish from the builder, that credential gets overwritten. The dashboard flags this with trigger divergence detection so you can resync, but the rule is: admin tweaks on the deployment are not sticky across re-publishes.

Rate limits and pausing

Every deployment has a per-minute rate limit for visitor runs. You set it on the Publish form when you create (or re-publish) the deployment. Defaults are reasonable for most uses. If a visitor tries to run the project past the limit, they get a 429 and a short message asking them to wait.

To pause a live deployment, use the Pause button on the deployment row. That flips the deployment to Paused: the URL still resolves, but visitors see a maintenance message instead of being able to run the project. Click Resume to flip it back. Good for demos you only want up during a meeting, or for cutting off a runaway visitor without tearing the deployment down.

Do not try to achieve the same thing by lowering the rate limit to zero, the publish form rejects it. Pause is the right control for "turn off visitors", rate limit is the right control for "throttle them".

What visitors can actually do

A published page is stricter than the Builder. Visitors can only touch the fields you explicitly exposed through your Loom page design, and they can only see the output ports you explicitly marked visible. Everything else (credentials, system prompts, internal wiring, config fields you did not expose) is hidden by default.

Two separate safeguards protect sensitive values. Both apply at the same time.

• Values are stripped from the weft code before publish. Any field whose catalog type is password or api_key has its value removed from the weft source at publish time. The stripping happens in the dashboard, in the deployer's browser, before anything hits the backend. Your OpenRouter key on the builder project does not get cloned into the deployment.
• Visibility is force-clamped to admin at render time. Even if a Loom directive says visibility: visitor on a password or API key field, the runner visibility layer overrides it and treats it as admin-only. Visitors never see the input at all. This is a second line of defense: it runs whether you got the publish strip right or not.

The first protects the data at the serialization boundary, the second protects the display at the render boundary. For non-credential fields you want admins (but not visitors) to see, use visibility: admin in your Loom. To give a deployment real credentials so it can actually run, set them directly on the deployment project via the Manage button on the deployment row, not through the builder's publish flow.

If you need a specific field visible to visitors or a specific output to show up, that is Loom's job. Loom has its own page, go there next.

Visitor sessions (cloud only)

On WeaveMind Cloud, each visitor gets a per-visitor session that remembers their last inputs and their last outputs. Open the page, fill some fields, close the tab, come back later, the fields are still filled and the last result is still shown. A humanizer demo where people paste text and get results back stays usable across a page refresh instead of resetting.

On OSS local mode, there is no session endpoint. Every page load renders with empty inputs. This is fine for local dev and for self-hosted tinkering, but it is worth knowing: anything session-like you see on weavemind.ai hosted pages is cloud-side and not part of the open source drop.

Managing existing deployments

Once a project has at least one publication, the toolbar button label flips from Publish to Manage deployments. Clicking it opens the same Publish modal, and every publication for this project shows up as a row at the top, under "This project".

Each row shows:

• The public URL, with a Live or Paused badge next to it.
• A one-line stats strip: N views · N runs · updated <date>. Views count visits, runs count execution attempts.
• Four buttons: Manage (opens the deployment's own builder for admin-only edits, triggers, infra), Pause/Resume (toggles is_live), Overwrite (re-publish the current project state onto this slug), and a delete button.

You can have multiple deployments from the same project. Different slugs, different Loom designs, same underlying weft code. Useful when you want one "internal" version with more fields exposed alongside a stripped-down "public" version, or when the same logic powers different landing pages.

Running locally

Publishing works on localhost the same way it works on the cloud. Click Publish on a local Weft instance, the page is available at http://localhost:5173/p/local/<slug>, no account, no deploy step, no separate hosting.

By default the dashboard dev server only listens on localhost, so only you can open the page. If you want a teammate on the same LAN to hit it, start the dashboard with the Vite --host flag so the dev server binds on every interface, and open the firewall on port 5173. Good enough for demoing in the room you are in, not a substitute for a real cloud deploy.