Management CLI reference

This is the canonical capability reference for microfeed’s repository-owned management CLI. It is written for people and coding agents that need to understand what the CLI can do, what it changes, and which safeguards apply.

For a guided task, start with Manage your site or the installation guides. Use this page when you need the complete command and option contract. Run npx @microfeed/cli manage help <command> for the corresponding terminal reference.

Contents

• Before running commands
• Safety model
• Command summary
• Shared conventions
• Command reference
  • accounts
  • init
  • connect
  • deploy
  • dev
  • theme
  • snapshot
  • status
  • destroy
  • migrate-pages
  • domain
  • access
  • auth
  • config
  • instances
  • use
• Built-in help
• Environment variables
• Maintaining this reference

Before running commands

The management engine remains part of the microfeed repository. Choose the invocation that matches how you are working.

The recommended invocation works from any folder and does not require you to Git-clone or open the microfeed source repository:

npx @microfeed/cli manage

The launcher carries the exact release matching the installed CLI and a pinned Yarn runtime. It verifies and copies that source into a private operating-system cache, installs its locked dependencies, and prints the deployment skill and reference paths for the agent. It stores saved deployment state separately under the microfeed configuration directory. The first setup may use about 1.3 GB and take several minutes; later commands reuse it.

Coding agents do not generally discover skills inside npm or cache directories automatically. The launcher therefore prints both cached file paths explicitly and tells the agent to read them completely. See the official Codex skill discovery behavior.

The replaceable workspace lives under ~/Library/Caches/microfeed/manage on macOS, ${XDG_CACHE_HOME:-~/.cache}/microfeed/manage on Linux, or %LOCALAPPDATA%\microfeed\manage on Windows. Saved deployment state instead lives under ${XDG_CONFIG_HOME:-~/.config}/microfeed/manage on macOS and Linux, or %APPDATA%\microfeed\manage on Windows. MICROFEED_CACHE_DIR and MICROFEED_CONFIG_DIR override the respective base directories; the launcher still appends its manage child directory.

Deployment and administration examples in this reference use the published launcher:

npx @microfeed/cli manage accounts --json
npx @microfeed/cli manage deploy --instance <instance-name>
npx @microfeed/cli manage status --instance <instance-name>

If you already have a Git-cloned microfeed source repository and have run yarn install, you may replace the npx @microfeed/cli manage prefix with yarn manage. For example, yarn manage help uses that source repository’s local version of the same management engine.

The dev section instead prioritizes yarn manage dev from a Git-cloned microfeed source repository because local source development requires that repository and its installed dependencies.

Both local paths require Node.js 22.12 or newer and an interactive session. Windows ARM computers are supported through Windows’ x64 application emulation: install the x64 build of Node.js because Cloudflare’s local runtime does not provide a native Windows ARM64 executable. Run node -p "process.arch" and confirm that it prints x64 before continuing. The published npx path also requires npm, but it does not require Git or Corepack. A Git-cloned source repository uses its normal Corepack and Yarn development setup. Cloudflare operations use Wrangler browser authorization. Credentials are managed by Wrangler; do not paste Cloudflare tokens into command arguments or agent conversations.

Cloudflare repository imports, Workers Builds, deploy buttons, and API-token deployment are not supported. The repository’s manual GitHub Actions workflow is a narrow exception for creating or updating a site: it runs yarn manage in an ephemeral Ubuntu runner and requires fresh Cloudflare device authorization for every run. It does not save a Cloudflare credential in GitHub. See Update with GitHub Actions.

Safety model

• The repository-owned management engine is the only supported interface for microfeed Cloudflare mutations. Use it through npx @microfeed/cli manage, or through yarn manage when working in a Git-cloned microfeed source repository; do not replace it with improvised Wrangler or REST commands.
• Initialization validates the selected account and checks Worker, Pages, D1, and, unless --no-r2 is used, R2 name collisions before creating resources.
• Existing D1 or R2 resources require explicit reuse approval. Resources recorded as reused are never deleted by destroy.
• Saved Cloudflare deployments retain their exact account ID. Later commands stop if the current login cannot access that account.
• Built-in login passwords should be created through the private browser link. --admin-password is an intentionally unsafe automation escape hatch because process arguments may appear in shell history, process lists, transcripts, and logs. The manual GitHub Actions workflow uses it only with GitHub’s masking and an operator-created Actions secret; the selected ref must be trusted because its code executes while that secret is available.
• destroy requires a read-only plan and an exact site-name confirmation. It rejects --yes, verifies resource identity, and records progress so the same command can resume safely.
• Local development uses isolated D1 and optional R2 simulations. It does not copy or synchronize production data.
• Snapshot restore validates every checksum and historical migration hash before mutation. Remote restore requires an unchanged, newly initialized target and exact instance-name confirmation, and leaves a resumable maintenance journal if migration or data restoration fails.

Command summary

Command	Purpose	External effect
accounts	Authorize and list Cloudflare accounts	Read-only discovery; may update local Wrangler login profiles and the management-workspace binding
init	Initialize production, preview, or local installation	Creates or updates Cloudflare resources, or local-only state
connect	Save an existing compatible Worker in local management state	Reads Cloudflare; writes local state only
deploy	Check, migrate, deploy, verify, or prepare a local release	Updates Worker code and D1 migrations, or only local state with --local
dev	Run a selected site locally	Starts a local server and changes local simulation data
theme	Initialize, install, and manage immutable theme versions	Creates local authoring repositories, writes theme rows to D1 and optional assets to R2, or changes active state through the Worker
snapshot	Create, pull, or restore a portable backup	Read-only export, local state creation, or an exactly confirmed fresh remote replacement
status	Verify resources and protection	Read-only Cloudflare and HTTP checks
destroy	Inspect and remove a deployment	Permanent deletion unless data is preserved
migrate-pages	Deploy a side-by-side Worker for Pages migration	Creates a Worker; preserves the Pages project and reused data
domain	Configure a production custom domain	Updates and redeploys the Worker route
access	Guide optional Cloudflare Access protection	User performs the dashboard change; CLI guides and verifies
auth	Manage built-in login, email, password, and path	Updates D1/configuration and may redeploy
config	Validate state and regenerate Wrangler configuration	Local files only
instances	List saved and discoverable installations	Read-only local and Cloudflare discovery
use	Select the default saved site	Local active-instance pointer only

Shared conventions

Selecting a site

Use --instance <name> whenever the target is not already the active saved site. MICROFEED_INSTANCE supplies the same selection for commands that accept an instance. Use npx @microfeed/cli manage instances to review choices and npx @microfeed/cli manage use <name> to change the default.

