モデルの境界を明確にしてOpenMakeをインストールする

どちらでも同じOpenMakeが立ち上がりますが、ホスト型デモは運用を任せ、セルフホストではアプリケーション・モデルエンドポイント・配置境界を自分で運用します。

• ホスト型エンドポイント — すぐ確認でき、GPUの世話も不要ですが、送ったリクエストはモデル提供者から見えます
• セルフホストのエンドポイント — vLLMとLiteLLMを自分で動かす代わりに、ネットワークも資格情報もモデル一覧もすべて自分の手に残ります

Node 24とDockerです。PostgreSQLとRedisはinfra/docker-compose.ymlのコンテナとして動きます。Homebrewで動かすPostgresはもうサポートされず、インストーラーが両方とも自動で起動します。APIは52416番、Webは3000番ポートを使います。

macOSではDocker Desktop・OrbStack・Colimaのいずれでも動きます。Windowsではすべてを WSL2 の中で行ってください。ネイティブのWindowsシェルを検出すると、インストーラーは処理を進める代わりにWSL2の準備手順を表示します。

クローンは不要です。リポジトリの外で実行すると、スクリプトがソースを ~/openmake_llm へ取得し、その中で自分自身を再実行します。bashへパイプしても /dev/tty で質問し、CIのように端末がなければ自動承認します。

尋ねられるのは1つだけ、どのOpenAI互換LLMエンドポイントを使うかです。完了時にWebのURLと生成された管理者パスワードを表示します。再実行しても安全で、上書きではなく足りない部分だけを修復します。

• ツールチェーンを点検し、足りないものを導入します — Node、Docker、PM2。可能な場所ではsudoなしで行います
• 秘密値を新たに生成して.envを作ります。JWT_SECRET・API_KEY_PEPPER・TOKEN_ENCRYPTION_KEYを例からコピーすることがありません
• PostgreSQLとRedisを起動し、マイグレーションをすべて適用し、両アプリをビルドしてPM2で起動し、/healthを待ちます
• --skip-dockerはPostgresとRedisを自分で運用する場合に使います。--postgres-portと--redis-portは5432・6379を奪い合う代わりにコンテナを別ポートへ移します

curl -fsSL https://raw.githubusercontent.com/openmake/openmake_llm/main/install.sh | bash

# 非対話 — エンドポイントを先に渡す場合
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

以下の値はインストーラーが書いてくれます。ここに挙げたのは、後から読み返して調整する場所です。環境変数名・モデルID・コマンドは翻訳対象ではなく、そのまま使う値です。

残りは.env.exampleを基準にしてください。.envを手で埋める場合は、例の秘密値を写さず新しく生成してください。

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=強い管理者パスワードに置き換える
TOKEN_ENCRYPTION_KEY=$(openssl rand -hex 32)

インストールが終わった時点でサービスはすでに動いています。その後に必要なコマンドが以下です。openmake_llm.shが3つの層を順に起動し — PostgreSQL、Redis、そしてPM2上のアプリ — 停止は逆順で行います。

サーバーは起動時に未適用のマイグレーションを先に適用するため、初回は少し時間がかかります。確認はプロセスの生死ではなく、実際の利用者がたどる経路をそのまま歩く方が確かです。

• APIとWebのプロセスが両方生きているか確認する
• ログインして、設定したモデルが入力欄に表示されるか確認する
• メッセージを1つ送り、意図したモデルから応答が返るか確認する
• 使用量画面にそのリクエストが記録されたか確認する

./openmake_llm.sh status     # すべての層の状態を一度に
./openmake_llm.sh health     # /health の応答確認
./openmake_llm.sh logs       # リアルタイムログ
./openmake_llm.sh start      # 再起動後
./openmake_llm.sh deploy     # コード変更後 — build + migrate + restart

閉じる

手動の経路も引き続き使えます。配置を自社向けに調整するつもりなら知っておく価値があります。インストーラーが自動化しているのと同じ順序で、ツールチェーン点検と秘密値の生成だけが省かれます。

git clone https://github.com/openmake/openmake_llm.git
cd openmake_llm
node --version              # 24.x が必要
npm install
cp .env.example .env        # 上の値を埋める
docker compose -f infra/docker-compose.yml up -d
./openmake_llm.sh build
./openmake_llm.sh migrate
./openmake_llm.sh start

画面ではなく運用のあり方そのものを変えるスイッチがいくつかあります。利用者を招く前に決めておくのが得策です。

スキルの自動選択は既定でオフです。SKILL_AUTO_SELECT_ENABLED=trueにして初めて、チャットとAgent Taskがスキルを自分で選びます。外部プロバイダーのキーは任意のままにし、ローカル既定の経路と混ぜないでください。

• DB_AUTO_MIGRATE=false — 手動でマイグレーションを回したいとき、起動時の自動適用を止めます
• SKILL_AUTO_SELECT_ENABLED=true — チャットとAgent Taskのスキル自動選択を有効にします
• 外部プロバイダーのキーはユーザーごとに登録するか、1日のトークン上限を付けた運用者キーをチームで共有します
• ./openmake_llm.sh update — git pull、ビルド、マイグレーション、再起動。未コミットの変更や分岐したコミットがあれば手を触れずに止まります
• ./uninstall.sh — インストーラーが作ったものを逆順で削除します。--keep-dataはデータベースのボリュームを残します

閉じる