著者 Matt Connor
RakazoをVPSにセルフホストする方法
RakazoをVPSで動かす手順を解説します。Node 22、pnpm、Postgres、Graphile WorkerをDocker Composeで構成し、sandboxの選択、キー管理、必要なメモリ容量を確認できます。
Rakazo のセルフホストで実際に動かすもの
Rakazo のセルフホストでは、1 台の Linux サーバー上で 5 つの要素を動かします。PostgreSQL、Graphile Worker プロセス、API、Web アプリ、そして起動中の各 bot 用の sandbox コンテナです。Rakazo は Grok Bot に代わるオープンソースのソフトウェアで、Apache 2.0 ライセンスの下で elie222 が公開しています。各 bot には専用のスレッド、コンピューター、メモリ、履歴が割り当てられます。また、他の bot や短時間だけ動作する subagent を起動できます。
この最後の点が、デスクトップではなく VPS (virtual private server) で運用する理由です。メモリを保持し、スケジュールされた処理を実行する bot は、ユーザーが就寝中も到達可能でなければなりません。ノート PC がサスペンドすると、キューの処理が停止します。
Rakazo は 2026 年 8 月時点で early beta です。そのため、完成した appliance ではなく、動作する構成として扱ってください。スタック全体で TypeScript を使用しています。Web アプリには React 19 と Vite、API には Hono、データベースには Prisma と組み合わせた Postgres、アカウント管理には Better Auth、バックグラウンドジョブには Graphile Worker を使用します。Graphile Worker は Postgres 内にキューを保存するため、Redis や 2 つ目のデータストアを運用する必要はありません。.env.example が WAKEUP_DRIVER=graphile を設定するため、bot の起動は Postgres を基盤とするジョブです。Postgres を停止すると、スケジュールされた bot の処理もすべて停止します。既存の製品を運用するのではなく、部品から agent を組み立てたい場合は、コンポーネントから独自の agent を構築するという別の方法もあります。
1 GB プランでは足りない理由
プロセス数を数えてください。Postgres が 1 つです。API は Node プロセスです。worker が 2 つ目です。Web アプリが 3 つ目です。sandbox supervisor が 4 つ目です。さらに、実行中の bot ごとに、グラフィカルな Linux デスクトップとブラウザーを含むコンテナが 1 つ必要です。
プロジェクト自身のセルフホスト向けドキュメントには、信頼できる数値が 1 つ示されています。E2B が bot のデスクトップを管理する場合、API、worker、Postgres には 2 vCPU と 4 GB のマシンで十分です。これは制御プレーンだけの数値であり、負荷の大きい部分は別の場所でホストされます。SANDBOX_PROVIDER=docker を設定すると、それらのデスクトップが VPS 上で動作するため、4 GB は目標値ではなく最低ラインになります。複数の bot を起動したままにする予定なら、8 GB から始めてください。bot の動作中に docker stats で実際の使用量を測定します。メモリ使用量を大きく左右するのは sandbox 内のブラウザーなので、スペック表だけでは判断できません。agent 用のマシンのサイズを決める一般的な方法については、agent VPS に実際に必要な RAM と CPUで測定方法を詳しく説明しています。
この問題の悪化を防ぐ設定が 1 つあります。.env.example は、アイドル状態がそのミリ秒数に達した後、E2B のコンピューターを一時停止し、Docker のコンピューターを停止するというコメント付きで SANDBOX_IDLE_MS=600000 を提供します。10 分間アイドル状態が続くと、コンピューターは削除されます。指定できる最小値は 30000 です。これを設定しないと、これまでに起動したすべての bot がメモリを永久に占有します。
ディスク容量も考慮が必要です。sandbox イメージ、Node モジュール、Postgres ボリュームが 1 台のディスクを共有するため、40 GB から始めるのが妥当です。
clone 前にバージョンを固定する
Rakazo は急速に更新されており、main はリリースではありません。2026 年 8 月 16 日時点で、リポジトリにあるタグは v0.1.0-beta の 1 つだけです。このタグは 2026 年 8 月 13 日に公開され、プレリリースとしてマークされています。
git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 53b119a68d9ef843d23aa3b7e3719b6be7b51fdb
git log -1 --format='%H %ci'このコミットは v0.1.0-beta が指しているものです。ブランチやタグではなく、コミットを固定してください。ブランチは次の git pull で変更される可能性があります。また、タグはメンテナーが付け替えられる可動ラベルです。そのため、どちらも再び取得できるツリーを一意に識別できません。コミット識別子は変更されません。使用したコミットを、他のサーバー情報とともに記録してください。アップグレードで問題が発生した場合、手軽な対処は git checkout <old commit> と再ビルドです。ただし、正常に動作していたコミットが分かっている必要があります。
要件: Node 22、pnpm 9、Docker
node -v
pnpm -v
docker --versionpackage.json は "engines": { "node": ">=22" } と "packageManager": "pnpm@9.15.0" を宣言するため、node -v は v22 以上を出力する必要があります。Ubuntu アーカイブの Node パッケージは通常これより古いため、NodeSource または nvm からインストールしてください。pnpm は corepack を通じて Node に付属します。
corepack enable
corepack prepare pnpm@9.15.0 --activate残りは Docker Engine と compose plugin で対応できます。ユーザーが daemon にアクセスできることも必要です。docker ps の結果が permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock になる場合は、ユーザーを docker group に追加して、新しい login shell を開いてください。追加する前に、その権限が与える範囲を理解してください。docker のメンバーシップはマシン上の root と同等です。この group に属するユーザーは、ホストのファイルシステムをマウントする container を起動できるためです。
.env を設定してから Postgres を起動する
cp .env.example .env
chmod 600 .envネットワークに接続する前に、2 つの値を変更する必要があります。.env.example には BETTER_AUTH_SECRET=replace-with-32-plus-character-secret と ENCRYPTION_KEY=replace-with-64-char-hex-or-passphrase が含まれています。Rakazo は開発環境以外でこれらのプレースホルダー値を拒否するため、設定が不完全なデプロイは、リポジトリで公開されている Secret を使って動作し続けず、明確なエラーで失敗します。
openssl rand -base64 48
openssl rand -hex 32次に、データベースだけを起動して、マイグレーションを実行します。
docker compose --env-file .env -f infra/compose/docker-compose.yml up postgres -d
pnpm install
pnpm db:generate
pnpm db:migrate
pnpm sandbox:buildpnpm sandbox:build は、package.json で docker build -t rakazo/computer:local infra/sandboxes/computer として定義された bot computer イメージをビルドします。これは graphical image であるため、初回のビルドでは大量のデータを取得し、時間がかかります。docker image ls rakazo/computer で作成されたことを確認します。1 行が出力されるはずです。
compose ファイルは Postgres を 127.0.0.1:5433:5432 として公開します。これは loopback 専用です。そのままにしてください。開発用の認証情報は rakazo:rakazo で、リポジトリに含まれています。パスワードが公開された状態でインターネットから到達可能な Postgres ポートを公開すると、数時間以内にスキャナーに発見されます。本番用の compose ファイルは代わりに POSTGRES_PASSWORD を読み込むため、その段階になったらランダムな文字列を設定してください。
最初の起動
pnpm devこれにより、4 つのコンポーネントが起動します。3100 番ポートの API、Graphile Worker、5173 番ポートの Vite Web アプリ、7091 番ポートのサンドボックススーパーバイザーです。アプリには http://127.0.0.1:5173 でアクセスでき、サインインページが表示されます。
VPS では、そのマシンの前に座って操作するわけではありません。また、アクセスするために 5173 番ポートを公開すべきでもありません。代わりに、自分のマシンから SSH（secure shell）でポート転送します。
ssh -L 5173:127.0.0.1:5173 -L 3100:127.0.0.1:3100 you@your-serverこの 2 つの実行方法の違いに注意してください。pnpm dev はホスト上で Vite をローカルにバインドして起動します。compose ファイルの web サービスは、すべてのインターフェースで 5173:5173 を公開します。公開 VPS で開発用 compose スタック全体を起動すると、アプリが外部に公開されます。そのため、起動したままにするものには本番用ファイルとそのリバースプロキシを使用してください。
サーバー上で安全に使用できるサンドボックスプロバイダーはどれですか？
ここでの設定を正しく行うことが重要です。SANDBOX_PROVIDER の .env には、4 つの値を指定できます。
dockerがデフォルトです。各ボットに、マシン上で専用のコンテナを割り当てます。このコンテナは、生成されたpnpm sandbox:buildから構築されます。セルフホスト構成では最も高速です。e2bは E2B 上でボットのコンピューターを実行するため、E2B_API_KEYが必要です。API とデータベースを実行するホストからボットのコンピューターを分離できるため、公開環境やマルチユーザー環境に推奨されています。desktopは、API と worker のホスト上でボットのコマンドを直接実行します。リポジトリの指示は明確で、公開サーバーや共有サーバーでは使用しないでください。fakeはテスト用のプロセス内エミュレーターです。実行環境ではありません。
デスクトップモードに関する警告は、文字どおり受け止めてください。デスクトップモードには分離境界がまったくありません。そのため、ボットは API プロセスを実行しているユーザーとして shell コマンドを実行し、そのユーザーのホームディレクトリ、SSH キー、クラウド認証情報、.env を使用できます。ボットが読み取った Web ページ内のテキストが、サーバー上のコマンドになります。サーバーでデスクトップモードを使用すると、ボットが認証情報を保持する状態につながります。使用する場合は、常に操作しているマシンでのみ使用してください。それ以外では使用しないでください。
docker は実際の境界ですが、完全ではありません。各ボットには専用のコンテナがあるため、あるボットが別のボットのファイルを読み取ることはできません。ただし、それらのコンテナを作成する supervisor は /var/run/docker.sock をマウントします。ホストの Docker socket を制御できる場合、ホストも制御できます。そのため、supervisor は非公開にしてください。.env.example では、SANDBOX_SUPERVISOR_TOKEN をオプションの個別サービス認証情報として説明しています。この値は空の場合に BETTER_AUTH_SECRET がデフォルトになります。つまり、その Secret をプレースホルダーのままにすると、GitHub で誰でも読める文字列によってコンテナ作成サービスを保護することになります。両方の値を設定してください。ここで利用できる分離を最大限にするには、e2b を使用するか、他のデータを保持していないマシンを Rakazo 用に用意してください。これは 使い捨て VM でコーディングエージェントを実行する場合と同じ考え方です。エージェントが誤った操作をしても影響を抑える最も安価な方法は、そのマシンに価値のあるものを置かないことです。
モデル API キーはどこに設定しますか？
Rakazo には、モデルの料金を管理する機能がありません。キーは利用者自身で用意します。.env.example が PI_DEFAULT_PROVIDER=openrouter を設定するため、通常は OPENROUTER_API_KEY に記述します。各プロバイダーのキーも同じ設定を通じて利用できます。
キーは .env に保持し、コミットするファイルには記述しないでください。リポジトリ内の両方の compose コマンドが --env-file .env を渡すため、値は git が追跡する YAML に書き込まれることなくコンテナへ渡されます。OPENROUTER_API_KEY を空のままにして、オンボーディング中にアプリへキーを貼り付けることもできます。これは、ENCRYPTION_KEY に提供時のプレースホルダーではなく、実際のランダムな値が必要な理由の1つです。
ボットがキーを使う前に、プロバイダー側でそのキーの利用上限を設定してください。ループするボットは料金を発生させ続けます。キー単位の上限は、監視に依存せずに停止できる唯一の方法です。このキーには専用の名前を付け、単独で無効化できるようにしてください。
開発モードから常時稼働できる構成へ
リポジトリには、本番用の compose ファイルが含まれています。このファイルは、Postgres、API、worker、Web アプリケーション、そして自動取得した TLS（トランスポート層セキュリティ）証明書を使用する Caddy を起動します。Bot 用コンピューターには E2B が必要です。
sudo DEPLOY_USER=deploy bash infra/compose/harden-host.sh
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --buildharden-host.shは SSH パスワードログインを無効にし、SSH、HTTP、HTTPS 用の UFW（uncomplicated firewall）ルールを設定し、fail2ban を有効にして AppArmor プロファイルを適用します。ログイン方法が変わるため、実行前に内容を確認してください。実行中は、2 つ目の SSH セッションを開いたままにしてください。
本番用の .env には、開発用のものより多くの設定が必要です。セルフホストのドキュメントには、次の最小構成が記載されています。
NODE_ENV=production
RAKAZO_HOST=app.example.com
BETTER_AUTH_URL=https://app.example.com
WEB_ORIGIN=https://app.example.com
API_URL=https://app.example.com
POSTGRES_PASSWORD=<random>
BETTER_AUTH_SECRET=<random>
ENCRYPTION_KEY=<random>
E2B_API_KEY=<your key>
OPENROUTER_API_KEY=<your key>
SANDBOX_PROVIDER=e2b
AGENT_RUNTIME=pi
DATA_DIR=/data最初の up の前に、サーバーを指す A レコードを設定してください。Caddy は RAKAZO_HOST に指定された名前の証明書を要求します。その名前がこのサーバーに解決されない場合、または外部から port 80 に接続できない場合、要求は失敗します。
SIGNUP_ALLOWLIST=you@example.com も設定してください。SIGNUPS_ENABLED=true はデフォルトで有効です。そのため、公開名で運用するインスタンスは、見つけた人なら誰でも登録でき、新しいアカウントごとにコンピューターが割り当てられます。まず許可リストを設定してください。必要に応じて、後から制限を緩和できます。
本番設定の基準として、リポジトリ内の docs/self-host.md を使用してください。コードの変更に伴ってこのファイルも変わるため、このガイドとは異なる場合があります。Compose が処理を担うため、通常のルールが適用されます。また、VPS 向け Docker Compose の基本では、スタックを数か月放置して稼働させる場合に --env-file と名前付きボリュームが重要になる理由を説明しています。
バックアップ
Postgres と data/ ディレクトリが、インスタンス全体です。
./scripts/backup.sh
./scripts/restore.sh backups/BACKUP_TIMESTAMPbackup.sh は Postgres をダンプし、data/ をアーカイブします。依存しているマシンでは、リポジトリが提供するタイマーを使用して、infra/compose/backup-prod.sh を /usr/local/sbin/rakazo-backup としてインストールしてください。これにより、ローテーションが自動的に行われます。データベースと同じディスク上にあるバックアップは、バックアップとはいえません。そのため、サーバー外へコピーしてください。次に、必要になる前に、予備サーバーで一度復元してください。
失敗する理由と確認できる内容
pnpm db:migrate からデータベースに接続できません。 マイグレーションは、127.0.0.1:5433 のデータベースサーバーに接続できないと報告します。Postgres コンテナが起動していないか、起動していてもまだ準備が完了していません。docker compose --env-file .env -f infra/compose/docker-compose.yml ps を実行し、postgres サービスの状態が healthy になることを確認してください。compose ファイルでは、3 秒ごとにヘルスチェックを実行する設定になっています。コンテナが再起動を繰り返す場合は、pgdata ボリュームが異なる認証情報で作成されていることが多いです。docker compose ... down -v でボリュームを削除できますが、保存されているデータも削除されます。
ポートがすでに使用されています。 5433 を別のプロセスが使用していると、Postgres の起動時に bind: address already in use で失敗します。停止し忘れた古い Rakazo スタックが原因であることが最も多いです。sudo ss -lntp | grep 5433 でプロセスを特定できます。
ボットにコンピューターが割り当てられません。 SANDBOX_PROVIDER=docker を指定していても rakazo/computer:local イメージがなければ、起動するものがありません。docker image ls rakazo/computer でその状態を 1 行で確認でき、pnpm sandbox:build で修正できます。スーパーバイザーが Docker socket に接続できない場合も、コンテナを作成できません。メッセージにはパス permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock が示されます。
長いコマンドが途中で終了します。 .env.example により SANDBOX_COMMAND_TIMEOUT_MS=300000 が設定されているため、ボットのコンピューター内で実行した 1 つのコマンドは 5 分後に強制終了します。サンドボックスのクラッシュを疑う前に、ビルドに時間がかかる場合はこの値を大きくしてください。
pnpm install が分かりにくい形で失敗します。 まず node -v を確認してください。ワークスペースでは >=22 を宣言しています。Node が古い場合、バージョンに関するメッセージではなく、依存関係のコード内で失敗します。
ローカルではサインインできますが、ドメイン経由ではできません。 BETTER_AUTH_URL、WEB_ORIGIN、API_URL はすべて、アドレスバーに表示されるアドレスと同じ公開オリジンを、スキームも含めて保持する必要があります。いずれかに古い http://127.0.0.1:5173 が残っていると、セッションが維持されないことが一般的です。
固定したチェックアウトの更新
self-host ガイドに記載されたアップグレード手順は短く、更新済みのソースを取得し、データベースのマイグレーションを実行して、API と worker を再起動します。
./scripts/backup.sh
git fetch --all
git checkout NEW_COMMIT_SHA
pnpm install
pnpm --filter @rakazo/db migrate
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml up -d --build最初にバックアップを作成します。マイグレーションは先に進むだけであり、beta 版では確実に戻せる手順を期待できません。固定した SHA から新しい SHA までのコミットを適用する前に確認してください。この段階のプロジェクトでは、告知なしに環境変数の名前が変更されることがあり、変数がないとサービスが起動した直後に終了する状態になります。Rakazo を実行する価値があるかまだ判断中であれば、self-host 型 AI エージェントの比較記事で、このカテゴリに属するほかの選択肢と、それぞれを稼働させ続けるためのコストを確認できます。
FAQ
1 GB VPS で Rakazo を実行できますか？
いいえ。Postgres、API、worker、sandbox supervisor、Web アプリが同時に動作します。さらに SANDBOX_PROVIDER=docker では、起動中の bot ごとに、グラフィカルデスクトップとブラウザーを保持するコンテナが追加されます。プロジェクトのドキュメントでは、bot のデスクトップを E2B がホストする場合に限り、API、worker、Postgres に 2 vCPU と 4 GB が必要十分とされています。control plane だけでも 4 GB を最低ラインとし、デスクトップを自分のマシンで実行する場合はさらに増やしてください。
サーバー上でデスクトップ sandbox provider を使用しても安全ですか？
いいえ。desktop は bot のコマンドを API と worker のホスト上で、プロセスを実行しているユーザーとして直接実行します。そのユーザーのファイルと認証情報にもアクセスできます。リポジトリでは、public server または shared server で使用しないよう記載されています。bot ごとにコンテナを用意する場合は docker を使用してください。複数のユーザーがサインインする場合は e2b を使用してください。
どのバージョンの Rakazo をインストールすべきですか？
2026 年 8 月 16 日現在、tag は 1 つだけです。v0.1.0-beta で、2026 年 8 月 13 日に公開された prerelease です。main を追跡するのではなく、その tag が指す commit（53b119a68d9ef843d23aa3b7e3719b6be7b51fdb）を checkout してください。branch は後から更新され、tag は付け替えられる可能性があるため、どちらも戻る先となる tree を確実には識別できません。どの commit が動作したかを記録してください。既知の commit がなければ rollback できないためです。
OpenRouter API key はどこに設定しますか？
.env に OPENROUTER_API_KEY として設定し、commit する compose file には決して記載しないでください。リポジトリ内の 2 つの compose コマンドはいずれも --env-file .env を渡すため、値は追跡対象の YAML に書き込まれずにコンテナへ渡されます。空のままにして、onboarding 中にアプリへ key を貼り付けることもできます。provider 側で key の支出上限を設定してください。bot がループすると、停止するまで model の呼び出しを続けるためです。
ドメイン名と TLS は必要ですか？
最初のテストを超えて使用する場合は、必要です。production compose file は Caddy を実行し、証明書を自動的に取得します。また、RAKAZO_HOST、BETTER_AUTH_URL、WEB_ORIGIN、API_URL はすべて同じ public HTTPS origin を設定する必要があります。最初に動作を確認するだけであれば、ドメインを省略できます。pnpm dev を実行し、公開せずに SSH 経由で port 5173 を forward してください。