Selecting a Cloudflare account

Use npx @microfeed/cli manage accounts first. Commands that operate on a saved deployment automatically require its recorded account. Supplying --account-id <id> is an additional exact-account assertion; it cannot override saved ownership.

To keep separate Cloudflare logins on the same computer, use npx @microfeed/cli manage accounts --profile <name>. The named Wrangler profile is local to your computer and does not need to be globally unique. It is separate from the microfeed site/Worker name, which should be globally distinctive.

Production, preview, and local data

• No environment flag means the production Cloudflare installation.
• --preview selects the isolated preview Worker and D1 database. Preview is available only after production R2 is ready and shares that bucket as a preserved resource.
• --local is supported only where documented. Local state is stored under the selected instance and never accesses production D1 or R2 data.

Interactive and non-interactive operation

--yes skips only prompts supported by a command. It does not bypass account, identity, collision, reuse, password, or deletion safeguards. destroy deliberately rejects it.

When R2 becomes available for an automatic pending installation, interactive deploy asks whether to add it and defaults to yes. A decline records the durable disabled choice. A non-interactive terminal continues content-only, keeps the automatic state, and prints the exact deploy --enable-r2 command.

Browser and device authorization

Cloudflare authorization normally opens a browser and waits for a localhost callback. --device instead prints a URL and one-time code, so an interactive person can authorize a command running in a headless environment. It is supported by accounts, init, connect, deploy, and status; it cannot be combined with a named --profile.

Device authorization does not create an API token. In this mode, Wrangler saves its OAuth credential in configuration storage without using an operating-system keyring; it remains there until wrangler logout removes it. The repository GitHub Actions workflow places that storage in the hosted runner’s temporary directory, isolates it from caches, and logs out afterward to revoke the refresh token and remove the local credential.

Command reference

npx @microfeed/cli manage accounts

Purpose: Authorize Cloudflare and list available accounts.

Changes: Read-only Cloudflare discovery; may update local Wrangler login profiles and their binding to the management workspace.

Authorize Cloudflare and list every account available to the active Wrangler login. This command never creates or changes a Worker, D1 database, R2 bucket, domain, or microfeed configuration.

A Wrangler profile is a Cloudflare login saved on the local computer. A Cloudflare account is a workspace that owns sites, databases, media storage, and other Cloudflare resources. One login profile may have access to one or more Cloudflare accounts.

The output lists every locally stored profile, marks the one active for this management workspace, and prints an exact npx @microfeed/cli manage accounts --profile <name> command for each other named profile. The displayed email and Cloudflare accounts belong only to the active profile; inactive profiles remain stored but are not queried. Wrangler’s default profile is a fallback login rather than a named profile selected by this option.

Use --profile <name> to create or select a named Wrangler browser login and bind it to the local management workspace. If the profile does not yet exist, the command opens Cloudflare authorization to create it. If it already exists, the command selects it without changing its credentials. Add --reauthorize to replace that named profile’s authorization deliberately. Wrangler profile names accept ASCII letters, numbers, hyphens, and underscores; default and staging are reserved. Wrangler currently labels named profiles as a beta feature.

npx @microfeed/cli manage accounts [--json] [--device] [--profile <name>] [--reauthorize]

Option	Meaning
--json	Print the login, active profile, all profiles with active markers, and {name, id} accounts as JSON.
--device	Use a URL and one-time code instead of a localhost browser callback. Cannot be combined with --profile.
--profile <name>	Create or select a named Wrangler browser login and bind it to the local management workspace.
--reauthorize	Force fresh browser authorization, for example when the desired account is missing.

Browser or device authorization rejection, missing permissions, zero accounts, or an unavailable callback fail before resource creation.

npx @microfeed/cli manage init

Purpose: Initialize or resume a production, preview, or local installation.

Changes: Creates or updates Cloudflare resources, or creates an isolated local sandbox with --local.

Initialize or resume an installation. Production initialization can create a Worker, D1 database, optional R2 bucket, secrets, migrations, administrator password setup link, and optional custom domain. It performs collision checks before the first mutation. Remote initialization runs type checks, focused deployment smoke tests, and a Worker build before publishing. The complete repository test suite remains part of yarn check and continuous integration. The authentication choice and any public-dashboard warning are confirmed before D1 or R2 resources are created. If initialization is interrupted later, retrying preserves whether each recorded resource was created for this site or explicitly reused. The fresh-target snapshot fingerprint is recorded after initialization, including optional custom-domain and login setup, has finished. Fresh initialization installs every current Built-in theme release and activates only the Default fallback. A resumed run installs any missing packages without changing an already selected theme.

npx @microfeed/cli manage init [--device] [--instance <name>] [--preview|--local] [options]

Option	Meaning
--instance <name>	Select the saved site name.
--account-id <id>	Use one exact Cloudflare account.
--device	Use a URL and one-time code instead of a localhost browser callback.
--project-name <name>	Set the production or preview Worker name: 1–63 ASCII letters, numbers, or hyphens; no leading or trailing hyphen.
--d1-name <name>	Set the production or preview D1 name.
--r2-name <name>	Set the production R2 name; preview always shares production media.
--admin-path <path>	Set the remote dashboard path, defaulting to admin.
--admin-auth <built-in|none>	Enable built-in protection or deliberately skip it.
--owner-email <email>	Set the administrator sign-in email. With --yes, the authenticated Cloudflare login email is used when available.
--admin-password <value>	Unsafe remote-only automation password. Never use from an agent.
--no-open	Print the private password page without opening a browser.
--reuse-d1	Explicitly reuse a same-named existing D1 database.
--reuse-r2	Explicitly reuse a same-named existing production R2 bucket.
--no-r2	Skip every R2 discovery and creation step, omit MEDIA_BUCKET, and save the validated future bucket name. Cannot be combined with --reuse-r2 or --preview.
--preview	Create or resume preview after production exists.
--local	Create or resume a local-only site. Cannot be combined with --preview.
--yes	Accept supported non-secret remote defaults. It never approves collisions implicitly.

Examples:

npx @microfeed/cli manage init
npx @microfeed/cli manage init --preview
npx @microfeed/cli manage init --local
npx @microfeed/cli manage init --no-r2 --r2-name future-media

--no-r2 works for both Cloudflare and local-only initialization. It creates a content-only instance where D1 publishing and external URLs continue to work. It never detaches an already configured bucket. Enable the saved bucket later with npx @microfeed/cli manage deploy --enable-r2.

