Skip to main content
Use deploy for a hosted Preview. Publish only when the reviewed change is on the project’s Production source Branch and ready for public visitors. Existing projects use main.

​
Deploy a Preview

fimo deploy works on the current Branch. It commits pending changes, pushes the Branch, updates its Preview, and returns the Fimo Studio URL. 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 <id> for the build output.
Run fimo preview url to retrieve the hosted deployment without another commit or push. It waits while the current generation builds.

​
Publish production

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:
A label helps you recognize the publication later. It does not change what gets published.
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.
Publishing makes the site public. A plain fimo deploy remains a project-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.
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. 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.
Legacy static hosting ignores these rules. Contact support if they have no effect on your deployed site.

​
CLI and Studio

The CLI and Studio are two ways to publish the same project:
  • Use the CLI while working in the repository. It can push local changes and publish in one command.
  • Use Publish in Studio 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

Launch checklist

Check readiness, URL, live site, and recovery.

Custom domains

Choose the address visitors will use.

Analytics

Review traffic after publication.