Skip to main content
You publish a Site with the Fluid CLI. fluid sites publish saves your folder to the Site’s source repository, uploads your build output and declarations, and makes them the Site’s current version in one step. Until that step succeeds, the Site keeps serving its current version. fluid deploy wraps the whole path for a project folder: it builds, creates the Site the first time, and publishes. Mist’s Publish button and the Fluid MCP server publish the same way. For a direct API integration, see Sites APIs.

​
Before you start

Install the Fluid CLI and its Sites plugin, and sign in. The CLI needs Node.js 24 or later, and Git to save the Site’s source:
Your login follows the Site’s owner. A member’s Site is published with that member’s login, and a company Site with the login of an admin who may change themes. Say which one you’re using with --as member or --as admin. Without it, the server decides and a refusal names the login the Site needs. Writes act as a person: a company API token can read company Sites but can’t create or publish one. fluid sites publish needs the folder’s binding file, .member-site.json, which names the Site. Don’t edit it or copy it into another Site’s folder. To bind a folder to a new Site, run fluid sites create in it. It creates the Site and writes the binding there, and leaves your files alone:
--company creates a company Site and needs an admin login. A folder already bound to the same Site is left as it is, and a folder bound to another Site is refused. To work on a Site whose source is already saved, clone it with fluid sites pull instead.

​
Deploy in one step

fluid deploy takes a project folder to a live address:
It reads what built the project (Vite, Astro, a Next.js static export or plain HTML), builds it with the project’s own package manager, creates and binds a Site the first time, publishes with fluid sites publish’s own code, and prints the address. The first deploy asks once whether the Site is public. --public answers yes, and without a terminal the Site stays private. --no-source and --as work as they do for fluid sites publish. A Next.js app with a server isn’t a Site. fluid deploy explains why, with Fluid’s recommendation when the server gives one, and creates nothing. See Site or App? and the framework guides.

​
Check the site

fluid sites lint checks the site’s folder on your machine. It makes no request and needs no login.
It runs the same checks fluid sites publish runs before it sends anything:
  • Every file of the build has a type a site may serve, such as HTML, CSS, JavaScript, JSON, SVG, images, fonts, text, XML, PDF, MP4, WebM and MP3.
  • No file is under /_fluid/, and nothing in the build is a symbolic link.
  • The build holds at most 2,000 files, each at most 25 MiB, and 250 MiB in all.
  • The build has an index.html when there’s no config/routes.json, and every route names a file of the build.
  • db/schema.json, config/access.json, config/meta.json and config/routes.json are valid JSON and pass their rules.
  • There’s no functions/ folder or config/functions.json. Server functions aren’t available yet.
Each problem is an error that names its file. A clean folder prints nothing and exits 0. Any error exits 1. For a company Site, fluid sites lint also warns when config/meta.json gives no title or description, or the build has no routes and no prerender entry. A warning doesn’t stop a publish, and the title and description warning is fine when the Site’s SEO settings set them. See SEO and indexing. The build’s folder is dist by default. Name another with --dir, relative to the site’s folder:

​
Publish

The command:
  1. Hashes every file of the build. A file under assets/ whose name carries a content hash, such as index-Bx3zQw9a.js, is cached by browsers for a year.
  2. Reads db/schema.json and the files in config/.
  3. Runs the checks of fluid sites lint, and stops before any request when one fails.
  4. Commits the folder and pushes it to the Site’s source repository. See Source in git.
  5. Uploads only the files the Site doesn’t store yet. Publishing the same build twice uploads nothing the second time, and changing one file uploads one file.
  6. Publishes: applies the schema, creating the Site’s database on the first publish that has a db/schema.json, and makes the new build the Site’s current version. It prints the Site’s address.
With --json, a successful publish prints ok, site, bundle, manifestSha256, source (the repository, branch and commit, or null when the source wasn’t saved) and, when the server sends one, url. A new Site is private until its owner makes it public. Publish it, open it at its address, and check it before you share it. To go back to an earlier build, see Deployments and rollback. The operations behind publishing are Start a bundle upload and Publish a bundle, or for a company Site Publish a company site’s bundle.

​
Make a Site public or private

fluid sites visibility sets who may open the folder’s Site:
public lets anyone open the site, and private only the people it’s shared with. Use the owner’s login: --as member for your own site, --as admin for a company site. Whatever its visibility, a draft or a site a company admin took down opens for nobody, and a site a company admin locked opens only for company admins. The command says so. See Share a Site.

​
Confirm a destructive schema change

A change to db/schema.json that drops, renames or retypes a table or column, or makes a column required, needs a migration. Confirm each migration by its id, once per migration:
Without it, the publish is refused with destructive_change_unconfirmed, the command lists each unconfirmed migration with its steps, and nothing changes. See Change the schema.

​
Finish an interrupted schema change

If a publish leaves a schema change pending, the next publish offers to finish that bundle first. With no terminal, use:
That run finishes the pending bundle and stops. Run the command again for your own build. If the pending bundle needs destructive migration confirmations, check its schema and pass --confirm-pending <id> for each of its migrations. Your build’s --confirm values are never applied to the pending bundle. See Finish an interrupted publish.

​
What the answers mean

When Fluid can’t set up the Site’s source repository, the command says so and publishes without the source. A later publish saves it. The command never prints the upload addresses it uses.