Without --no-r2, only Cloudflare’s documented R2 subscription-required response (10042, NotEntitled) is safely deferrable. The Worker is deployed and verified without MEDIA_BUCKET, the saved setup mode remains automatic, and the CLI prints the exact account’s R2 dashboard link. R2 activation and any payment-method or billing consent stay in Cloudflare’s dashboard; microfeed never performs those actions. Permission, authentication, and unknown R2 failures remain fatal.

Choose a globally unique, distinctive site name. If you plan to use a custom address, replace its dots with hyphens; for my.domainname.com, use my-domainname-com. Fresh interactive Cloudflare initialization does not preselect a generic site name.

Rerun the identical command after interruption. Saved progress prevents duplicate creation and unrelated-resource overwrite.

On a newly created Cloudflare account, its first Worker deployment may report that workers.dev is not ready while Cloudflare finishes preparing the account. Wait a few minutes, then rerun the same npx @microfeed/cli manage init command. The saved initialization resumes without duplicating completed work.

microfeed enables the free workers.dev address, so Worker names are checked against its Cloudflare naming rules: 1–63 ASCII letters, numbers, or hyphens, with no leading or trailing hyphen. A one-character Worker name is valid. Names only need to be unused in the selected Cloudflare account; before its first change, the CLI checks that account for an existing Worker or Pages project with the same name. Explicit invalid names are rejected before Cloudflare authorization. D1 database and R2 bucket names are validated separately before resource creation.

If a same-named Worker exists but the current local management state has no saved connection for it, init stops without overwriting it. Use the exact npx @microfeed/cli manage connect --worker <name> --instance <name> command printed by the error when that Worker is an existing microfeed installation. Otherwise, choose a different project name.

If resource provisioning or the first-password handoff is incomplete, init resumes only the unfinished work and preserves every recorded resource. When the installation and dashboard login are already ready, it stops without changing anything and points to deploy, status, domain, and auth for later management.

npx @microfeed/cli manage connect

Purpose: Connect local management state to an existing Cloudflare microfeed.

Changes: Reads Cloudflare and writes local connection state; does not change Cloudflare.

Discover an existing compatible microfeed Worker, including a content-only Worker identified by its D1 binding and saved R2 variables, verify its public identity, and save it in local management state. Cloudflare is not changed. Connected D1 and any ready R2 resource are marked reused and preserved by later destruction. Use --preview only after production is connected; it recovers the preview’s independent Worker and webhook Queue identity under the same saved instance.

npx @microfeed/cli manage connect [--device] [--preview] [--account-id <id>] [--worker <name>] [--instance <name>]

Option	Meaning
--account-id <id>	Search one exact account.
--device	Use a URL and one-time code instead of a localhost browser callback.
--worker <name>	Select an exact compatible Worker.
--instance <name>	Choose the local saved name.
--preview	Connect the preview Worker after its production instance is connected under the same local name.
--yes	Run without selection prompts; requires --worker when several matches exist.

npx @microfeed/cli manage deploy

Purpose: Check, migrate, deploy, and verify a saved installation.

Changes: Updates a selected Cloudflare Worker, or prepares a local-only release with --local.

Regenerate configuration, apply D1 migrations, run type checks and focused deployment smoke tests, and build. The smoke tests cover migration compatibility, core item and feed operations, installation identity, and administrator setup. When a release introduces or repairs search, deployment strips saved item HTML into D1’s stored plain-text column in resumable batches and validates the unified item-and-Page search index before it becomes available. A second pass after the Worker switch captures any item write completed by the previous Worker version. An incomplete pass stops deployment instead of serving partially normalized search data. Every deployment synchronizes the registered Built-in catalog from the current checkout. Missing and newer Built-in releases are installed inactive, and the active and previous selections are never changed. Preview and activation remain explicit actions in Settings → Themes. Synchronization is idempotent and can resume after a partial run. After a current Built-in release is available, deployment soft-deletes older releases of the same package when they are not active, previous, referenced by a draft or another version, or needed for theme assets. Current, newer, referenced, user-installed, and invalid-version records are preserved. A matching previously deleted Built-in release can be restored only when its package, version, source kind, and checksum still match the catalog. The complete repository test suite remains part of yarn check and continuous integration. Cloudflare mode then tags the Worker version with the current Git commit, deploys it, and verifies the Worker. The protected dashboard uses that version metadata to identify the deployed source release. --local preserves local data, performs the same preparation against local D1, and does not deploy or start a server.

npx @microfeed/cli manage deploy [--device] [--instance <name>] [--preview|--local] [--enable-r2] [--enable-webhooks|--disable-webhooks]

Option	Meaning
--instance <name>	Select the saved site.
--account-id <id>	Confirm the exact saved account.
--device	Use a URL and one-time code instead of a localhost browser callback.
--preview	Deploy preview instead of production.
--local	Prepare an instance created with init --local; cannot target a Cloudflare-managed instance or be combined with --preview.
--enable-r2	Require R2 entitlement and permanently prepare/bind the saved bucket, or add the simulated binding with --local. Idempotent when already ready.
--enable-webhooks	Provision one dedicated production or preview Queue and endpoint-secret encryption key when needed, then bind its producer and consumer and install one hourly Cron. Re-enabling verifies and reuses the exact saved Queue ID and secret. With --local, prepares the simulated binding explicitly, although plain dev already does this temporarily.
--disable-webhooks	For Cloudflare production or preview, pause and purge the dedicated Queue, cancel pending deliveries, and deploy empty producer, consumer, and Cron configuration. Retains the Queue, endpoint data, delivery history, and encryption secret. Cannot be combined with --enable-webhooks or --local.
--reuse-r2	Explicitly approve reuse if the saved bucket name already exists during Cloudflare enablement. --enable-r2 alone never approves reuse.
--yes	Run without optional prompts. Pending R2 remains automatic and content-only unless --enable-r2 is supplied.

deploy only operates on instances with locally saved configuration. If the microfeed already exists on Cloudflare, run npx @microfeed/cli manage connect --instance <name> first and select its Worker. For a new installation with no saved configuration, run npx @microfeed/cli manage init --instance <name> instead. When initialization has saved the instance but its first Worker deployment is not yet complete, deploy resumes that deployment and supplies the missing initial upload-signing secret automatically.

An ordinary deployment does not probe or prompt when media storage is already ready or explicitly disabled. For automatic pending setup, NotEntitled continues content-only with an activation reminder. When R2 is available, an interactive deployment offers to add it; declining records disabled so future deployments stay quiet. Non-interactive deployment prints the deterministic enable command and leaves the automatic pending state unchanged.

