Try Forge First

Installation assumes you have already decided. This page is for the step before that: seeing what Forge is without standing up a Postgres, a container registry login and an .env file. The code ships several evaluation surfaces that the install path never mentions, and they cost anywhere from nothing to twenty minutes.

They are listed cheapest-first. Each one shows you something real and hides something real, so the last section says plainly what none of them can tell you.

The options at a glance

Option	What you need	What it gives you
Read the test-case library	A browser	~730 written acceptance cases describing how the whole business lifecycle should behave
Run the static demo SPA	Node, or Docker with no registry login	Every screen, populated, clickable — no server behind it
Run the manual test bed	Node	The same case library as a browser-based runner you can work through against an install
Install with --seeded	Docker + a GHCR token	The real stack, pre-populated with fabricated users, customers and jobs
Install clean	Docker + a GHCR token	Your shop, from an empty database — see Installation

Read the test-case library — nothing to install

The forge-test repo is a library of manual acceptance cases covering the lifecycle of a manufacturing business: bootstrap from an empty database, foundations, master data, first transactions, the first production cycle, then exception cycles — damage, preventive maintenance, RMAs, period close, traceability, subcontract. Alongside those sit eleven cross-cutting suites (accounting, audit, bulk operations, concurrency, documents, edge cases, integrations, list views, notifications, permissions, reports).

The important property for an evaluator is the authoring rule the repo states about itself: cases are written against industry-standard behaviour, not against a particular screen or menu path. If the application cannot do what a case describes, that is treated as a bug in the application, not in the case. So the library doubles as a specification you can read as "here is what this product believes an ERP owes you", and later as a checklist you run against your own install.

Start with the repo's docs/ — the schema, the glossary, the per-phase case files and their manifests. Nothing here is automated; a person reads a case, performs the steps, and records what happened.

What it cannot tell you: whether Forge actually passes. The library is the standard, not the result.

Run the static demo — no API, no database, no registry token

forge-ui builds a second, API-less variant of the whole application. The demo build configuration swaps in an environment where apiUrl and hubUrl are deliberately empty strings, and an HTTP interceptor registered ahead of everything else short-circuits every API call, answering it from checked-in JSON under forge-ui/public/demo-data/ (one file per entity, exported from a genuinely seeded instance, plus synthesized responses for dashboards, search, counts and reports). Sign-in is stubbed: any credentials return a session for a demo user holding several roles at once.

Two ways to run it, neither of which touches ghcr.io:

# From source — Node only, no Docker at all
git clone https://github.com/armoryworks/forge-ui.git && cd forge-ui
npm ci
npx ng serve --configuration demo

# As a container — builds locally from the umbrella tree
git clone https://github.com/armoryworks/forge.git && cd forge
./bootstrap.sh                       # clones forge-ui and friends into this tree
docker compose -f docker-compose.demo.yml up -d --build

The container is a single nginx serving a static bundle with no upstream of any kind — the compose file wires no API, no database, no object storage. It binds to loopback by default (DEMO_BIND), and the same service exists in the main deploy stack under the demo profile, so an existing install can serve a demo alongside itself by opting that box into COMPOSE_PROFILES=demo.

What the demo is genuinely good for:

• Shape and density. Every list, form, board and dashboard, populated with plausible records. This is the fastest way to answer "is this too much software for my shop, or not enough?"
• A guided start. The demo build has its own welcome screen that asks two plain-language questions — what your shop mainly does, then a couple of optional add-ons — and configures the demo's active modules from the answers before you ever sign in.
• Watching Capability Gating work. A module switcher rebuilds the capability descriptor live, so you can flip between the full suite and one cordoned module and watch the navigation and the gated controls reconfigure around you. That is the single hardest thing to explain in prose and the easiest thing to show.

The demo build marks itself — a [DEMO] prefix on the page title, a corner chip and a faint watermark — so a screenshot taken against it is never mistaken for a real install.

What it cannot tell you. There is no server, so everything a server decides is absent or faked:

• Nothing is enforced. No validation beyond what the form does, no workflow gates, no approval routing, no numbering sequences, no posting to the books. See Workflow Gates and Approvals for what the real system does here.
• Permissions are meaningless. The stubbed session holds several roles at once and MFA reports itself as not required. You cannot evaluate the access model from the demo.
• Writes are a fiction. Edits land in an in-memory overlay so screens behave; a page refresh resets everything to the shipped snapshot.
• No real-time, no integrations, no documents. SignalR, accounting providers, carriers, e-mail, storage and PDF generation are all server-side and simply are not there. Accounting always reports itself as standalone.
• No performance signal. Response times are the browser reading a JSON file.

Run the manual test bed

forge-test/test-bed/ is an Angular runner that compiles the Markdown-and-YAML case library into JSON and drives it in a browser, storing results in IndexedDB. It needs no server and no database of its own — results stay in the tester's browser.

git clone https://github.com/armoryworks/forge-test.git
cd forge-test/test-bed
npm install
npm start

npm start runs the content compile first, so the runner always reflects the cases in docs/. The deploy stack also carries this as a service under the test profile (TEST_BIND / TEST_PORT), which is how you would host it next to a real install for a team to work through.

This is the piece that turns an evaluation into evidence: stand up a seeded or clean install, then work the Phase 0–5 sequence against it and record what actually happened. Bugs found in the application belong on the Forge repo; bugs in a case or the runner belong on forge-test.

Install with --seeded

When the demo has done its job, the next honest step is the real stack with fabricated data in it:

./setup.sh --seeded

That is the normal install (see Installation for prerequisites and deployment targets) with SEED_DEMO_DATA turned on. Setup prompts for a temporary password for the seeded accounts and enforces a complexity rule on it. Beyond the reference and configuration data every install gets — roles, track types, the chart of accounts, sales-tax base rates, costing templates — the seeded path adds an admin plus team members across the role catalogue, customers, vendors, jobs spread over the stage board, historical transactional records and a set of pre-packaged reports.

Now everything the demo faked is real: the API validates, the gates fire, the books post, jobs move, the audit log fills in. This is the only option that tells you whether Forge does what the test cases say it should.

Two things to know before you use it:

• A seeded box is not a starting point for your production box. Demo seeding writes fabricated users, customers and jobs straight into the live database, and there is no un-seed. The API refuses to boot if SEED_DEMO_DATA is on while the runtime environment is Production, unless you explicitly override that guard — which is the signal to take seriously. Evaluate on a seeded install, then install clean for real, or wipe and start over with --fresh.
• Integrations may still be canned. A stock evaluation install ships the mock posture, so accounting, shipping and AI can appear to work against fabricated data. Configuration and Integrations explains the mode resolution and the readiness report that tells you what your box is actually talking to.

What none of these answer

Use the evaluation surfaces for shape, workflow and fit. They will not answer the questions that decide an adoption, and it is better to read those up front than to discover them in month three:

• How big a shop this fits, and what the architecture implies about growing into it.
• One install is one company — sites and currencies are modelled; a second legal entity means a second stack.
• What is mock, half-built or absent — outbound webhooks, some EDI transports, machine data collection, several analytics services. The seeded install will happily show you screens for all of them.
• Getting your data back out, which Forge answers well but which no demo can demonstrate.

All of that lives on Limits and Non-Goals, which is deliberately the least flattering page in this wiki and the one worth reading second. Then Architecture for how it is built, Feature Reference for what each area covers, Business Shapes if you are not a job shop, and Installation when you are ready.