FireForm CLI for one-command install and setup

[chetanr25]

Proposal: FireForm CLI for one-command install and setup

Right now the only way to run FireForm is to clone both repos, set up Docker, and go through the Makefile. That works for contributors, but a third party who just wants to use FireForm should not have to do any of that. This proposal is about shipping FireForm through a small CLI tool that a user installs with a single copy-paste command from our docs.

A CLI is the right shape for this because it stays on the user's machine and grows with us. When we ship a new version, the user runs one update command and gets it. It also gives users real control, since we can add commands over time for configuring the backend, switching models, checking logs, or anything else, instead of asking them to edit files by hand. This is the same install experience people already know from Ollama and Homebrew, so it will feel familiar from the first command.

---

1. Publish the backend image from CI/CD

The backend already runs fully in Docker. We add a step to our CI/CD pipeline that builds the backend image on every release and pushes it to a public registry, tagged with the release version plus a latest tag. From then on, every release automatically has a ready-to-pull image and we never build anything on the user's machine. GitHub has official docs for publishing Docker images from Actions.

2. How the CLI pulls and runs the backend

The CLI pulls the published image from the registry and starts it. For the registry, the two obvious options are Docker Hub and the GitHub Container Registry (GHCR).

One thing the install script and the CLI must both handle: the image can only run if the user has a working Docker engine. So before doing anything, we check that Docker is installed and that the daemon is actually running (a simple docker info call answers both). If it is missing, we print a short message pointing the user to Docker Desktop. A clear message here matters a lot, because "docker daemon not running" is the first wall most users will hit.

3. Shipping the frontend

The frontend is an Electron desktop app, so it cannot come from a Docker image. Instead we use CI/CD in the frontend repo: when we push a version tag, the pipeline builds the app and attaches the binaries to a GitHub release. electron-builder is the standard tool here. It builds all the formats we need and can publish straight to GitHub Releases from CI.

Each platform needs its own format:

Platform	Format	Notes
Windows	.exe (NSIS installer)	electron-builder generates the installer for us
macOS	.dmg	needs signing and notarization eventually
Linux	AppImage or .deb	AppImage runs anywhere without install

We should decide early which platforms we support first, since every extra target adds build and testing work. The install script has to deal with this too: it detects the user's OS and architecture and downloads the matching binary from the release, so the user never has to think about which file is theirs.

4. How the whole flow runs

The user copies one command from our docs and runs it in their terminal. The script it fetches does a few small things:

1. Detect the OS and architecture.
2. Download the matching fireform CLI binary from the fireform-cli releases.
3. Place it in a standard location and add it to the PATH.

From that point the script is done and everything else goes through the CLI. On first run, the CLI does the actual setup: it checks Docker as described above, pulls the latest backend image from the registry, downloads the frontend app for the user's platform, and starts everything end to end. After that the user has simple commands like:

fireform start
fireform stop
fireform update
fireform logs

and we can keep adding more as the project grows. This split matters: the script stays tiny and almost never changes, while all the real logic lives in the CLI where we can version and update it properly.

5. Tech stack for the CLI: Go and Cobra

For the CLI itself I propose Go with the Cobra library, maintained in a new fireform-cli repo with its own releases. The case for it:

• Go compiles to a single static binary per platform with no runtime needed on the user's machine. That is exactly what our install script wants to download.
• Cobra gives us subcommands, flags, help text, and even shell autocompletion with very little code.
• It is the most proven choice in this space. kubectl, the Docker CLI, the GitHub CLI, and Hugo are all built on Cobra, and our CLI does the same kind of work they do (talking to Docker, downloading releases, managing a local service).
• Releasing is a solved problem: GoReleaser cross-compiles for every OS and architecture and attaches the binaries to a GitHub release in one CI step. Later it can also publish to Homebrew, Scoop, and winget for us if we want nicer install channels.

---

Would like to hear what everyone thinks, especially on the platform list for the frontend binaries and the registry choice.

This is completely new idea and I think this is of less priority as of now, but we definitely need this at some point of time. The goal is to run FireForm in organisations or personal system without cloning our source code and setting it up from scratch.

[chetanr25]

Would love to hear your thoughts on it. @marcvergees @vharkins1

[marcvergees]

Green light.✅