Explicit enablement fails with the account-specific dashboard and billing instructions if R2 is still unavailable. After successful creation or approved reuse, the generated Worker configuration contains the exact MEDIA_BUCKET binding, and deployment verifies both the bucket and Worker binding before completing. A later failure remains resumable. The CLI records a fresh remote restore baseline only when D1 is still bootstrap-only and the new bucket is empty; failing that eligibility check does not undo working R2 setup.

Webhook infrastructure has three saved states: unprovisioned, enabled, and disabled. Production and preview use separate, instance-specific Queue names and IDs. The first enable creates one Queue and one endpoint-secret encryption key. Later enablement, disabling, normal deployment, status, connection, and destruction verify that exact identity and fail closed if the Queue is missing or replaced. A same-named unknown Queue is never adopted automatically.

Enabled configuration binds the Queue as producer and consumer and installs one hourly maintenance trigger. It reconciles delivery IDs saved in D1 but not handed to the Queue and performs 30-day retention cleanup on the 00:00 UTC run. When no active or auto-paused endpoint remains, the trigger exits after one D1 check without reconciliation, cleanup, or Queue work.

Before enabling or disabling, the CLI verifies the existing exact Queue identity when present and performs read-only Queue and D1 access checks through the same Wrangler profile used by the deployment. It retries each safe check once when Cloudflare returns authentication code 10000. If the second check fails, the command stops before pausing, creating, purging, resuming, or detaching webhook resources and prints the exact deployment command to rerun in a fresh process. If Cloudflare rejects a later request, the saved transition remains resumable and the same recovery command is shown.

Disabling is resumable. It records the transition, pauses delivery, and marks pending or retrying rows canceled_webhooks_disabled, deploys explicit empty Queue and Cron arrays, cancels again to close the deployment race, purges the dedicated Queue, and verifies that the Queue is retained, paused, empty, and detached. Endpoint settings, subscriptions, encrypted signing secrets, failure streaks, history, and the encryption key remain unchanged. Events during the disabled interval are not replayed. Re-enabling keeps the Queue paused while restoring the producer, consumer, and Cron, then resumes delivery after verification.

An ordinary deployment preserves the saved lifecycle state. Repeating enable or disable verifies the state without creating another Queue or secret. Interrupted transitions resume on the next deployment. The reviewed destroy plan includes the Queue name, Queue ID, lifecycle state, backlog, and Cron schedules; confirmed destruction removes the exact Queue even when disabled.

yarn manage dev

Purpose: Run one site locally with isolated development data.

Changes: Starts a local server and changes only isolated local D1/R2 simulation data.

Run this from a Git-cloned microfeed source repository after yarn install. The command starts the selected site after applying local migrations. Even when the site is connected to Cloudflare, development uses isolated local D1 and R2 simulations.

yarn manage dev [--instance <name>] [--preview] [--enable-webhooks|--disable-webhooks]

Option	Meaning
--instance <name>	Select the local sandbox.
--preview	Use preview configuration with isolated local data.
--enable-webhooks	Optional explicit alias. Webhook simulation is already enabled for every local dev run.
--disable-webhooks	Omit the simulated Queue producer, consumer, and Cron for this run only. Does not change saved production, preview, or later local behavior.

Plain dev always generates a temporary Wrangler configuration with the local Queue producer, consumer, hourly maintenance trigger, and local endpoint-secret encryption key. It creates no Cloudflare Queue or other resource, requests no Cloudflare permission, incurs no Cloudflare Queue or Worker charge, and does not change whether preview or production webhooks are enabled. The original generated configuration is restored when the development server exits.

npx @microfeed/cli manage theme

Purpose: Initialize, install, and manage versioned themes.

Changes: Initializes a local authoring repository, installs immutable theme versions in D1, optionally writes declared assets to R2, or changes the active theme through a one-time authenticated Worker operation.

Start a new authoring repository from the theme the selected instance is actually using:

npx @microfeed/cli manage theme init ~/microfeed-themes/my-theme --instance <instance-name>

init resolves the same effective selection as the live site: a valid active D1 version, then the bundled default fallback. The command copies the source theme’s available slots and any declared packaged assets into an empty directory, adds the authoring kit, schemas, fixture, local package scripts, agent skill, and CLAUDE.md bridge, and initializes a Git repository on main. It recursively creates the destination and any missing parent directories, so ~/microfeed-themes/ does not need to exist first. It refuses to write into a non-empty destination. Keeping the generated directory outside the microfeed checkout prevents the standalone theme repository from being committed to microfeed accidentally.

The derived package receives a separate local.<directory-name> package ID and starts at 0.1.0, so edits cannot overwrite the source version. Its source license and microfeed compatibility range are preserved. Use --package-id, --name, --version, and --author to set publish-ready metadata during initialization, or edit the generated manifest before the first install. Package IDs beginning with microfeed. are reserved for bundled themes. Use a local.* identity for a site-specific version or a package ID you control for a distributable theme. Pass --no-git when another tool will initialize version control.

The generated repository also contains the develop-microfeed-theme coding agent skill. It exports the rendered theme package, not the build sources of the original project. To use microfeed’s complete Tailwind/Vite starter, copy themes/default from a Git-cloned microfeed source repository instead.

Use init to derive a new local.<name>@0.1.0 identity from the site’s effective active, imported, or fallback appearance. Use export when you want an exact installed immutable version and need to preserve its current package ID and version:

npx @microfeed/cli manage theme export --active --instance personal --git --json

# Or export one explicit immutable version.
npx @microfeed/cli manage theme export <theme-id> --instance personal \
  --output .microfeed/themes/example-theme-1.0.0 --git

Export writes the templates, inherited assets, README, local package scripts, fixture, schemas, agent skill, CLAUDE.md bridge, an independent yarn.lock, a pinned Yarn version, and a project-local .yarnrc.yml into an empty directory. The local Yarn configuration preapproves only @microfeed/theme-kit, so a newly published official toolkit can pass Yarn’s package-age gate without weakening the gate for other packages. The generated dependency uses the compatible major range rather than requiring the application checkout’s exact patch version.

Choose exactly one immutable theme ID or --active. When --output is omitted, export uses .microfeed/themes/<package-id>-<version>/. The scaffold also includes the develop-microfeed-theme skill. With --git, it also initializes a local Git repository on main; without that flag, Git behavior is unchanged. It never stages, commits, creates a remote, pushes, installs, activates, or otherwise changes the public site.

Export preserves an installed identity for inspection, archival, or continued development by that package’s owner. Do not modify and republish an exported microfeed.* package. Use theme init to fork its appearance under local.*.

With --json, a successful export returns packageId, version, themeId, selection, output, and gitInitialized. If Git initialization fails, the command exits unsuccessfully but retains the completed scaffold for inspection; do not rerun export into that now-non-empty directory.

