Self-Host

Deploy the runtime tooling and the professional site separately.

LLMFit is easiest to operate when you treat it as two artifacts: the runtime tooling (`llmfit`, `llmfit serve`) and the static product/docs site. They can live together, but they do not have to.

Binary install

The fastest path for individual users or operators testing on one machine.

curl -fsSL https://raw.githubusercontent.com/miounet11/llmfit/main/install.sh | sh

Source build

Best when you want full control, local modification, or integration into a Rust-oriented workflow.

git clone https://github.com/miounet11/llmfit.git
cd llmfit
cargo build --release

Node-local API service

Run `llmfit serve` on a host and let upstream systems poll it rather than embedding the fit logic elsewhere.

llmfit serve --host 0.0.0.0 --port 8787

Full local stack

Use the shipped Compose file when you want the API and the static site available together during development.

docker compose up --build

Production pattern

Use an isolated site deployment path.

The safest rollout pattern is to keep the site isolated from existing application services until you have verified the new domain mapping, certificate coverage, and health checks.

Static root pattern

Place the `site/` output in a dedicated Nginx or Caddy document root and let your reverse proxy serve it directly.

Container pattern

Run a separate static container on an unused internal port, then reverse proxy only after validating the site in isolation.

Certificate pattern

Issue TLS certificates for every host you plan to expose, including both apex and `www` variants when applicable.

Repo-managed remote rollout

scripts/deploy-site.sh user@host /opt/llmfit

This helper clones or updates the repository on the target host and starts the shipped site deployment definition.

Containerized site rollout

docker compose -f deploy/site.compose.yml up -d

The shipped site compose file uses an isolated port so you can test before updating the live reverse proxy.

Production checklist

Minimal discipline before a domain cutover.

Back up the previous site

Preserve the current docroot
Back up the active virtual host config
Record certificate paths and current server names

Validate the proxy stack

Run `nginx -t` before reloading
Confirm the active nginx binary and config path
Check for duplicate site definitions

Verify direct host routing

Use `curl --resolve` before DNS flips
Check `robots.txt` and sitemap availability
Confirm redirects for both apex and `www` hosts

Watch post-cutover logs

Tail access and error logs immediately after DNS changes
Check TLS coverage for every public hostname
Keep rollback artifacts available

Operational next step

Pair deployment guidance with API integration.

API integration Read the FAQ