> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. # Deploy & publish > Create a hosted Preview, then publish the reviewed Production source Branch when you are ready to go live. Use deploy for a hosted Preview. Publish only when the reviewed change is on the site's Production source Branch and ready for public visitors. Existing sites use `main`. ## Deploy a Preview ```bash theme={null} fimo deploy -m "feat: update homepage" ``` `fimo deploy` works on the current Branch. It commits pending changes, pushes the Branch, updates its Preview, and returns the Fimo Studio URL. Add `--description` to say why you made the change. It becomes the body of the commit, and teammates and agents that later edit the same files read it, for example when their work conflicts with yours: ```bash theme={null} fimo deploy -m "fix: link to the agents page" --description "The routines page linked to /features/agnets, which returned a 404." ``` Deploy uses the description only when it has pending changes to commit. If you commit yourself, write the reason in your own commit message. By default, deploy waits for the sandbox to answer before returning the Studio URL. Use `--no-wait` only when you deliberately want to return after sync without that readiness check. Use your local dev server for everyday editing. Deploy at review points when you need a hosted link. ### When a deploy fails The error names the step that failed: pulling the Branch into the Preview sandbox, installing dependencies, starting the dev server, or the final readiness check. When the sandbox produced output, the error also includes the exit code and the last lines of that output, with credential-shaped values redacted, so you can fix the cause and run `fimo deploy` again. When the final readiness check fails, the message names what the check last saw, such as a dev server that stopped or an optimized dependency the Preview route was still delivering. With `--json`, read `error.details.failure_code`, `error.details.phase`, `error.details.exit_code`, and `error.details.log_tail`. `fimo logs` reads the Preview that is currently serving. A deploy that fails while preparing a replacement sandbox discards that sandbox, so the output on the error is the record of that attempt. A failed `--publish` still returns its publication ID. Run `fimo publish logs ` for the build output. A failed publication never replaces the version that is already live. Fimo also tells the people responsible: whoever published and the site's managers get an email that opens **Publish**, unless they turned off **Publication failures**, and **Publish** in Studio shows **Latest update failed** until a newer publication finishes. See [Publish in Studio](/docs/studio/publish.md#if-a-publication-fails). > [!TIP] > > Run `fimo preview url` to retrieve the hosted deployment without another commit or push. It waits while the current > generation builds. ## Publish production ```bash theme={null} fimo checkout main fimo deploy --publish ``` `fimo deploy --publish` pushes the configured Production source Branch and publishes it in one command. It does not run from another Branch. To publish the revision already on the Fimo remote without another deploy: ```bash theme={null} fimo publish fimo publish --label "Homepage launch" ``` A label helps you recognize the publication later. It does not change what gets published. > [!NOTE] > > If you are upgrading from Fimo 0.15, remove `--version`. Fimo now assigns each publication a stable ID; use `--label` > for an optional human-readable name. > [!WARNING] > > Publishing makes the site public. A plain `fimo deploy` remains a site-member Preview. ## Redirects and response headers Configure hosting rules in `.fimo/config.json`, not provider deployment files. The `hosting` object supports `redirects`, `headers`, `rewrites`, `cleanUrls`, and `trailingSlash`. ```json theme={null} { "hosting": { "redirects": [{ "source": "/old-pricing", "destination": "/pricing", "permanent": true }], "headers": [ { "source": "/(.*)", "headers": [{ "key": "X-Frame-Options", "value": "DENY" }] } ] } } ``` Redirects default to temporary. Use `"permanent": true` only for lasting moves; browsers cache it. An explicit `statusCode` of `301`, `302`, `307`, or `308` overrides `permanent`. Use a `host` condition to apply a rule to a particular hostname. For example, this redirects every `www` URL to the apex domain while preserving the path and query string: ```json theme={null} { "hosting": { "redirects": [ { "source": "/:path(.*)", "has": [{ "type": "host", "value": "www.example.com" }], "destination": "https://example.com/:path*", "statusCode": 301 } ] } } ``` Use `/:path(.*)` when the rule must include the homepage `/` as well as nested paths. Fimo preserves your `source` pattern as written; `/:path*` does not include the bare `/` on this hosting path. Connect both hostnames to the project before testing. A `host` condition matches the hostname the visitor requested, including a connected custom domain. Use `missing` instead of `has` to match requests that do not satisfy the condition. Host conditions also work on rewrites and response headers. Run `fimo validate` before deploying. Rules apply only to deployed sites; test them on a hosted Preview or published site, not a local dev server. > [!WARNING] > > Legacy static hosting ignores these rules. Contact support if they have no effect on your deployed site. ## When a site is unavailable A site that has been unpublished or taken offline can show “This site is unavailable” at its Fimo address. If you own the site, open Fimo to check its publication status. Restoring permission to publish does not put the site back online automatically; publish again when it is ready. Republishing restores the site at the same Fimo address, including a customized default address. ## CLI and Studio The CLI and Studio are two ways to publish the same site: * Use the CLI while working in the repository. It can push local changes and publish in one command. * Use [Publish in Studio](/docs/studio/publish.md) when the latest work is already saved and you want a visual publish action. Do not run both procedures for the same release. ## Continue the launch > [card] [Launch checklist](/docs/environments/launch-checklist.md) > > Check readiness, URL, live site, and recovery. > [card] [Custom domains](/docs/deploy/custom-domains.md) > > Choose the address visitors will use. > [card] [Analytics](/docs/deploy/analytics.md) > > Review traffic after publication. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.