MINARAデプロイ
ローカル、Docker Compose、または Agent 専用サービスで Minara を動かす
ほとんどの利用者はデスクトップアプリまたはローカル実行で十分です。永続ボリュームを備えた再現可能なサーバー構成が必要な場合は Docker を使います。
デプロイ形態を選ぶ
| 必要なこと | 推奨形態 |
|---|---|
| 個人の PC、ターミナル不要 | デスクトップアプリ |
| ローカルのブラウザとターミナル | インストーラーと minara serve --ui |
| 再現可能なセルフホスト構成 | Docker Compose |
| Web UI を使わない API またはメッセージングサービス | Agent 専用コンテナ |
Docker Compose スタック
ソース checkout のルートから実行します。
pnpm docker初回は .env.example を .env へコピーして終了します。LLM provider の認証情報と MINARA_API_KEY を少なくとも入力してから再実行してください。次が起動します。
- Web UI：
http://localhost:5173 - Gateway：
http://localhost:8080
よく使う操作：
pnpm docker:up
pnpm docker:down
pnpm docker:logs
pnpm docker:rebuild稼働中の Agent に対してターミナルセッションが必要な場合は、docker exec -it minara-agent node dist/gateway/cli.js を使います。
永続データとアップグレード
Docker スタックは Minara の状態を名前付きボリュームに保存します。SQLite データ、監査記録、ワークスペースファイル、認証プロファイル、ログが含まれます。コンテナを作り直してもこのボリュームを保持してください。
大きなアップグレード前には、データボリュームをバックアップするか SQLite データベースをエクスポートします。その後、同じボリュームを接続したままコンテナを再ビルドまたは置き換えます。DB マイグレーションは Agent 起動時に実行されます。
SQLite は 1 つのアクティブな書き込み元向けです。1 つのボリュームは状態を所有する 1 つの Agent が使います。レプリカを追加する場合、書き込みはその所有者に送ってください。複数の独立した書き込み元で同じ DB をマウントしてはいけません。
ネットワークとシークレット
理由がない限り gateway は localhost に留めてください。リモート gateway は金融・アカウント操作に到達できるため、GATEWAY_AUTH_TOKEN を設定し、TLS を終端するリバースプロキシを前に置きます。
認証情報をイメージに入れないでください。ローカル Docker Compose では .env、ホスト環境ではシークレットストアまたは実行時の環境変数を使います。シークレットを commit したり、イメージに焼き込んだりしないでください。
gateway はコンテナの基本的なヘルスチェックとして GET /healthz を提供します。より広いローカル設定確認には minara doctor を実行します。
Agent 専用コンテナ
Web UI が不要な場合は Agent イメージを直接ビルドして実行できます。
pnpm docker:build
pnpm docker:runこの方法は 8080 番ポートで gateway を公開し、minara-data ボリュームをマウントします。認証情報はホスト環境またはデプロイ基盤から渡し、コマンド履歴には残さないでください。
本番前の確認
- 再起動後もデータボリュームが残ることを確認する。
- アカウントに合う日次と取引ごとの上限を設定する。
minara doctorと gateway のヘルスチェックを確認する。- 公開前にリバースプロキシと認証経路を試す。
- 自動化はペーパーまたは小額から始め、監査記録を確認する。