The ignored .microfeed/themes/ directory keeps the standalone repository in the same checkout and coding-agent workspace without exposing it to the parent repository. Do not use dist/themes/: dist/ is disposable application build output and a normal build may replace it. The ignored repository remains local until you commit and push it from inside its own directory, and cleanup that removes ignored files can still delete it. Validate the untouched baseline before making the first commit. See Export an installed version for a copy-paste prompt that stops before commit or publication.

Use this command to install a theme package from a local directory or a public GitHub repository, directory, or microfeed-theme.json URL. GitHub branches and tags are resolved to an exact commit before the manifest and declared files are downloaded. The CLI uses an anonymous temporary Git fetch for commit and tree metadata, then downloads only the declared files; it does not depend on GitHub’s unauthenticated REST API quota. Git must be available. V1 does not store GitHub credentials and does not support private repositories.

Canonical bundled:<key> sources install registered rendered packages from the current microfeed checkout. The compatibility alias default continues to resolve to bundled:default:

npx @microfeed/cli manage theme install bundled:default --instance <instance-name>
npx @microfeed/cli manage theme install bundled:podcast --instance <instance-name>
npx @microfeed/cli manage theme install bundled:blog --instance <instance-name>
npx @microfeed/cli manage theme install bundled:photo --instance <instance-name>
npx @microfeed/cli manage theme install bundled:video --instance <instance-name>
npx @microfeed/cli manage theme install bundled:curation --instance <instance-name>
npx @microfeed/cli manage theme install bundled:changelog --instance <instance-name>

The registered keys are default, podcast, blog, photo, video, curation, and changelog. Each source maps to its independent microfeed.* package and immutable release ledger.

Like every manual install, it remains inactive until explicitly activated. theme update reloads the matching canonical Built-in package when the selected version came from the catalog.

Install and update always create an inactive version. Preview it in Settings → Themes, then activate it separately. Templates and manifests are written with parameterized D1 REST queries, avoiding statement interpolation and D1’s SQL statement-size limit. When a package declares assets, the CLI uploads and verifies every object in R2 before inserting the D1 row; a failed insert removes the uploaded objects.

Activation, deactivation, rollback, and deletion create a short-lived, single-use grant in D1 and call the deployed Worker’s management endpoint. The Worker consumes the grant atomically, updates theme state, and purges the THEME_CURRENT cache tag. The CLI never needs an Admin password.

npx @microfeed/cli manage theme <init|install|list|update|activate|deactivate|rollback|export|delete> \
  [directory|source|theme-id] [options]

Option	Meaning
--instance <name>	Select the saved site.
--ref <ref>	Select a Git branch, tag, or commit for install or update.
--path <directory>	Select the theme directory inside a GitHub repository.
--output <directory>	Choose the empty directory used by init or export; export defaults under .microfeed/themes/.
--package-id <id>	Set the new package ID created by init; microfeed.* is reserved for bundled themes.
--name <name>	Set the new theme name created by init.
--version <semver>	Set the initial semantic version created by init.
--author <name>	Set the new theme author created by init.
--active	Export the active installed immutable theme version.
--git	Initialize an exported theme as a local Git repository on main.
--no-git	Create init files without initializing a Git repository.
--local	Use the selected instance’s isolated local D1/R2 simulation.
--preview	Use the deployed preview environment.
--json	Print machine-readable results.
--confirm <theme-id>	Confirm deletion by exactly matching the immutable theme ID.

Common examples:

# Start a new repository from this instance's effective active theme.
npx @microfeed/cli manage theme init ~/microfeed-themes/my-theme --instance personal

# Set public package metadata immediately.
npx @microfeed/cli manage theme init ~/microfeed-themes/my-theme --instance personal \
  --package-id example.my-theme --name "My theme" --author "Your name"

# Install an inactive GitHub version.
npx @microfeed/cli manage theme install https://github.com/example/microfeed-theme \
  --instance personal

# Reinstall the current Default Built-in release as an inactive version.
npx @microfeed/cli manage theme install bundled:default --instance personal

# Install the current Podcast showcase release as an inactive version.
npx @microfeed/cli manage theme install bundled:podcast --instance personal

# Install the Link Digest release, whose search results open original links.
npx @microfeed/cli manage theme install bundled:curation --instance personal

# Exercise a local checkout without changing the deployed site.
npx @microfeed/cli manage theme install ~/microfeed-themes/my-theme --local --instance personal

# Inspect and activate an installed version.
npx @microfeed/cli manage theme list --instance personal
npx @microfeed/cli manage theme activate <theme-id> --instance personal

# Return to the previous theme, or deactivate to the bundled default fallback.
npx @microfeed/cli manage theme rollback --instance personal
npx @microfeed/cli manage theme deactivate --instance personal

# Export one exact installed version as a Git-ready standalone repository, or delete it.
npx @microfeed/cli manage theme export --active --instance personal --git --json
npx @microfeed/cli manage theme export <theme-id> --instance personal --git
npx @microfeed/cli manage theme delete <theme-id> --instance personal --confirm <theme-id>

The unique key is (packageId, version). Reinstalling the same checksum is a no-op; different content under an existing version is rejected. update imports a changed commit as another inactive version and requires the package author to bump SemVer. A soft-deleted package/version identity remains reserved and must not be reused. Deletion rejects the active version, soft-deletes D1 metadata first, and retains an asset owner while any published version or draft still references it. Failed asset cleanup remains retryable by repeating the same confirmed delete command.

The microfeed.* namespace is reserved for Built-in themes and cannot be used by local-directory or GitHub installations. Canonical bundled:<key> sources are trusted catalog installs; default remains a compatibility alias for bundled:default. Admin-created versions and ordinary site-specific forks use local.* package IDs and count as Custom versions even when derived from a Built-in package.

Each environment is limited to 100 non-deleted Custom versions and 20 drafts. Built-in versions do not consume the Custom quota and cannot be manually deleted; deployment synchronization prunes safe superseded releases. An idempotent reinstall of identical Custom content still succeeds at the limit. Delete an inactive Custom version to free a slot; if Admin installation reaches the limit, its draft remains available. theme list selects only package and source metadata, not the full theme bundles.

npx @microfeed/cli manage snapshot

Purpose: Create, download, validate, and restore migration-safe portable snapshots.

Changes: Creates an export, restores a new local instance, or replaces the data in one explicitly confirmed fresh Cloudflare target.

The archive is one .tar.gz containing manifest.json, separate D1 schema and durable-data SQL exports, and every object in the production R2 bucket. The manifest records SHA-256 checksums, object metadata, table classifications, row counts, and the exact ordered D1 migration filenames and hashes.

