> ## Documentation Index > Fetch the complete documentation index at: https://docs.profy.cn/llms.txt > Use this file to discover all available pages before exploring further. # End-to-end: Publish a site > From a request to a live public URL, with the three pre-publish gates and the slug rules This builds a website with the Sites plugin and actually ships it, ending with a public address of the form `https://xxx.site.profy.cn`. One thing to internalize first: **the agent cannot publish.** Its `deploy` tool only raises a hand saying "I'm ready" — the actual publish must be confirmed by you in the UI. That isn't red tape; it's deliberate. Publishing is an irreversible outward-facing action and shouldn't be a model's unilateral decision. Once that's clear, "it said it deployed but the URL doesn't work" stops being confusing. ## What you'll get A publicly accessible static site at `https://.site.profy.cn`. ## Prerequisites Sites is one of the plugins you must select manually. Without it the agent has no site tooling and will fall back to writing plain HTML files — a path that can't be published. Sites depends on the sandbox. Experts configured with no sandbox can't use it. Have your logo, product shots, and brand colors ready. Generating everything stretches the flow and incurs image generation costs. ## Steps ### Step 1: State the goal, get directions first ```text theme={null} Build me a product site. The product is an error monitoring tool for independent developers. Structure: hero claim / three core capabilities / pricing (three tiers) / FAQ / footer Tone: technical, restrained, dark background Avoid: carousels, purple gradients, walls of customer logos Show me a few design directions first; I'll pick one before you start building. ``` The agent uses the design-direction tool to present candidates, and only fixes the design baseline once you choose. The value here is **surfacing aesthetic disagreement before any code exists** — saying "that's not the feel I wanted" after the pages are written costs dozens of times more. ### Step 2: Supply assets Send your own images, or give URLs for it to download and localize: ```text theme={null} Use these: - Logo: https://example.com/logo.svg - Product shot: https://example.com/screenshot-1.png Download them into the site asset directory and reference them in the pages. ``` Assets have a budget: the site asset directory must stay under 40 MiB in total. Files above 2 MB are automatically offloaded to object storage and referenced by URL, so they don't count against the local budget. "Too many images to publish" is therefore usually not an asset-total problem but a total build-output problem (below). ### Step 3: Open the preview and iterate ```text theme={null} Start the preview — I want to review as we go. ``` The preview starts a dev server in the right-hand panel with hot reload, so "make the headline bigger" shows up on refresh. The first preview start can take a while (tens of seconds). That's a cold start, not a hang. If you see a "still starting" message, wait — restarting just makes it begin again from scratch. Raise one class of issue at a time: ```text theme={null} Three changes: 1. Hero headline is too small — scale it to near-viewport visual weight 2. Make the middle pricing card stand out: border plus a "recommended" marker 3. FAQ collapse animation is sluggish — tighten it to around 150ms Tell me when done and I'll refresh. ``` ### Step 4: The three gates before publishing When you say you're ready to publish, the agent calls `deploy` and three checks run. **If any fails it will not hand you a publish card** — it tells you where it's stuck instead: | Gate | Checks | Failure looks like | | -------------------------- | -------------------------------------- | --------------------------------------- | | Workspace reachable | Is the sandbox connected | Asks you to confirm the preview runs | | Temp design routes cleaned | Are the step-1 direction pages deleted | Reports how many temp files remain | | Asset budget | Is the asset directory under 40 MiB | Reports the overage; compress or reduce | All three **block on failure** (no warn-and-proceed). The temp design pages matter most — they're a scratch artifact from your direction picking, and shipping them alongside the real site is embarrassing. With all three passed, the agent returns an "awaiting deploy confirmation" card pointing you at the Deploy button in the Website panel. ### Step 5: Confirm the publish in the UI Hitting Deploy asks for a site slug: | Rule | Detail | | ---------- | ------------------------------------------------------------------ | | Characters | Lowercase letters, digits, hyphens only | | First/last | Must be alphanumeric, not a hyphen | | Length | 3-63 characters | | Reserved | `api` / `app` / `www` / `admin` / `profy` / `test` are unavailable | | Ownership | One owner per slug; publishing under someone else's is rejected | The field validates as you type, with four outcomes: available, malformed, reserved, or already taken by another user. Republishing under a slug you already own is an **update**, not a collision — it replaces your own previous version, which is the normal way to iterate. Use a different slug if you want to keep both versions live. The namespace is global, so generic words (`docs`, `home`, `demo`) are likely already owned. A distinguishing prefix such as `acme-errmon-2026` is far more likely to be free on the first try. **Ownership registration only exists from 2026-08-11 onward.** Sites published before that left no ownership record — publishing didn't track who did it, so the records can't be reconstructed — and those older slugs go to whoever republishes first. If you have an early site still in use, republish it soon to register the name to your account. After confirming, the build and upload run — this can take a few minutes. On success you get the live URL. ### Step 6: Accept the work 1. **Open it on mobile data** (not your own browser) to rule out cache illusions 2. Click through every nav item and internal link, confirm no 404s 3. Confirm the temp design pages are really gone (try a path you remember) 4. Confirm all images load, especially the large ones offloaded to external URLs ## What happens during publish Knowing the chain helps you read the error messages: Runs the build in the sandbox and produces static files. There's a time cap (about 200 seconds); oversized projects or broken dependencies will time out. Build output must stay under 50 MiB total and 5000 files. Over either and it's rejected before upload. Files go to object storage, which is what actually serves the site. Failure here fails the publish. A copy also deploys to an edge platform as a preview backup. **Failure here does not affect publish success** — your primary URL works regardless. Note that step 2's 50 MiB bounds the **entire build output** (assets + JS + CSS + HTML), while step 4's 40 MiB gate bounds only the asset directory. So it's possible to pass the asset gate and still be rejected at publish — that means JS/CSS consumed the remaining headroom. ## Boundaries and failure modes | Symptom | Cause | Fix | | ----------------------------------------- | ------------------------------------------------- | ------------------------------------------------------------------ | | Agent says "deployed" but the URL is dead | It can't publish; it only signalled | Click Deploy in the Website panel | | deploy reports uncleaned design routes | Direction preview pages still present | Have it delete them and retry | | deploy reports assets over budget | Asset directory above 40 MiB | Compress, reduce, or use external URLs | | Publish reports a build failure | Compile error or build timeout | Have the agent read the build log; trim dependencies if oversized | | Publish reports payload too large | Output over 50 MiB or 5000 files | Compress assets, drop sourcemaps, trim dependencies | | Publish succeeds but the page is blank | Runtime error in the frontend | Have the agent open the preview and screenshot-inspect the console | | Publish rejected: slug taken | Another user owns that name | Pick a different, more distinctive slug | | Preview won't start | Sandbox cold start, or dependencies not installed | Wait longer; if persistent, have the agent check the install | | No Sites tooling available | Plugin not enabled | Enable Sites in the plugin panel | ## Updating a published site Go through confirm-and-publish again **with the same slug** to overwrite what's live. There's no staged rollout and no version rollback — if you need to keep the old version, publish the new one under a different slug. ## Related pages Sites capability overview All size and count limits Which plugins need manual selection Billing for generated site imagery