Skip to main content
Sites lets you build a website from a conversation — you describe what you want, the expert designs, codes, and self-checks it, you confirm in the preview, and you click publish in the UI.
The expert cannot publish. Its deploy tool only raises a hand to say “I’m ready”; the actual publish must be confirmed by you in the Website panel. This isn’t ceremony — publishing is an irreversible public action. Once you know this, “it said it deployed but the URL doesn’t work” stops being a mystery.

​
Workflow

1

Enable the Sites plugin

Sites is opt-in. Only after you enable it does the expert get website tools; otherwise it just writes plain HTML files, and that path can’t be published.Sites also needs a sandbox (sandbox_mode != none). In conversations without one, the plugin doesn’t activate.
2

Describe your site

A single sentence works, so does a detailed page plan. Expressive requests (brand pages, portfolios) and functional ones (dashboards, form tools) take different branches from here.
3

Pick a design direction (expressive requests)

The expert first builds 3 real, clickable hero variants under the temporary /profy-design/<name> namespace, then shows you a card to choose from. You’re looking at actual pages, not descriptions.Once you pick, the decision is written to .profy/site-design.json in the workspace. That file is the single source of truth for design decisions — the expert must read it back later rather than re-deriving intent from the chat log.
4

Live preview

The Website panel opens automatically and the dev server starts on demand (lazy start) with HMR, so code changes show up immediately.
5

Iterate

Just say what to change in the conversation. The expert uses browser tools to take real desktop and mobile screenshots for visual self-checks instead of only reading its own code.
6

Confirm publish

The expert requests publish → you click deploy in the panel → enter a site slug → confirm. Only then does the build and upload begin.

​
Design-direction constraints

site_design has two modes, chosen by the kind of request: Hard limits per field:
Image generation requires your authorization, and the card shows an estimated cost. Authorization locks in the image model that was active at that moment; if the model changes before generation, the batch is rejected as model_mismatch and asks for a fresh estimate — so you never authorize at model A’s price and get charged at model B’s.

​
Asset size budget

The asset constraint is attached to the directory, not the tool, so there’s no way around it — downloading with curl counts exactly like downloading with a tool. Three entry points measure this budget, with different attitudes:

​
Three gates before publish

When the expert calls deploy, three checks run. If any fails you don’t get a publish card — you get told where it’s stuck: The second one earns its keep — those direction variants are scratch work for your choosing, and shipping them alongside the real site is awkward.

​
Publish pipeline numbers

Publishing runs two channels: files upload to object storage (the real serving layer, delivered via CDN), plus a best-effort EdgeOne preview. EdgeOne failure does not fail the publish, because object storage is what actually serves traffic. The final URL looks like https://<your-slug>.site.profy.cn.

​
Billing

The dominant cost is usually iteration rounds, not publishing. “Agree on the plan before coding” genuinely saves money here: getting the structure wrong means reworking it, which burns the whole coding phase’s tokens a second time.

​
Failure modes and troubleshooting

​
What you can build

The archetypal expressive request, so it goes through 3-direction selection. Good fit for seeing variants before committing to a style.
Hero, features, testimonials, CTA. Asset-hungry, so mind the 3-generated-asset cap — cover the rest with offloaded URLs.
Time-sensitive and structurally simple; usually settled in one or two rounds.
Anything with interaction logic. Actually click through the preview before publishing — static screenshots don’t surface interaction bugs.
Structured content sites. For many pages, build in batches; asking for a dozen pages at once spreads the expert thin.

​
Technical notes

  • The framework is TanStack Start; build output lands in .output/
  • The working directory is /home/user/workspace/web/ (persistent); /home/user/project/web/ in the image is a read-only seed — don’t edit there
  • The dev server starts on demand, so non-website conversations never pay for it
Published sites are publicly accessible with no access control. Make sure the content holds nothing sensitive, and click through every page before publishing.

End-to-end: publish a site

Full walkthrough from request to live URL

Image generation

Batch asset generation and its billing

Limits reference

Every hard limit on the platform

Sandbox

Code execution environment and persistence rules