D1 cannot export FTS5 virtual tables. Snapshot creation therefore removes only the rebuildable unified-search indexes and triggers while the D1 schema and data are exported, then recreates and validates them in a finally recovery step. Item and Page content remains durable and unchanged; search can briefly return an unavailable response during that D1 export window. Restores likewise recreate the derived indexes from the restored items table rather than archiving FTS shadow data.

Long-running snapshot creation and restore steps keep an animated elapsed-time indicator visible. Its brief status message changes as D1, migrations, R2, and verification work advances, then ends with a green success or red failure mark.

npx @microfeed/cli manage snapshot <create|pull|restore> [options]

Option	Meaning
create|pull|restore	Select the snapshot action.
--instance <name>	Select the source or restore target instance.
--output <file>	Choose a new .tar.gz output path for create or pull; existing files are never overwritten.
--local-instance <name>	Choose the new local instance created by pull.
--file <file>	Read this portable archive for restore.
--local	Restore into a new local-only instance.
--dry-run	Validate and print a remote restore plan without changing the target.
--confirm <name>	Approve remote replacement by exactly matching the fresh target instance.

Common examples

1. Back up a production instance into one .tar.gz file

npx @microfeed/cli manage snapshot create \
  --instance my-podcast-domain-com \
  --output my-podcast-domain-com-backup.tar.gz

2. Create a local instance directly from a production instance

# No separate .tar.gz download is required first. This command creates a
# temporary snapshot, restores it into the new local instance, then removes it.
npx @microfeed/cli manage snapshot pull \
  --instance my-podcast-domain-com \
  --local-instance my-podcast-production-copy

Add --output my-podcast-domain-com-backup.tar.gz if you also want to keep the downloaded snapshot.

3. Create a local instance from a .tar.gz file

# The local instance name must be new.
npx @microfeed/cli manage snapshot restore \
  --file my-podcast-domain-com-backup.tar.gz \
  --local \
  --instance my-podcast-archive-copy

If the snapshot has no administrator account, the completed restore prints the exact next step for creating the local dashboard login:

npx @microfeed/cli manage auth setup \
  --instance my-podcast-archive-copy

4. Create a remote instance from a .tar.gz file

# First initialize a fresh remote target with new, nonreused D1 and R2 resources.
npx @microfeed/cli manage init --instance restored-podcast-domain-com

# Validate the archive and target without changing Cloudflare data.
npx @microfeed/cli manage snapshot restore \
  --file my-podcast-domain-com-backup.tar.gz \
  --instance restored-podcast-domain-com \
  --dry-run

# Then restore by confirming the exact target instance name.
npx @microfeed/cli manage snapshot restore \
  --file my-podcast-domain-com-backup.tar.gz \
  --instance restored-podcast-domain-com \
  --confirm restored-podcast-domain-com

5. Create one remote instance from another remote instance

# A local .tar.gz handoff is currently required. Download the source first.
npx @microfeed/cli manage snapshot create \
  --instance my-podcast-domain-com \
  --output my-podcast-domain-com-backup.tar.gz

# Initialize a fresh target with new, nonreused D1 and R2 resources.
npx @microfeed/cli manage init --instance new-podcast-domain-com

# Validate the archive and target, then perform the confirmed restore.
npx @microfeed/cli manage snapshot restore \
  --file my-podcast-domain-com-backup.tar.gz \
  --instance new-podcast-domain-com \
  --dry-run

npx @microfeed/cli manage snapshot restore \
  --file my-podcast-domain-com-backup.tar.gz \
  --instance new-podcast-domain-com \
  --confirm new-podcast-domain-com

Migration safety

Snapshot creation refuses a D1 migration ledger that is not an ordered prefix of this checkout’s migrations/ directory. It also refuses any application table absent from the explicit durable, ephemeral, target-specific, or internal classification. Released migration files and historical classifications are therefore immutable.

Restore validates the complete archive before changing a target. Its migration list must be an exact filename-and-hash prefix of the current checkout:

• An older snapshot restores its original schema and durable data, recreates its d1_migrations ledger, and then applies only newer migrations.
• A snapshot at the current head needs no forward migrations.
• Derived unified-search virtual tables are recreated and repopulated after the durable item and Page data is imported.
• A newer, missing, reordered, edited, or divergent migration history is rejected before mutation.

Durable tables currently include channels, items, Pages, Site Files, settings, users, and login accounts. Sessions, verification records, rate-limit state, and password setup/reset records are recreated empty. The target installation identity is rewritten, while the administrator email and password hash are preserved. Webhook endpoints, encrypted signing secrets, delivery history, budgets, and alerts are deployment-specific and are recreated empty; after a restore, create new endpoints and distribute their new signing secrets. publicBucketUrl is reset to /media/.

Restore safety and recovery

Local restore requires a name that has never been initialized. It builds D1 and R2 state in a temporary persistence directory, verifies it, and only then makes that state active.

Remote restore supports production targets only. First initialize a new target whose D1 and R2 resources are not reused. Initialization records a fingerprint of the fresh database and empty bucket. Always run --dry-run; mutation rejects --yes and requires the exact --confirm <name> value.

Archive validation and target readiness are separate dry-run stages. A message that the snapshot archive is valid confirms only the file and its migration history; it does not approve the restore target. If a completed initialization is missing its fingerprint, an interactive --dry-run offers to repair the local safety record only after read-only checks prove all of the following:

• The deployed Worker exposes this saved installation identity.
• The exact saved D1 database exists, has the current schema and migration ledger, and contains no content beyond the exact channel and settings rows that microfeed automatically creates on the first page request.
• With built-in login, D1 may contain the exact one-time initial password setup record created during initialization. Restore clears that record. Password reset links and all other authentication activity are rejected.
• The installation row belongs to this instance and the R2 bucket is empty.

The same strict checks run automatically if the saved fingerprint changes. This can happen when the fresh Worker creates its exact automatic channel and settings defaults on the first page request. If those defaults are the only change, restore refreshes the local fingerprint and continues. The pending initial password link described above is also safe because restore clears all one-time authentication state. Any user-created content or identity, schema, migration, index, or R2 difference is rejected.

A successful repair or refresh saves the fingerprint in the local instance configuration; the later restore refuses to start if the target changes again. It changes no Cloudflare data or D1/R2 ownership flags, and resources already marked reused remain protected from npx @microfeed/cli manage destroy. The dry run never imports the snapshot. An incomplete initialization still must be finished before restore, while a nonempty or mismatched target is rejected.

