Command Reference
Global Options
Global options can be used with any command.
Assets
assets list
Lists assets for a site, with optional filtering and sorting.
Usage
Options
Also accepts global options.
Example
assets upload
Uploads a file as a site asset.
Supported file types
- Images (≤ 4 MB): PNG, JPG, JPEG, GIF, SVG, WEBP, AVIF
- Documents (≤ 10 MB): PDF, DOC, DOCX, XLS, XLSX, PPT, PPTX, TXT, CSV, ODT, ODS, ODP, JSON, Lottie
Usage
Arguments
Options
Also accepts global options.
Example
assets update
Updates an asset’s metadata.
Usage
Arguments
Options
Also accepts global options.
Example
assets folders list
Lists asset folders for a site.
Usage
Options
Also accepts global options.
Example
assets folders create
Creates a new asset folder.
Usage
Arguments
Options
Also accepts global options.
Example
Authentication
auth login
Authenticates the CLI with your Webflow account. Opens a browser window where you select a workspace and grant access, then saves WEBFLOW_API_TOKEN to a .env file in your project root.
Usage
Options
Also accepts global options.
Example
For more details, see the authentication documentation.
auth status
Shows the currently authenticated user and active OAuth scopes.
Usage
Example
auth logout
Removes the stored session and logs out of the CLI.
Usage
Example
auth telemetry
Manages telemetry settings for all Webflow CLI commands.
Usage
Options
Also accepts global options.
By default, --enable/--disable write to a global config file (~/.config/webflow/telemetry.json on macOS/Linux, %APPDATA%\webflow\telemetry.json on Windows) that applies to every project. Pass --local to write the preference to the current directory’s webflow.json instead, overriding the global setting only for commands run there. A webflow.json with an existing telemetry setting is still read and takes precedence over the global config regardless of this flag. DO_NOT_TRACK overrides both.
Example
CMS
cms collections list
Lists all CMS collections for a site.
Usage
Options
Also accepts global options.
Example
cms collections get
Gets the details and field schema for a CMS collection.
Usage
Arguments
Options
Also accepts global options.
Example
cms collections create
Creates a new CMS collection on a site.
Usage
Options
Also accepts global options.
Example
cms fields create
Adds a field to a CMS collection.
Usage
Options
Also accepts global options.
Valid field types
PlainText, RichText, Number, DateTime, Link, Image, Video, Color, Bool, Option, ItemRef, ItemRefSet
Example
cms items list
Lists items in a CMS collection.
Usage
Options
Also accepts global options.
Example
cms items get
Gets a single CMS item by ID.
Usage
Options
Also accepts global options.
Example
cms items create
Creates a new CMS item.
Usage
Options
Also accepts global options.
Example
cms items update
Updates an existing CMS item.
Usage
Options
Also accepts global options.
Example
cms items delete
Deletes a CMS item.
Usage
Options
Also accepts global options.
Example
cms items publish
Publishes one or more CMS items.
Usage
Options
Also accepts global options.
Example
DevLink Export
devlink export
Exports Webflow components from your site as a static, self-contained local React bundle.
Usage
Options
Also accepts global options.
Example
devlink sync
webflow devlink sync is deprecated. Use webflow devlink export instead.
Syncs Webflow components to your local filesystem. When run without arguments, all components are synced.
Usage
Arguments
Options
Also accepts global options.
Example
DevLink Import
devlink import
Bundles and shares components with a Webflow Workspace.
Usage
Options
Also accepts global options.
Example
devlink bundle
Bundles components locally to a dist directory.
This command doesn’t share the components to Webflow.
Usage
Options
Also accepts global options.
Example
Designer Extensions
extension list
Lists available templates for extension init.
Usage
extension init
Initializes a new Designer Extension from a template.
Usage
Arguments
Both arguments are optional — the CLI prompts for any that are not provided.
Example
extension bundle
Bundles your Designer Extension into a bundle.zip file for upload.
Usage
extension serve
Serves your Designer Extension on a local development server.
Usage
Arguments
Forms
forms list
Lists all forms for a site.
Usage
Options
Also accepts global options.
Example
forms submissions
Lists submissions for a specific form. Supports JSON output and CSV export.
Usage
Options
Also accepts global options.
Example
Logging
log
Displays the directory and path to the latest log file.
Usage
Sites
sites list
Lists all sites in your Webflow workspace.
Usage
Options
Also accepts global options.
Example
sites get
Gets details for a specific site.
Usage
Arguments
Options
Also accepts global options.
Example
sites domains
Lists the custom domains configured for a site.
Usage
Options
Also accepts global options.
Example
sites publish
Publishes a site to the Webflow subdomain or to specific custom domains.
Usage
Options
Also accepts global options.
Example
Apps
The apps namespace is the canonical way to manage Webflow Cloud apps — full-stack applications deployed either to an existing Webflow site (site-attached) or as a standalone project (project app). It replaces the cloud namespace below, which remains available as a set of deprecated aliases.
apps is a pre-release namespace — install the @next channel
Every apps command on this page ships only on the CLI’s pre-release channel. On the
stable channel the apps namespace does not exist, and each command below fails with an
unknown-command error.
A pre-release install reports a version with a -next. suffix; a stable install reports a
plain version number. Check with webflow --version.
The stable channel covers cloud init, cloud deploy,
cloud create, and cloud list only. There is no stable
equivalent for the management commands — apps list, get, domains, link, update,
delete, environments, deployments, logs, or env-vars.
For the identity-resolution order (flags, environment variables, webflow.json), non-interactive requirements, and CI/CD examples, see Agents & CI/CD.
apps init
Bootstraps a new Webflow Cloud app locally. Shares its options and behavior with the deprecated cloud init.
Usage
Options
Also accepts global options.
--no-input requirements
Always pass --app-name and --framework. Site-attached apps additionally require --site-id. Project apps
(--new) should pass --workspace-id — without it, a token that can see more than one workspace triggers a picker
that hangs in a non-TTY context.
Example
Creating an app from a repository
--import points init at an existing GitHub repository instead of scaffolding a new
project. Webflow creates the app from that repo, triggers a first build, and clones the
repo locally so you can keep working in it.
The app name defaults to the repository name; pass --app-name to override it. The
branch defaults to the repository’s default branch; pass --branch to build a different
one.
--site-id, --new, and --mount behave differently with --import
These flags are not interchangeable with their scaffold-path behavior. With
--import:
--framework and --workspace-id are also rejected alongside --import — a repository
brings its own code, and the workspace is derived from your token.
--idempotency-key is required when importing with --no-input (including CI). Use a
retry-stable value unique to the repository and target, so a retried step replays the
original app instead of creating a second one.
Webflow reads the repository through its GitHub App, never through your personal GitHub credentials, so the App must be installed on the repository’s account and connected to your workspace. When it isn’t, the command fails with an actionable error carrying the URL to complete:
Open the URL from the error you got — the two are different pages, and visiting the install page for an already-installed account only shows GitHub’s “Configure” screen and connects nothing. Then re-run the command. The browser is only involved for this one-time step.
A Workspace API Token can deploy but cannot create an app — creating one records you as
its author, so it requires a token from webflow auth login. This applies to apps init generally, --import included.
apps deploy
Deploys the current app to Webflow Cloud. Shares its options and behavior with the deprecated cloud deploy.
Usage
Options
Also accepts global options.
--site-id and --workspace-id are mutually exclusive
Use --site-id to deploy site-attached, or --workspace-id to deploy a project app in a specific workspace. Passing
both will error. This one is a hard failure before any backend call — unlike --mount, which is not enforced.
The deploy prompts (pick an app, name a new app, pick an environment) are gated on whether --mount and --environment are both set — not on --no-input. Passing --no-input without both still triggers the prompt and hangs in a non-TTY context. The minimum safe form is --no-input --mount <path> --environment <env> plus --site-id (site-attached) or --workspace-id (project app, first deploy).
Omitting --mount under --no-input deploys to root, silently
--mount is not enforced. When it is omitted in a non-interactive run the command does not
fail and does not warn — it deploys at root (/). The mount prompt offers a /app
default, but the non-interactive path only accepts a default that passes a validator, and
this prompt has none, so nothing is returned and the value normalizes to /. Root is a
valid mount, so the deploy goes ahead there.
Always pass --mount explicitly in CI and scripts. A wrong mount tends to surface later as
an ENVIRONMENT_MOUNT_MISMATCH on a subsequent deploy, well away from the run that caused
it.
How deploy decides between site-attached and project app
A preflight step resolves identity before any backend call, taking the first match:
--site-id → --workspace-id → WEBFLOW_SITE_ID → siteId in webflow.json →
WEBFLOW_WORKSPACE_ID → cloud.workspace_id → a hard error under --no-input, or a
picker otherwise.
Two consequences worth knowing: environment variables outrank webflow.json, and any
resolved site short-circuits before workspace resolution is attempted. A stale
WEBFLOW_SITE_ID left in the environment therefore wins over a manifest configured for a
project-app deploy. Pass --site-id or --workspace-id explicitly to remove the
ambiguity.
Example
apps list
Lists all apps in your Webflow workspace.
Usage
Options
Also accepts global options.
App names are unique only within a site, so pass --site and --name together to
resolve to at most one app. --site alone can match many apps, and --name alone can
match apps across different sites.
Multiple filters combine with AND — every one must match. An exact filter plus a
non-matching --q therefore returns an empty page, and that means nothing matched all
the filters, not that the app doesn’t exist. Use --q to discover, then narrow.
Example
apps get
Gets details for a specific app.
Usage
Arguments
Options
Also accepts global options.
Example
apps domains
Lists the domains and live URLs configured for an app.
Usage
Arguments
Options
Also accepts global options.
Example
apps update
Updates an app’s name, description, or GitHub source. Requires at least one of --name, --description, or --github-source.
Usage
Arguments
Options
--github-source does not deploy
Attaching or repointing a repository changes only what the app builds from. Run
apps deployments trigger afterwards to build it.
To change which branch an environment builds, use
apps environments update --branch — --github-source
selects the repository, the environment selects the branch.
It requires the Webflow GitHub App installed on the repository owner and connected to your
workspace, the same prerequisite as
apps init --import.
Also accepts global options.
Example
apps delete
Deletes (or archives, depending on the site kind) an app.
Usage
Arguments
Options
Also accepts global options.
Example
apps environments list
Lists the environments of an app.
Usage
Arguments
Options
Also accepts global options.
Filters combine with AND, so --branch plus a non-matching --q returns an empty page —
that means nothing matched every filter, not that the environment is absent.
Example
apps environments create
Creates an environment on an app, bound to a branch and served at a mount path.
Usage
Arguments
Options
Also accepts global options.
The environment starts empty. Run apps deployments trigger
to build it.
Example
apps environments update
Updates an environment’s branch or mount path. Requires at least one of --branch or --mount.
Usage
Arguments
Options
Also accepts global options.
The environment keeps serving its existing build until you run
apps deployments trigger.
Example
apps environments delete
Deletes an environment from an app.
Usage
Arguments
Options
Also accepts global options.
--yes is required non-interactively
Without a TTY and without --yes, the command refuses rather than deleting, reporting
yes as the missing flag.
Example
apps link
Points the current directory at an existing app and environment by updating webflow.json. Verifies the app, but creates and deploys nothing — use it to adopt an app from a fresh clone, or to repoint a directory at a different app or environment.
Usage
Arguments
Options
Also accepts global options.
Example
apps deployments list
Lists the most recent deployments of an environment, newest first. Resolves the app and environment from WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID, webflow.json, or an interactive picker — this command takes no appId argument.
Usage
Options
Also accepts global options.
Example
apps deployments get
Gets details for a specific deployment. Resolves the app and environment the same way as deployments list.
Usage
Options
Also accepts global options.
Example
Waiting for a deployment to finish
Watching is a modifier on get, not a separate command. Pass --wait to poll until the
deployment reaches a terminal status — useful as a gate before a downstream step such as
smoke tests or a notification.
Deployment status is one of starting, building, deploying, success, failed,
canceled, or unstaged. The first three are in-flight; the rest are terminal.
Exit codes with --wait
--wait exits 1 both when the deployment ends in a non-success status and when
polling times out first. A CI step that needs to tell “it broke” from “it is still
running” has to read the reported status rather than gate on the exit code alone.
Example
apps deployments redeploy
Re-runs an existing deployment at its same commit, enqueuing a fresh build. Redeploying an earlier successful deployment is how you roll back.
Usage
Arguments
Options
Also accepts global options.
Apps deployed from local files with apps deploy are not eligible —
there is no commit to re-run. Connect a repository with
apps init --import or
apps update --github-source.
Example
apps deployments trigger
Builds the resolved environment’s current HEAD on demand. Same as redeploy, but with no deployment ID — there is no past build to re-run, so it builds whatever the environment’s configured branch points at now.
Usage
Options
Also accepts global options.
Same eligibility rule as redeploy: apps deployed from
local files with apps deploy cannot be triggered.
If the two differ, the CLI warns but does not block. Check with
webflow apps environments list --fields id,branch when you are unsure which branch will
build.
Example
apps logs build
Reads the build logs of one deployment. Resolves the app and environment from WEBFLOW_APP_ID / WEBFLOW_APP_ENVIRONMENT_ID, webflow.json, or an interactive picker.
Usage
Arguments
The command does not fall back to the newest deployment. That default was removed because its result could not be told apart from a wrong answer: with two deploys in flight you silently got someone else’s build, and before your own build was queued you got the previous deployment — already finished, already green — reported as the current one.
Omitting the ID fails before any network call. Under --json the error carries
missingFlag: "depId", so an agent can recover programmatically instead of
string-matching:
The two-step pattern is the intended one — listing first means you see which deployments exist rather than accepting a silent choice.
Options
Also accepts global options.
Example
apps logs runtime
Reads the runtime logs of an environment. Resolves the app from WEBFLOW_APP_ID / webflow.json (or a picker); the environment from the envId argument, WEBFLOW_APP_ENVIRONMENT_ID, webflow.json, or a picker.
Usage
Arguments
Accepts the same --since, --q, --limit, --cursor, --fields, and --json options as logs build.
Example
apps env-vars list
Lists environment variables for a Cloud app environment. Secret values are always masked.
Usage
Options
Also accepts global options.
Example
apps env-vars set
Creates or updates an environment variable.
Usage
Arguments
Options
Also accepts global options.
Passing a secret value as the value argument exposes it in shell history and the process list. Pipe it via stdin instead:
Example
apps env-vars delete
Deletes an environment variable.
Usage
Options
Also accepts global options.
Example
apps env-vars import
Bulk imports environment variables from a .env-style file.
Usage
Arguments
Options
Also accepts global options.
Partial failures exit non-zero after printing the full created / updated / skipped / error breakdown.
Example
Webflow Cloud
webflow cloud init and webflow cloud deploy are deprecated aliases of apps init and apps deploy — prefer the apps namespace for new scripts and CI/CD pipelines. cloud create
remains cloud-only, with no apps equivalent. cloud list is also deprecated: it lists scaffold templates for
init, not your Cloud apps — use apps list to list your apps, or apps init with
--framework / --help for available templates.
cloud create
webflow cloud create is deprecated. Use webflow cloud init instead, which supports both
site-attached and standalone apps and lets you choose the mount path interactively or via --mount.
Scaffolds a new site-attached Webflow Cloud project non-interactively. The project mounts at /app with no option to override the mount path.
Usage
Arguments
Options
Also accepts global options.
Example
cloud init
webflow cloud init is a deprecated alias of webflow apps init. Both share the exact same options and
behavior; prefer apps init in new scripts.
Initializes a new Webflow Cloud app from a template.
Usage
Options
Also accepts global options.
--site-id and --workspace-id are mutually exclusive
Use --site-id to connect to an existing site, or --workspace-id with --new to create a project app in a specific
workspace. Passing both will error.
Example
cloud list
Lists available app templates for cloud init.
Usage
cloud deploy
webflow cloud deploy is a deprecated alias of webflow apps deploy. Both share the exact same
options and behavior; prefer apps deploy in new scripts.
Deploys your app to Webflow Cloud.
Usage
Options
Also accepts global options.
--site-id and --workspace-id are mutually exclusive
Use --site-id to deploy site-attached, or --workspace-id to deploy a project app in a specific workspace. Passing
both will error.
Before deploying, the CLI resolves the target app in this order:
--site-idflag → site-attached deploy.--workspace-idflag → project-app deploy.siteIdinwebflow.json→ site-attached deploy.cloud.workspace_idinwebflow.json→ project-app deploy.WEBFLOW_SITE_IDenvironment variable → site-attached deploy.- Interactive picker → or hard-error when
--no-inputis set.
For non-interactive deployments suitable for CI/CD pipelines, pass --no-input along with both --mount and --environment, plus an explicit target — either --site-id for site-attached deploys or --workspace-id for project apps. You can also use --auto-publish to publish the site after deployment so that your new environment is live.
The deploy prompts (select an existing app, name a new app, pick an environment) are gated on whether --mount and --environment are both set — not on --no-input. Passing --no-input without both flags still fires the prompt and hangs in non-TTY contexts. The minimum safe CI form is --no-input --mount <path> --environment <env> --site-id <id> (or --workspace-id <id> for a project-app first deploy).