DevForgeKit 3.0: First Public Release
After 30+ releases of internal iteration, DevForgeKit is public: a local-first platform for building, managing, analyzing, and maintaining developer workstations.
DevForgeKit started as a dotfiles repository with ambitions. Thirty-plus releases later, it's a four-layer platform: a bash bootstrap that provisions a brand-new machine, a Node.js CLI with twelve subsystems, a manifest-driven plugin layer, and a registry of 261 curated packages, all local-first, all MIT-licensed, and now public on GitHub.
What ships in 3.0
The headline numbers: 261 registry packages across 35 categories, 17 project generators, 50 environment profiles, 196 compatibility rules, a 29-page interactive dashboard with 20 themes, an AI assistant speaking to 7 providers, and 1,350 tests holding it all together.
Everything runs from one command. The dashboard opens when you run devforgekit with no arguments; any argument takes the classic CLI path.
# Provision everything
./devforgekit install
# Open the interactive dashboard
./devforgekit
# Generate a project
./devforgekit new nextjs my-app
# Run deep diagnostics
./devforgekit doctorLocal-first, honestly scoped
Two principles shaped every subsystem. First, local-first: your environment state, AI chat memory, workspace secrets, and benchmark history never leave your machine. Secrets are AES-256-GCM encrypted with a machine-local key; the AI event log records what happened, never conversation contents.
Second, honest scoping: if a capability isn't real, DevForgeKit says so. AI commands without an API key degrade to clear messages instead of fake responses. Install sizes are measured live rather than stored as fabricated metadata. The plugin 'sandbox' is documented as a timeout, not a security boundary.
Cross-platform for real
v2.2.3 brought genuine Linux and Windows support: apt, dnf, and pacman on Linux; winget, choco, and scoop on Windows; WSL detected automatically. 222 packages carry platform-specific install steps, and the platform layer fails with one clear message (never a raw spawn error) when something is genuinely macOS-only.
What's next
This website is milestone one. After that: Homebrew and npm distribution so installation is a single command (both have since shipped), plus a live remote registry and the hosted plugin marketplace the SDK was designed for. The roadmap page tracks all of it.
Star the repository, try a recipe, and open an issue if anything breaks; every subsystem has a doctor command, and now it has a public issue tracker too.