After an interrupted restore has finished uploading media, rerunning --dry-run also compares the current R2 inventory with the archive and reports the exact missing or extra object, byte-size difference, or metadata difference. This diagnostic is read-only and avoids repeating the upload just to identify the previous verification failure.

After confirmation, the Worker enters maintenance mode. The CLI reimports the archived schema/data and ledger in one D1 import, applies forward migrations, replaces R2 content using streaming multipart uploads, verifies migrations, tables, indexes, foreign keys, administrator data, row counts, installation identity, and R2 keys/sizes, and only then deploys the current Worker. If R2’s inventory does not immediately reflect completed multipart uploads, verification keeps its spinner active and retries for up to one minute before reporting exact differences. A failure keeps maintenance mode and an owner-only resume journal. Rerunning the same archive and confirmation starts again from the archived schema and data before retrying migrations.

While maintenance mode is active, the CLI temporarily enables the Worker’s otherwise-disabled workers.dev address as a token-protected control endpoint. Every request without the one-time restore token receives HTTP 503, and the normal deployment disables that address again after a successful restore. This keeps restore control independent of custom-domain DNS and Access settings.

If the snapshot contains no administrator account, successful local and remote restore completion prints the exact npx @microfeed/cli manage auth setup --instance <name> command. Running it asks for the administrator email when needed and creates a private one-time browser link for choosing the first password.

Snapshots include password hashes and possibly private media. They are unencrypted and created with owner-only (0600) permissions. Store and encrypt them according to your backup policy.

Cloudflare snapshot create, pull, and remote restore require a ready production R2 bucket and binding. Run npx @microfeed/cli manage deploy --enable-r2 first for a content-only installation. Preview initialization is blocked by the same production-R2 requirement.

npx @microfeed/cli manage status

Purpose: Verify Cloudflare resources, the public site, and dashboard protection.

Changes: Read-only Cloudflare and public-site verification.

Read and verify the exact Worker and D1 binding, public URL, administrator state, pending password setup, and anonymous dashboard protection. When R2 is ready, also verify both the exact bucket and the Worker’s MEDIA_BUCKET binding. A verified content-only Worker is healthy and reports media as either subscription-pending or user-disabled.

When webhooks are enabled, status also verifies the exact Queue ID, producer binding, Worker consumer, resumed delivery, and one hourly Cron. When disabled, it verifies that the same Queue is retained, paused, empty, and has no producer, consumer, or Cron. An unprovisioned environment expects none of those resources. For enabled infrastructure it prints realtime backlog and oldest-message data; Cloudflare-observed writes, reads, deletes, total billable operations, and average retries for that Queue since UTC midnight; account-wide Queue totals for the same window; microfeed-side delivery accounting; and the observation time. Cloudflare Analytics is operational telemetry rather than a billing invoice, so reconcile cost alerts with the account’s Queues dashboard.

npx @microfeed/cli manage status [--device] [--instance <name>] [--preview]

Option	Meaning
--instance <name>	Select the saved site.
--account-id <id>	Confirm the exact saved account.
--device	Use a URL and one-time code instead of a localhost browser callback.
--preview	Check preview instead of production.

This command is read-only. Missing resources or unsafe protection produce a non-zero result with recovery guidance.

npx @microfeed/cli manage destroy

Purpose: Inspect and safely remove a saved Cloudflare deployment.

Changes: Permanently deletes owned Cloudflare resources and local instance data unless explicitly preserved.

Inventory and safely remove one saved Cloudflare deployment. Always begin with --dry-run; it prints the exact site, account, Worker, D1 ID/name, R2 bucket, webhook Queue name and ID, lifecycle state, backlog, Cron schedules, custom address, local folder, actions, and inspection links. If a Queue consumer is attached, the plan includes its Worker name and consumer ID.

npx @microfeed/cli manage destroy --instance <name> --dry-run
npx @microfeed/cli manage destroy --instance <name> --confirm <name>

Option	Meaning
--instance <name>	Select the exact saved site.
--account-id <id>	Confirm the exact saved account.
--preview	Target preview; preview must be removed before production.
--dry-run	Print a read-only plan and dashboard inspection links.
--confirm <name>	Confirm by exactly matching the saved site name.
--keep-data	Preserve owned D1 and R2 while removing the Worker and local state.

--yes and --local are rejected. Reused data is always preserved. The command verifies installation identity, refuses unexpected or replacement resources, pauses a dedicated webhook Queue, explicitly removes Cron schedules, cancels pending webhook deliveries when D1 is preserved, detaches only the single Queue consumer whose Worker name exactly matches the saved deployment, and verifies that no consumer remains. It then deletes the Worker and exact verified Queue before owned data. An unexpected, ambiguous, or replacement consumer fails closed without deleting it. --keep-data preserves D1 and R2, not the environment-specific Queue. Completed steps are recorded and local state is removed last. Rerun the same confirmed command to resume a partial removal.

npx @microfeed/cli manage migrate-pages

Purpose: Create a side-by-side Worker migration from Cloudflare Pages.

Changes: Creates a side-by-side Worker and local state; reuses but does not modify or delete the Pages project, D1, or R2.

Create a differently named Worker beside an existing Pages installation while reusing the existing D1 database and R2 bucket. The command does not modify or delete Pages; traffic cutover remains manual.

npx @microfeed/cli manage migrate-pages [--pages-name <name>] [--project-name <name>] [options]

Option	Meaning
--account-id <id>	Use one exact account.
--instance <name>	Choose the new local saved name.
--pages-name <name>	Select the existing Pages project.
--project-name <name>	Set a new Worker name different from Pages, using the same Worker naming rules as init.
--d1-name <name>	Select the existing Pages D1 database.
--r2-name <name>	Select the existing Pages R2 bucket.
--admin-path <path>	Set the new Worker dashboard path.
--admin-auth <built-in|none>	Choose dashboard authentication.
--owner-email <email>	Set the new Worker administrator email.
--no-open	Do not open the private password page automatically.
--yes	Approve the displayed reuse and supported defaults.

--preview is rejected because the new migration Worker is already deployed side by side.

npx @microfeed/cli manage domain

Purpose: Configure and verify a production custom domain.

Changes: Deploys the production Worker with a Cloudflare Custom Domain and updates local state.

Configure and verify a Worker Custom Domain for production. Preview always uses its workers.dev URL. If the hostname remains attached to a recorded Pages project, the command stops and links to the manual Pages detachment screen.

npx @microfeed/cli manage domain [--instance <name>] [--hostname <hostname>]

Option	Meaning
--instance <name>	Select the production site.
--account-id <id>	Confirm the exact saved account.
--hostname <hostname>	Set the custom hostname without a path.
--yes	Skip supported post-deployment prompts.

