nf

Usage

Use this page as a map for day-to-day work. Detailed command reference lives in Commands; implementation and contributor notes live in Development and Architecture.

First-Time Setup

Configure global settings before creating or managing projects:

nf config init
nf password set-salt <shared-salt>

nf config init walks through required settings, including provider API keys and base_domain. Use nf password set-salt with the shared team salt so derived passwords match across machines. See Configuration for config files, secrets, and password derivation.

Project Setup

Create repo metadata from the project repository:

nf init

Project repositories use nf.json. This file is safe to commit and must not contain API tokens, SSH keys, live database passwords, provider secrets, or mutable provider inventory.

By default, nf init derives the project slug from the current git root folder and assumes the WordPress theme lives in theme/:

nf init \
  --project-slug client \
  --theme-slug client \
  --theme-source theme

After nf init, run project-local commands from that repo so theme, env, plugin, alias, and remote are available.

Common Workflows

Start local WordPress from a repo:

nf env up
nf env show

Read Local Development for Docker env startup, WP-CLI, logs, Mailpit, the database UI, resets, and local passwords.

Create infrastructure and hosted WordPress envs:

nf provider check linode
nf target add linode app1 --dry-run
nf site add app1-linode client --dry-run

Read Targets for target creation and Sites for remote WordPress site creation, inspection, passwords, shell access, WP-CLI, and exports.

Add or manage staging:

nf site staging status client.app1-linode
nf site staging add client.app1-linode --dry-run

Read Staging for staging lifecycle commands.

Connect the current repo to a remote env:

nf site refresh
nf remote add production client.app1-linode:live
nf remote show production

Read Remotes for repo remote setup. Remotes stay pointed at env IDs such as client.app1-linode:live, not public domains.

Build and deploy a theme release:

nf theme tasks
nf theme build
nf theme package
nf theme deploy production --dry-run

Read Themes for task execution, clean release artifacts, deploys, and rollback.

Expose root aliases to existing WordPress content:

nf alias add files wp-content/uploads/public/files
nf alias status production
nf alias sync production

Read Aliases for root-level symlinks to paths under wp-content.

Manage WordPress plugins declared in nf.json:

nf plugin status
nf plugin diff production
nf plugin install production --dry-run

Read Plugins for plugin configuration, status, diff, and install behavior.

Move data safely:

nf env snapshot add before-content-work
nf env snapshot list
nf env pull production --dry-run

Read Snapshots for local and remote snapshots. Read Sync before pushing or pulling a database or mutable wp-content.

Launch a public domain:

nf domain list production
nf domain add production www.client.com client.com --primary --dry-run
nf domain check production www.client.com client.com
nf domain primary production www.client.com --search-replace --dry-run

Read Domains and Launch before a launch window. Public DNS remains the client’s responsibility; nf attaches domains, prints DNS instructions, verifies readiness, and performs the primary cutover.

Safety Pattern

Guarded infrastructure and sync mutations support a plan-first flow:

nf <command> --dry-run
nf <command> --execute --yes

When run interactively without --yes, these commands prompt before changing remote infrastructure or content. In non-interactive mode, remote execution requires both --execute and --yes.

Theme deploy and plugin install also support dry-run or confirmation flags, but their exact execution flags differ. nf alias sync mutates only root-level symlinks; run nf alias status first when reviewing a remote env.