Commands

Command	What it does
goodfellow dev	Serves the site, rendering each page from the files on disk, plus the admin panel at /admin, which saves to those files
goodfellow build	Writes one HTML file per page that's shown at the time (see Scheduled publishing) to dist/, builds the CSS and copies public/. Also writes sitemap.xml (without pages hidden from search engines), robots.txt and feeds of dated collections if the site's address is set, the admin panel if the config has a backend or demo, the JavaScript for Client Components, with Preact where they all work with it unless --react, GOODFELLOW_REACT=1 or the config says React, calendar files and month pages for collections of events, lists' later pages and pages for each choice, a page at each redirect's old address and _redirects for Cloudflare Pages, a copy of the site's Google Fonts in fonts/google/, which its pages load in place of Google's, plugins' admin frames, and what their build steps write, the content API in api/ unless the config turns it off, a search index if a page has a Search block, and goodfellow-build.json, which says what the site was built from and when what it shows by today's date next changes, for the nightly check. For a site in a subfolder, it says where search engines look for robots.txt (see Sites in a subfolder)
goodfellow preview	Serves dist/ the way a host would, including the "Page not found" page
goodfellow index	Writes the search index for a site built another way
goodfellow update	Updates Goodfellow, and blocks from its registry, if the site still builds with the update (see Keeping a site up to date)
goodfellow due [--since <time>]	Says whether a scheduled page or item has been shown or hidden since --since (an ISO time; the last hour without one), so the site needs building again. On GitHub Actions it also sets the step's due output to true or false, which the starters' hourly check reads; --output <file> adds it to a file instead, for a CI setup that reads it in its shell. It's also due the first check after the live site's goodfellow-build.json says what it shows by today's date changes
goodfellow nightly [--mode <mode>] [--output <file>]	Says whether tonight's build is needed: when the site has changed since the live site was built, something it shows by today's date has, or an update is available, reading the live site's goodfellow-build.json. --mode (or GOODFELLOW_NIGHTLY) is changed, the default, always or off. On GitHub Actions it sets the step's build and update outputs, or adds them to --output; see Rebuilding overnight
goodfellow task [--out <file>]	Runs one of a plugin's tasks for the admin panel, as the starters' task workflow and job do: the request comes in GOODFELLOW_TASK_REQUEST, GOODFELLOW_TASK_PLUGIN, GOODFELLOW_TASK_NAME, GOODFELLOW_TASK_INPUT and GOODFELLOW_TASK_KEY, and the answer, sealed to the request's key, goes to --out (default: goodfellow-task-result.json), even when the task fails. Secrets come from the environment and from GOODFELLOW_SECRETS, a JSON object, and the task gets only those its plugin declared
goodfellow content link [folder]	For a site whose content is in a repository of its own: links content/ and public/media/ to it, in folder (default: content-repository), so goodfellow dev reads and saves its files
goodfellow content copy [folder]	Copies them from it instead, as builds do
goodfellow broker add [folder] --host <host>	Writes the site's token broker's repository into folder (default: beside the site's, named after it with -signin), for github-pages (with --domain), gitlab-pages, cloudflare-pages or vercel
goodfellow broker use <address>	Signs editors in at the token broker from then on, once the site has rebuilt; goodfellow broker remove stops it
goodfellow sign-in service <address>	Names a GitHub site's sign-in service, for Sign in with GitHub; goodfellow sign-in client-id <id> names a GitLab site's OAuth application or a Bitbucket site's OAuth consumer instead, and goodfellow sign-in remove takes either out. Site Settings → Security does the same, except for sites whose content is kept in a repository of its own
goodfellow admin add <address>	Names the admin panel's address of its own, such as admin.example.org, in goodfellow.config.tsx, for sites whose config the admin panel can't publish, such as those whose content is in a repository of its own
goodfellow admin check	Once the site has rebuilt with it, checks that the site's pages at the admin address leave it before running anything, then marks it checked, from which the admin panel opens only there; goodfellow admin remove stops using it
goodfellow blocks add <item>	Installs a shadcn registry item (button, @acme/hero, or an item's address) with shadcn's own CLI and makes a block of its component, with fields from its props, then typechecks and renders it and lists what it couldn't do (see Any shadcn component as a block). With --registry <folder>, writes the block into a block registry there instead; with --native <folder>, also makes its version for the Expo app in that folder, with shadcn-tamagui-codemod. Needs TypeScript 7 in the site
goodfellow import wordpress <file or address>	Brings a WordPress site's pages, posts, categories, tags, menus and media into the site, from its export file or its address (see Move from WordPress). --dry-run says what would come across and changes nothing
goodfellow import markdown <folder>	Brings a folder of Markdown files into the site: the files at the top as pages, and each folder as a collection, unless --pages or --collection names it (see Import Markdown files). --dry-run says what would come across and changes nothing
goodfellow import site <zip or folder>	Brings another Goodfellow site's export into the site: its pages, collection items, synced blocks and media, keeping the site's version of what both have differently unless --take export (see Move content between Goodfellow sites). --menus, --settings, --layout and --redirects bring those in too, --replace makes the site's content the export's, --without-missing-blocks brings in what uses blocks the site lacks without them, and --dry-run changes nothing
goodfellow export wordpress [file]	Writes the site as a WordPress export file, at file or in a file named after the site, which WordPress imports with Tools → Import → WordPress (see Move from WordPress)
goodfellow export markdown [folder]	Writes the site's pages and items as Markdown files, with its media and menus, in folder or a folder named after the site, which has to be empty (see Export as Markdown). --scheduled also exports what a schedule hides now, as drafts, and --links files links to the files rather than the site's addresses
goodfellow export site [file]	Writes the site's content, media and the lists of blocks and plugins it added as a zip, at file or in a new file named after the site, for another Goodfellow site to import (see Move content between Goodfellow sites)

Next.js sites have the same update, due, nightly, task, content, blocks, admin, import and export commands as goodfellow-next update, goodfellow-next due, goodfellow-next nightly, goodfellow-next task, goodfellow-next content, goodfellow-next blocks, goodfellow-next admin, goodfellow-next import and goodfellow-next export, goodfellow-next broker use and remove, and goodfellow-next sign-in.

Options: --root <dir>, --out <dir>, --port <port>, --base <path>, for import, --dry-run, for import site, --take site|export, --replace, --menus, --settings, --layout, --redirects and --without-missing-blocks, for export markdown, --scheduled and --links site|files, and for blocks add, --registry <folder> and --native <folder>.

Site checks

goodfellow build ends with what the site checks find, the same ones the admin panel runs when publishing: links to pages, items and media the site doesn't have are errors, and pages without a title or description, and theme colors text is hard to read on, are warnings. On GitHub Actions each also shows as an annotation on its file. They don't stop the build, so a link broken outside the admin panel, such as by deleting a file in the repository, never takes the site down; goodfellow build --strict fails the build when there are errors, for checking changes made in code before they're merged.

It then checks every built page for accessibility problems: the ones the admin panel warns about (images without a description, headings that skip a level, and links that don't say where they go), and the rules of axe-core, the checker browsers' developer tools use, each explained in plain words, such as a form field without a label or a frame without a title. Problems in the header and footer are listed once, not for every page. Automated checks find only some accessibility problems, so a build with none doesn't mean the site is accessible: try it with a keyboard and a screen reader too. Contrast is checked on the theme's colors, not on built pages, since that needs a browser.

Next.js sites get the checks of built pages from goodfellow-next finish; the checks of content files don't run in next build yet.

goodfellow dev uses port 4321, or the next free one if another program has it, and goodfellow preview uses 4322. Each prints its address when it starts. goodfellow dev answers only at localhost and this computer's IP addresses, since its admin panel saves to your files without signing in: a website can point its own name at your computer, and the development server refuses requests to any other name. Only this computer can open goodfellow preview, since it may show what isn't published yet; --network lets other computers on the network see it too.

Serving from a subfolder

Some hosts serve a site from a subfolder, such as /my-repo/ on GitHub Pages. The base path comes from --base, then the GOODFELLOW_BASE environment variable, then base in goodfellow.config.tsx. Every root-relative link and image in the built pages is adjusted to match, including links inside formatted and Markdown text.

The site's address (Site Settings → General) should be the full public address, subfolder included.