A pending browser password link is replaced with one using the final hostname.

npx @microfeed/cli manage access

Purpose: Guide and verify optional Cloudflare Access protection.

Changes: Opens Cloudflare for a user-managed Access application; the CLI itself only guides and verifies.

Print exact guidance for an optional Cloudflare Access application that covers only the dashboard path. The user saves the Access application in Cloudflare; the CLI can then verify that the dashboard is intercepted while public routes stay available.

npx @microfeed/cli manage access [--instance <name>] [--preview] [--open]

Option	Meaning
--instance <name>	Select the saved site.
--account-id <id>	Confirm the exact saved account.
--preview	Target preview instead of production.
--open	Open the Cloudflare Access application page immediately.
--yes	Print instructions without interactive opening or verification prompts.

npx @microfeed/cli manage auth

Purpose: Set up or change the built-in dashboard login and path.

Changes: Updates administrator credentials, configuration, D1 rows, and sometimes redeploys the Worker. Local-only disable changes only saved configuration and its generated Wrangler file.

Manage the built-in administrator login and path.

When you are already signed in and know the current password, use the dashboard’s Account settings for a routine email or password change. Use this command for setup, forgotten-password recovery, dashboard-path changes, disabling login, or administration of the selected saved site.

npx @microfeed/cli manage auth <setup|reset-password|change-email|change-path|disable> [options]

Action	Effect
setup	Remotely, enable the built-in login and create a first-password browser link when needed; locally, securely prompt for the initial password.
reset-password	Remotely, create a single-use reset link; locally, securely prompt for and immediately store the replacement password. Completing the reset revokes the owner’s app authorizations and credentials.
change-email	Update the administrator email and revoke existing sessions.
change-path	Redeploy at a new dashboard path; the old path returns 404.
disable	Disable built-in protection after a high-visibility warning and immediately revoke the owner’s app authorizations and credentials. Locally, the development dashboard opens without login; remotely, the dashboard may become public.

Without an action, npx @microfeed/cli manage auth prints its subcommand usage, options, and examples. It does not select an instance, inspect authentication state, or change anything. Choose setup, reset-password, change-email, change-path, or disable explicitly.

After an action is selected, the CLI shows a Dashboard login target summary before prompting or changing anything. It identifies the instance, whether the command targets local data, Cloudflare production, or Cloudflare preview, the dashboard location, and the selected action. Cloudflare targets also show the Worker name. Check this summary before entering an email or password.

A saved local-only instance is detected automatically after an action is selected. It supports setup, change-email, reset-password, and disable. Local disable keeps the existing account, credentials, D1 data, and R2 data, then regenerates the instance configuration; restart its development server if it is running. Changing the dashboard path remains remote-only. A Cloudflare-connected site’s local sandbox cannot override the saved production authentication mode. Remote setup does not redeploy when built-in login is already active.

Target selection follows the saved instance type:

• A local-only instance automatically uses its local data; --local is not required.
• A Cloudflare-connected instance targets Cloudflare by default. Add --local only to target its separate local development sandbox.
• --preview targets a Cloudflare preview and cannot be combined with a local target.

Snapshot restore still requires --local because it creates a brand-new local instance whose type cannot be inferred yet.

Option	Meaning
--instance <name>	Select the saved site.
--account-id <id>	Confirm the exact saved account.
--preview	Target the preview login.
--local	Use a Cloudflare-connected instance’s separate local development sandbox; optional for local-only instances.
--owner-email <email>	Supply the email for setup or change-email.
--admin-path <path>	Set the new path for change-path.
--admin-password <value>	Unsafe remote-only value for setup or reset-password. Never use from an agent.
--no-open	Print a setup/reset link without opening it.
--yes	Skip supported confirmations, including the disable warning.

Local examples:

npx @microfeed/cli manage auth change-email \
  --instance microfeed-org-local \
  --owner-email new-owner@example.com

npx @microfeed/cli manage auth reset-password \
  --instance microfeed-org-local

npx @microfeed/cli manage auth disable \
  --instance microfeed-org-local

Local password reset always uses hidden password and confirmation prompts. Local disable shows a warning unless --yes is supplied and does not query or modify feed content or R2 data. Both actions revoke app authorizations and credentials in the selected D1 database.

npx @microfeed/cli manage config

Purpose: Validate saved state and generate a local Wrangler configuration.

Changes: Writes only the generated local Wrangler configuration when needed.

Validate saved state and regenerate the selected local Wrangler configuration without deployment or a development server. With --local, missing local-only state and development secrets may be initialized.

npx @microfeed/cli manage config [--instance <name>] [--preview|--local]

Option	Meaning
--instance <name>	Select the saved site.
--preview	Generate preview configuration.
--local	Generate the local view and ensure local development values exist.

npx @microfeed/cli manage instances

Purpose: List local, managed, and connectable microfeed installations.

Changes: Reads local saved state and available Cloudflare Workers; does not change Cloudflare.

List local-only sites, Cloudflare sites in local management state, and compatible Cloudflare Workers available to connect. Output is grouped by account and includes each media-storage state and ready-to-run connect commands. No Cloudflare resources are changed.

npx @microfeed/cli manage instances [--account-id <id>] [--json]

Option	Meaning
--account-id <id>	Limit Cloudflare discovery to one available account.
--json	Print machine-readable local, accounts, and discovery messages groups.

npx @microfeed/cli manage use

Purpose: Select the default saved site.

Changes: Changes only the active-instance pointer in local management state.

Set the active saved site used when later commands omit --instance. This changes only local management state.

npx @microfeed/cli manage use <name>

Option	Meaning
--instance <name>	Alternate flag form of the positional site name.

Built-in help

npx @microfeed/cli manage
npx @microfeed/cli manage help
npx @microfeed/cli manage help destroy
npx @microfeed/cli manage destroy --help

Top-level help lists every command. Command help is generated from the same metadata inventory used by documentation consistency tests.

Environment variables

Variable	Purpose
MICROFEED_INSTANCE	Default site name when --instance is omitted.
CLOUDFLARE_PROJECT_NAME	Default production Worker name during initialization.

Wrangler manages the Cloudflare account and browser-login environment internally. Do not use environment variables to pass a microfeed password.

Maintaining this reference

The command inventory and terminal help live in manage-cli/help.ts. This file is the checked-in human-and-agent interface contract. Tests require every implemented command and every metadata option to appear here, so additions cannot silently disappear from either discovery surface.

When changing the CLI:

1. Update command behavior.
2. Update manage-cli/help.ts.
3. Update the matching section in this document.
4. Run the management CLI help/documentation consistency tests and the normal repository checks.