Fresh install

The test ladder upgrades a running store: golden database, setup:upgrade, the extension's patches applied on top of an installed schema. A customer's first install is the other path: an empty database, no env.php, every module's schema and patches applied in dependency order by setup:install. An extension can pass one and fail the other: a data patch that reads a table a later core patch creates, a patch that saves configuration before the default store exists, a declarative schema that names a foreign key before its owner.

--fresh-install runs exactly that instead of the ladder:

furnace run --gate=all --fresh-install -c m248
furnace run --gate=all --fresh-install -p 3            # every matched cell
furnace run --gate=all --fresh-install --release=1.2.0 # a released version

It needs --gate=all. It composes with every install method and with a harness: the code reaches the cell the declared way, then Magento is installed from nothing around it.

What happens on a cell

Step	What it does
reset	golden restored, app/code purged
composer require or dependencies + copy	the code is placed the declared way, verified by state
settings	locale, currency, timezone, search engine, host, port and admin path are read from the cell before anything is removed; a cell whose settings cannot be read is left untouched
remove config.php	app/etc/config.php removed (the detail says how many modules it declared)
remove env.php	app/etc/env.php removed
recreate database	DROP DATABASE, CREATE DATABASE, under the same lock the restore uses, proven by counting tables afterwards
setup:install	with the settings read above, the cell's database credentials, a furnace_fresh admin account and the search index prefix <cell>_fresh; passes only when the command exits 0 and env.php and config.php exist and the database has tables
modules enabled	every module of the extension is 1 in the new config.php
schema up to date	setup:db:status reports all modules up to date right after the install
storefront	the home page answers HTTP 200 with a complete page: not Magento's 404, not its error page, not a PHP fatal
cleanup	the usual golden restore: Composer metadata, composer install, fingerprint, database, identity files, compiled state

No upgrade, tests or production build run. The static tier still runs on the host before the cells (skip it with --skip-static if you want only the install), and for a harness the source gates do not run on the cell in this mode.

Verified

m248 (Magento 2.4.8-p4, PHP 8.4), m2-faqs by composer require from the staged path, 2026-10-28:

Step	Result
reset	golden restored in 8.5 s
composer require	8 packages in 7.5 s
settings	en_US, USD, Europe/Warsaw; opensearch at 127.0.0.1:9200, index prefix m248_fresh; admin path /admin
remove config.php	395 modules were declared
recreate database	m248 dropped and created empty, 1.6 s
setup:install	427 tables, 404 modules enabled, 85 s
modules enabled	8 of 8 enabled by the install
schema up to date	all modules are up to date, 6.9 s
storefront	home page served, 105 kB
cleanup	golden restored; doctor -c m248 fully green afterwards

The database password is passed to setup:install on its command line and is masked in the run log; the log records --db-password=***.

What the verdict means

A fresh-install run makes a different claim from a certification, and the report says so: it records purpose: fresh-install, demands only the install and fresh-install gates per cell, and its verdict reads fresh install passed, never certified. Test-protocol conformance does not sink it (a suite furnace cannot drive still installs or does not), and a skipped static tier is not a gap. Matrix coverage still applies: a single-cell run is "not proven" fleet-wide until --allow-incomplete accepts that, exactly as for a certification.

Deliberate differences from the golden cell

• The search index prefix is <cell>_fresh, not the cell's own. setup:install may touch the shared OpenSearch, and the golden's indices have to survive it.
• Every module in the codebase is enabled, as on any customer's fresh install. The golden cell has a few disabled (two-factor authentication among them); that is a cell choice, not something a customer would have.
• A new crypt key and a new admin account (furnace_fresh) are created. Both go with the database on restore.

If a run is interrupted

Between remove env.php and the restore the cell has no env.php. A cell without one would normally be invisible to every furnace command. Discovery therefore falls back to the golden copy of env.php, which carries the same database identity, so doctor still lists the cell, clean --restore can put it back, and the next run recovers it on its own.

furnace clean --restore -c m248