Decide where the model runs

Self-host / deployment path

Install OpenMake with an explicit model boundary

One command installs and starts everything; the rest of this page is what that command did and how to change it. The first decision is not a setting — it is who operates the model.

Decide where the model runs

Either path installs the same OpenMake, but a hosted demo leaves operation to someone else, while self-hosting means you operate the application, the model endpoint, and the deployment boundary.

  • A hosted endpoint is quick to verify and spares you the GPU, but the provider sees the requests you send
  • A self-hosted endpoint means running vLLM and LiteLLM yourself, and holding the network, the credentials, and the model list
NextWhat the machine needs

What the machine needs

Node 24 and Docker. PostgreSQL and Redis run as containers from infra/docker-compose.yml — Homebrew-managed Postgres is no longer supported — and the installer brings up both. The API listens on 52416 and the web app on 3000.

On macOS, Docker Desktop, OrbStack, and Colima all work. On Windows, run everything inside WSL2: the installer detects a native Windows shell and prints the WSL2 setup steps instead of proceeding.

NextInstall with one command

Install with one command

No clone needed. Run outside a repository and the installer fetches the source into ~/openmake_llm and re-enters itself there. Piped through bash it still prompts you over /dev/tty; with no terminal, as in CI, prompts are auto-approved.

It asks one question — which OpenAI-compatible LLM endpoint to use — and finishes by printing your web URL and the generated administrator password. Re-running it is safe: it repairs in place rather than overwriting.

  • Checks the toolchain and installs what is missing — Node, Docker, PM2 — without sudo where it can
  • Generates .env with fresh random secrets, so JWT_SECRET, API_KEY_PEPPER, and TOKEN_ENCRYPTION_KEY are never copied from an example
  • Starts PostgreSQL and Redis, applies every migration, builds both apps, launches them under PM2, and waits for /health
  • --skip-docker when you run Postgres and Redis yourself; --postgres-port and --redis-port move the containers off 5432 and 6379 instead of fighting for them
shell
curl -fsSL https://raw.githubusercontent.com/openmake/openmake_llm/main/install.sh | bash

# non-interactive, endpoint supplied up front
curl -fsSL https://raw.githubusercontent.com/openmake/openmake_llm/main/install.sh | bash -s -- --yes \
  --llm-base-url https://openrouter.ai/api/v1 --llm-api-key sk-or-... --llm-model qwen/qwen3-235b-a22b
NextCheck the gateway settings

Check the gateway settings

The installer writes these for you; this is what to read back and adjust. Environment variable names, model IDs, and commands are literal values, not translated text.

Treat .env.example as the reference for everything else. If you fill .env by hand, generate the secrets rather than copying the sample values.

shell
LLM_BASE_URL=http://localhost:4000
LLM_DEFAULT_MODEL=qwen3.8-27b
LLM_POOL_DEFAULT_CTX=262144
DATABASE_URL=postgresql://openmake:your_password@localhost:5432/openmake_llm
JWT_SECRET=$(openssl rand -hex 32)
API_KEY_PEPPER=$(openssl rand -hex 32)
ADMIN_PASSWORD=replace_with_a_strong_password
TOKEN_ENCRYPTION_KEY=$(openssl rand -hex 32)
NextStart it and check it

Start it and check it

The installer leaves the service running, so these are the commands you need afterwards. openmake_llm.sh brings the three layers up in order — PostgreSQL, Redis, then the app under PM2 — and back down in reverse.

The server applies pending migrations as it boots, which makes a first start slower. Verification is worth more when it follows the path a real user takes rather than checking that a process exists.

  • Check that both the API and web processes are alive
  • Sign in and confirm the model you configured appears in the composer
  • Send one message and confirm the answer comes back from the model you intended
  • Confirm that request shows up on the usage screen
shell
./openmake_llm.sh status     # every layer at once
./openmake_llm.sh health     # /health response
./openmake_llm.sh logs       # live logs
./openmake_llm.sh start      # after a reboot
./openmake_llm.sh deploy     # build + migrate + restart, after a code change
The real proof of an install is the first message coming back. The composer names the model, and the answer returns along that same route.
NextIf you would rather do it step by step

If you would rather do it step by step

The manual path still works and is worth knowing when you are adapting the deployment. It is the same sequence the installer automates, minus the toolchain checks and the generated secrets.

shell
git clone https://github.com/openmake/openmake_llm.git
cd openmake_llm
node --version              # 24.x required
npm install
cp .env.example .env        # then fill in the values above
docker compose -f infra/docker-compose.yml up -d
./openmake_llm.sh build
./openmake_llm.sh migrate
./openmake_llm.sh start
NextDecide these before you invite anyone

Decide these before you invite anyone

A few switches change how the deployment operates rather than how it looks. Settle them before users arrive.

Automatic skill selection ships off. Set SKILL_AUTO_SELECT_ENABLED=true for chat and agent tasks to pick skills on their own. Keep external provider keys optional and separate from the local default route.

  • DB_AUTO_MIGRATE=false — turns off automatic migration on boot when you would rather run them by hand
  • SKILL_AUTO_SELECT_ENABLED=true — enables automatic skill selection in chat and agent tasks
  • External provider keys are registered per user, or a team shares an operator key under a daily token limit
  • ./openmake_llm.sh update — git pull, build, migrate, restart; it refuses to touch a tree with uncommitted or diverged commits
  • ./uninstall.sh — removes what the installer created, in reverse; --keep-data preserves the database volumes
Splitting tokens by model shows at a glance whether traffic is staying local.