Skip to main content
You publish a member site with the Fluid CLI. fluid sites publish 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.

​
Before you start

Install the Fluid CLI and its member site plugin, and sign in:
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. fluid sites publish needs the folder’s binding file, .member-site.json, which names the site. To start a new site, run fluid sites create in your site’s folder. It creates the site and writes the binding there, and leaves your files alone:
For a company site, add --company and use --as admin. A folder already bound to the same site is left as it is, and a folder bound to another site is refused.

​
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. 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. 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.
  5. Publishes: applies the schema and makes the new build the site’s current version.
A new site is private until its owner makes it public. Publish it, open it at its storefront address, and check it before you share it. To go back to an earlier build, see Make an earlier bundle current. The other operations behind publishing are Start a bundle upload and Publish a bundle, or for a company site Publish a company site’s bundle.

​
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.

​
What the answers mean

The command never prints the upload addresses it uses.