开源MCP工具

Quick install

These commands assume a fresh machine with no DPF repo yet. If you've already cloned the repo (contributors), skip to Step 2 from inside the repo.

Step 1 — download the installer (run from any directory)

iwr -UseBasicParsing https://raw.githubusercontent.com/OpenDigitalProductFactory/opendigitalproductfactory/main/install-dpf.ps1 -OutFile install-dpf.ps1

Step 2 - run it (prompts for install directory; may suggest a non-C drive)

powershell -ExecutionPolicy Bypass -File install-dpf.ps1 ```

macOS Apple Silicon — Early access · [full guide](docs/install/macos.md)

The Unix installer sources helper libraries from inside the repo, so you must clone first.

```bash

Step 2 — run the installer

bash install-dpf.sh ```

Linux (native Docker) — Early access · [full guide](docs/install/linux.md)

git clone https://github.com/OpenDigitalProductFactory/opendigitalproductfactory.git
cd opendigitalproductfactory
bash install-dpf.sh

Cloud Single VM (AWS / GCP / Azure) — Early access · pilots wanted · [full guide](docs/install/cloud-single-vm.md)

Inside the VM:

git clone https://github.com/OpenDigitalProductFactory/opendigitalproductfactory.git
cd opendigitalproductfactory
bash install-dpf.sh --headless --release

Terraform modules for the cloud-VM path live under infra/terraform/single-vm/{aws,gcp,azure}/.

The installer asks one question — Ready to go (pre-built images; Build Studio is the governed development surface) or Customizable (full source clone; Build Studio and a local IDE share the same workspace). Both modes include the full platform; the difference is whether direct IDE access is part of the supported workflow. For serious source changes while Build Studio continues hardening, use Customizable mode. Login credentials are saved to .env / .admin-credentials at the end of installation.

If you hit a wall — happy-path success stories and "the installer hit a wall at step X" failures are equally useful — open an issue using the Install verification report template and attach the bundle produced by bash install-dpf.sh doctor.

---

Architecture & deployment specs

The deployment architecture keeps Windows, macOS, native Linux, customer-cloud, and TAPPaaS aligned to the same canonical contracts while each target carries its own maturity level:

• Deployment Contracts — 10 canonical contracts every deployment target wraps (release artifacts, runtime config, lifecycle, identity, edge, build execution, observability, secrets, LLM / agent routing, client / API surfaces)
• Cloud Deployment Design — substrates (Single VM, Managed container service, Managed Kubernetes) and packaging targets
• DPF Edge Node — host-resident trust + connectivity for discovery, MCP / A2A gateway, identity brokering
• Edge Node Deployment Matrix — Mode 1 container vs. Mode 4 native binary per host substrate, with the verified-2026-05-20 Docker Desktop finding
• Build Execution Provider — sandbox lifecycle abstraction so Build Studio runs on substrates beyond local Docker
• Mac / Linux Installer-Parity Roadmap — 10-phase implementation plan for native macOS (Apple Silicon) + native Linux installs

For runtime topology — container layout, hardware tiers, Docker Compose breakdown, monitoring stack — see docs/architecture/platform-overview.md.

---

Branch model + PR workflow

• Topic branches off origin/main — short-lived, one PR per branch
• All changes land via PR; main is the release branch, force-push protected
• DCO sign-off required on every commit (git commit -s)
• For concurrent sessions: each runs in its own git worktree; use git commit --only <paths> with positional arguments so a parallel session's staged files do not sweep into your commit
• Never --no-verify, never --no-gpg-sign, never amend across sessions

Source isolation vs. runtime isolation

Worktrees created by scripts/new-dev-worktree.sh give you source-control isolation — your branch, your working tree, your commits — so concurrent sessions and the self-upgrade loop don't reset your work. They are not a second runtime.

For each change:

• Edit and commit from the worktree.
• Cheap source-local checks (targeted Vitest, pnpm typecheck on the changed package) can run in the worktree if its deps resolve cleanly.
• For anything that exercises the live platform — portal routes, server actions, MCP tools, DB-bound behavior, Build Studio flows — verify against the canonical install at the root clone (or a leased shared nonprod environment), and capture that evidence in the PR.
• If the worktree can't run a build/test because pnpm/corepack isn't on PATH, workspace symlinks point outside the worktree, the Prisma client is missing, or Turbopack rejects a cross-workspace symlink — that's a harness limitation, not a product defect. Route the verification through the shared local-CI convergence sandbox (one runtime every worktree leases sequentially via local-integration-ci); per-worktree runtimes don't scale at DPF's expected 1k–10k concurrent worktrees.

Full rule: AGENTS.md §5 and worktree-is-source-control-not-runtime. The Quick dev commands below assume you're either in the root install or a worktree whose dep graph already resolves — they are not a claim that every worktree is a standalone runtime.