Drobek

drobek

オープンソースのバイブコーディング向けホスティングサービスです。AI エージェントがウェブアプリを構築し、drobek がコンパイル、プレビュー、公開します。

Claude、Claude Code、Cursor、Codex をご利用ください。エージェントは MCP 経由で接続し、ワークスペースに直接アプリを書き込み、コンパイル結果のフィードバックとライブプレビューを受け取ります。公開するタイミングはご自身で決められます。プラットフォームモジュールがサインイン、データ、フォーム、メール、アップロード、外部 API、定期インポートを提供し、ダッシュボードからアプリ、ユーザー、シークレットを管理できます。Claude のアーティファクトとして作成したものも、エージェントがファイルをそのまま移行し、プレビューを表示します。

すでにエージェントをお使いの方向けの、Lovable、Bolt.new、v0 に代わるオープンソースでセルフホスト可能な選択肢です。drobek 自体にはチャット機能がなく、お使いのエージェントが構築を担当し、drobek がその成果物をコンパイル、バージョン管理、プレビュー、ホスティングします。

drobek.app を試す · セルフホスト · ギャラリー · ドキュメント

35秒でわかるプロキシモジュール：エージェントが外部 API を登録し、管理者が呼び出し可能なユーザーを承認します。ダッシュボードに入力したキーがアプリやエージェントに渡ることはありません。

MCP Registry 名：io.github.freema/drobek。ホスト型の Streamable HTTP エンドポイントは https://drobek.app/mcp で、OAuth 2.1 を使用します。

実行場所を選ぶ

	はじめ方
drobek.app	メンテナーがホストするインスタンスです。サインインしてエージェントを接続してください。
独自のサーバー	Postgres、Redis、Caddy とともに、同じ公開イメージを実行します。セルフホストのクイックスタートに従い、サーバーの /mcp エンドポイントにエージェントを接続してください。

コア部分は AGPL-3.0 です。ビルド、テスト、セルフホストに、drobek.app を運営するプライベートリポジトリへのアクセスは必要ありません。エージェントプラグインは MIT ライセンスで、どちらのインスタンスにも接続できます。

みんなが作ったものを見る

• Drobek Tycoon — 3つのレベルがある、プレイ可能なホスティング会社シミュレーターです。
• Pokédex — drobek のプロキシモジュールを通じて PokéAPI を検索し、ステータスを確認できます。ライブリクエストログも表示されます。
• Pixel Wall — 認証、データなどのプラットフォームモジュールを活用した、共有型の 64 × 40 キャンバスです。
• Pixel Crumbs — ブラウザーで使えるピクセルアート・アニメーションエディターです。
• Drobek Skok — リーダーボード付きのピクセルプラットフォーマーです。
• Pekárna Drobek — 小さなベーカリーのデモサイトです。

これらは drobek.app で公開されているアプリです。さらに多くの例はギャラリーをご覧ください。

最初のアプリを構築する

1. 上記のインスタンスを選び、エージェントを接続します。

2. 次のような小さなアプリを依頼します。

   Build a shift planner for our team on drobek.
   Let people sign in and see their own shifts.
   Give me a preview to try before publishing.
   

3. プレビューを開いて変更を依頼し、準備ができたら公開するようエージェントに依頼します。

アプリはブラウザーで実行されます。バックエンドにはインストール済みのプラットフォームモジュールを使用します。任意のアプリサーバーコードや、アプリごとの npm install は実行モデルの対象外です。独自のバックエンド統合を行う場合は、プラットフォームモジュールを作成してください。

一連の流れ

1. drobek をエージェントに接続します（OAuth を使用する MCP サーバーです。ブラウザーで承認します）。
2. アプリを依頼します。例：「倉庫向けのシフト計画アプリ」。エージェントは create_app を呼び出し、コンパイル可能なスターターとルールの説明を受け取ります。
3. write_files を呼び出します。drobek は esbuild を使ってファイルをプロセス内でコンパイルし、コンパイルエラーを同じ応答内で返します。エージェントはエラーを修正して、再度書き込みます。書き込みのたびに不変のバージョンが作成されます。
4. コンパイルに成功すると、アプリのプレビュー用ホスト https://<slug>--preview.<APPS_DOMAIN> ですぐに公開され、エージェントからリンクが渡されます。
5. 問題がなければ、エージェントが publish を呼び出し、バージョンが https://<slug>.<APPS_DOMAIN>（または独自のドメイン）で公開されます。以前のバージョンを公開すれば、ロールバックになります。

このように設計されている理由：

• サーバーはアプリコードを実行しません。 コンパイルして配信し、成果物はブラウザーでのみ実行されます。アプリごとのサンドボックスも、npm install も、エージェントのサーバーサイドコードもありません。
• シークレットがエージェントを経由することはありません。 アプリの所有者がダッシュボードでシークレットを設定し、モジュールがサーバーサイドで使用します。
• 各アプリは独自のオリジンを持ちます（<slug>.<APPS_DOMAIN>）。ダッシュボードとは分離されています。
• 1つのプロセス、1つのイメージ（ghcr.io/freema/drobek）＋Postgres＋Redis（TLS 用の Caddy）。一般的な小型サーバーで実行できます。

主な概念

エージェントプラグインとプラットフォームモジュールは、それぞれ異なる役割を担います。 プラグインは、drobek でアプリを構築する方法をエージェントに教えます。モジュールは drobek サーバーで実行され、アプリにバックエンド機能を追加します。プラグインをインストールしても、サーバーモジュールはインストールされません。リポジトリと互換性マップを参照してください。

• ワークスペース — ロール（workspace-admin / editor / viewer）を持つユーザー。

• アプリ — ワークスペースが所有する、グローバルに一意なスラッグ。ホストは次のとおりです。 <slug>.<APPS_DOMAIN>（公開済み）、<slug>--preview.<APPS_DOMAIN>（コンパイルに成功した最新バージョン）、<slug>--v<N>.<APPS_DOMAIN>（バージョン N を指定）、および検証済みのカスタムドメイン。

• バージョン — アプリのソースとコンパイル済み出力を保存した、番号付きの不変スナップショットです。公開時にはポインターが1つ移動します。

• プラットフォームモジュール — アプリが利用できる唯一のバックエンドです。アプリのホスト上の /__drobek/v1/<name> 配下のルート、ブラウザー SDK 内の drobek.<name>、エージェントが提案し、リスクがある場合は所有者が確認するアプリごとの設定、そしてエージェントが読むスキルを提供します。組み込みモジュール（modules/、DROBEK_MODULES で有効化）：

  • auth — アプリのユーザーはメールで送信されるコードを使ってサインインします（許可リスト、管理者、<LoginGate>、所有者が失効できるセッション）。
  • data — 操作ごとのルール（public / user / owner / admin）、JSON Schema、CSV を備えたレコードのコレクション。
  • forms — <Form> の送信内容を保存して所有者にメールで送信します。ボット対策も備えています。
  • email — アプリの所有者への通知（任意のアドレスには送信できません）。アプリごと、およびサーバー全体の送信上限があります。
  • files — バイト列から種類を判別する、エンドユーザーによるアップロード機能。アプリごとの容量上限があります。
  • proxy — SSRF 対策のもと、シークレットをサーバーサイドで注入して外部 API を呼び出します。

  運用者は公開された仕様に基づいて独自のモジュールを追加できます。npm create drobek-module@latest <name> を実行すると、npm パッケージ @freema/drobek-modules と @freema/drobek-sdk（npm エイリアス経由で @drobek/modules / @drobek/sdk としてインポート）を使ったモジュールのひな形が生成されます。 docs/MODULES.md → モジュールの作成。

セルフホストのクイックスタート

必要なもの：

• パブリック IPv4（および／または IPv6）を持つサーバー。linux/amd64（v1 には ARM イメージはありません）。インターネットからポート 80 と 443 にアクセスできること。

• ダッシュボード用とアプリ用のドメイン。ステップ 3 の前に、次の DNS レコードを作成してください（Let's Encrypt が確認します）。

  レコード	向き先	例
  ダッシュボードのホスト用 A（および／または AAAA）	サーバー	drobek.example.com
  ワイルドカード A／AAAA *.<APPS_DOMAIN>	サーバー	*.apps.example.net

  アプリ用に別の登録可能なドメイン（example.com に対する example.net）を用意するのがより安全です。apps.<your dashboard domain> も使用できます。 DNS がまったくないテスト環境の場合は、ステップ 3 で DOMAIN=localhost を使用してください。Caddy のローカル CA（tls internal）が使われ、サーバー自身からのみアクセスできます。

• SMTP アカウント（ホスト、ポート、ユーザー、パスワード、送信元アドレス）または Resend API キー。サインインコードはメールで送信されます。

すべてのコマンドは root として実行します（または先頭に sudo を付けます）。

1. Docker、git、go-task

curl -fsSL https://get.docker.com | sh
apt-get install -y git openssl
snap install task --classic
docker compose version     # → Docker Compose version v2.x (or newer)
task --version             # → Task version: v3.x

2. drobek のファイル（compose ファイル、スクリプト、環境変数のテンプレート。イメージ自体は GHCR から取得します）

git clone https://github.com/freema/drobek /opt/drobek
cd /opt/drobek
git checkout "$(git tag -l 'v*' --sort=-v:refname | head -n 1)"   # the newest release (skip before the first one)

3. 設定 — すべてのシークレットを生成し、.env.production（モード 600）を書き込み、イメージ付属のジェネレーターで deployments/Caddyfile を生成します（ホストに Node は不要です）。

DOMAIN=drobek.example.com APPS_DOMAIN=apps.example.net \
[email protected] [email protected] \
SMTP_HOST=smtp.example.com SMTP_PORT=587 [email protected] \
[email protected] \
task selfhost:init

出力例（抜粋）：

✓ created .env.production from .env.production.example (mode 600)
✓ generated POSTGRES_PASSWORD
✓ generated DROBEK_MASTER_KEY
✓ generated TLS_ASK_TOKEN
✓ dashboard https://drobek.example.com · apps https://<slug>.apps.example.net
✓ TLS mode for the app hosts: on-demand
✓ rendered deployments/Caddyfile (on-demand)
✓ docker compose config: OK

次に、SMTP パスワードを入力します（コマンドラインには絶対に入力しないでください）。

nano .env.production       # SMTP_PASS='…'   (single quotes if it has $, # or spaces)

task selfhost:init は確認を求めず、シークレットを上書きすることもありません。いつでも再実行できます（TLS 設定を変更した後は task tls:reload を実行してください）。 実ドメインの場合、TLS のデフォルトはオンデマンドです（アプリのホストごとに Let's Encrypt 証明書を発行し、drobek が発行を制御します）。TLS_MODE=wildcard-file または TLS_MODE=dns を指定すると、代わりにワイルドカード証明書が使われます。docs/SELF-HOSTING.md の「TLS」を参照してください。

4. 起動

docker compose --env-file .env.production -f docker-compose.production.yaml up -d --wait

初回起動時にはイメージが取得され、drobek がすべてのデータベースマイグレーションを適用します。想定される状態は、Container drobek-prod-postgres-1 Healthy、…-redis-1 Healthy、…-drobek-1 Healthy、…-caddy-1 Healthy です。

curl -s https://drobek.example.com/healthz      # → {"ok":true,"db":"up","redis":"up"}
curl -s https://drobek.example.com/api/version  # → {"name":"drobek","sha":"<commit>","version":"vX.Y.Z","commitTime":"…","startedAt":"…","modules":[…]}

ヒント：alias dc='docker compose --env-file .env.production -f docker-compose.production.yaml' と設定すると便利です。このガイドでは、以降もコマンドをすべて記載します。

5. サインイン — https://drobek.example.com を開き、SUPERADMIN_EMAIL を入力して、メールで届いた 6 桁のコードを入力します。個人用ワークスペースの /me が表示されます。

6. エージェントを接続する（Claude Code）

claude mcp add --transport http drobek https://drobek.example.com/mcp

Claude Code は drobek の OAuth サーバーを検出し、ブラウザーで同意ページ（read、write、publish）を開いて、ユーザーに紐づくトークンを取得します。エージェントのマシンでブラウザーを使えない場合は、代わりにサーバーで API キーを発行し、ヘッダーとして渡してください。

docker compose --env-file .env.production -f docker-compose.production.yaml exec drobek \
  node node_modules/@drobek/oauth/dist/cli/api-key-create.js \
  --email [email protected] --name laptop --scopes read,write,publish
# → drk_…   (shown once)
claude mcp add --transport http drobek https://drobek.example.com/mcp \
  --header "Authorization: Bearer drk_…"

7. アプリを公開する — エージェントに 「drobek でチップ計算機を作成して公開して」 と依頼します。エージェントは create_app → write_files → publish を呼び出します。返された published_url（https://tip-calculator.apps.example.net）を開いてください。オンデマンド TLS の場合、新しいアプリホストへの初回リクエストでは、証明書の発行に数秒かかります。

DNS のないテスト環境 — Caddy のローカル CA を使用する場合も、手順は同じです。

DOMAIN=localhost [email protected] SMTP_HOST=… task selfhost:init   # → TLS mode internal
docker compose --env-file .env.production -f docker-compose.production.yaml up -d --wait
docker compose --env-file .env.production -f docker-compose.production.yaml cp \
  caddy:/data/caddy/pki/authorities/local/root.crt ./drobek-root.crt
curl --cacert drobek-root.crt https://localhost/healthz

警告なしで使用するには、ブラウザー／OS で drobek-root.crt を信頼するように設定してください（Node クライアントの場合：NODE_EXTRA_CA_CERTS=drobek-root.crt）。アプリホストは https://<slug>.apps.localhost となり、ブラウザーはこれをサーバー自身に解決します。 HTTPS_PORT=8443（および HTTP_PORT=8080）を指定すると、Caddy のポートを 443 以外に変更できます。その場合、すべての URL にポートが含まれます。

バックアップ（task backup、task backup:verify、task restore）、アップグレード（task selfhost:upgrade）、DROBEK_MASTER_KEY のローテーション（task selfhost:rekey）、3 種類の TLS 設定、カスタムドメイン、不正利用への対応、すべての設定については、docs/SELF-HOSTING.md を参照してください。

エージェントを接続する

MCP エンドポイントは <PUBLIC_APP_URL>/mcp です（OAuth 2.1。クライアントが自動的に検出、登録し、ユーザーの同意を求めます）。スコープは read、write、publish です。トークンはユーザーに紐付けられ、所属するすべてのワークスペースに適用されます。各ワークスペースでは、ユーザーのロールに応じた権限が適用されます。

• Claude Code： claude mcp add --transport http drobek https://drobek.example.com/mcp を実行し、/mcp → サインインします。ホスト型の drobek を使う場合は、claude plugin marketplace add freema/drobek-plugin と claude plugin install drobek@drobek を実行します（MCP サーバー、ビルドスキル、/drobek:build-app）。
• Claude（ウェブ／デスクトップ）： /mcp URL を使ってカスタムコネクターを追加します。
• Cursor： ~/.cursor/mcp.json → { "mcpServers": { "drobek": { "url": "https://drobek.example.com/mcp" } } }。
• Codex： ホスト型の drobek を使う場合は、codex plugin marketplace add freema/drobek-plugin、codex plugin add drobek@drobek、codex mcp login drobek を実行します。
• スクリプト／CI： /me/api-keys で発行した個人用 drk_… API キーを Authorization: Bearer drk_… として指定します。

エージェントは次のツールを利用できます。list_apps、create_app、duplicate_app、get_app、read_file、write_files、バージョン履歴用の restore_version、list_versions、keep_version、delete_versions、publish、set_gallery_listing、アプリの設定とライフサイクル用の unpublish、set_visibility、set_frame_ancestors、release_lease、delete_app、skill_info、configure_module、query_data、アプリに保存されたデータ用の create_records、update_record、delete_record、delete_collection、purge_orphan_records、get_logs、訪問者数用の get_analytics、動画、音声、画像、フォント用の create_asset_upload、list_assets、delete_asset（アップロード URL を使うため、ファイルがモデルを経由することはありません）、オーナーのモジュールタブ用の list_form_submissions、delete_form_submission、list_end_users、set_end_user_role、set_end_user_blocked、sign_out_end_users、list_uploads、delete_upload、remove_module_secret、list_activity、プレビューの Feedback ボタンからメンバーが残したメモ用の list_feedback、get_feedback_screenshot（メモに添付されたスクリーンショットを画像として取得）、resolve_feedback、delete_feedback、ユーザーに表示されている内容を確認するための request_screenshot（開いているプレビューに Capture バーを表示）と get_screenshot、カスタムドメイン用の list_domains、add_domain、verify_domain、set_primary_domain、remove_domain、プロキシモジュールの外部 API 用の list_upstreams、register_upstream、set_upstream_streaming、remove_upstream、同期モジュールのスケジュール済みインポート用の sync_now、ワークスペース用の create_workspace、list_members、invite_member、set_member_role、remove_member、delete_workspace（スーパー管理者はさらに set_workspace_publishing、set_workspace_module、takedown_app、restore_app、set_gallery_hidden も利用できます）。エージェントの仕様（スコープ、ブリーフィング、スキル、/llms.txt）の全文は docs/AGENT.md にあります。稼働中のサーバーでは、/llms.txt、/llms-full.txt、/build-with-your-agent から参照できます。プラグインを使わずにエージェントに一連の手順を教えるには、cp -r skills/drobek ~/.claude/skills/drobek を実行します。

ローカルで開発する

前提条件：スタックの実行には Docker（Compose v2）、ホスト側で task check / task e2e を実行するには go-task 3、Node 22、pnpm 10 が必要です。

git clone https://github.com/freema/drobek && cd drobek
cp .env.example .env
# Two edits make it yours (the rest have working dev defaults):
#   1. SUPERADMIN_EMAIL  → the email you'll sign in with (becomes super-admin)
#   2. DROBEK_MASTER_KEY → a real key:  openssl rand -hex 32
task dev          # or: docker compose up -d --build

サービス	ホストポート	確認方法
drobek（ダッシュボード + OAuth AS + MCP /mcp）	3041	GET /healthz → {ok,db,redis}（依存先が停止している場合は503）；GET /health → {ok:true}
postgres 17	5441	pg_isready
redis 7	6391	redis-cli ping
mailpit（開発用SMTPシンク）	8025	ログインコードがここに届きます

開発スタックでは、すべての組み込みモジュールに加えて、サンプルの drobek-module-hello と drobek-module-acme-crm（オプトイン。task dev によって ./.modules にインストールされます）を実行します。localhost:3041 でサインインし（コードはMailpitに届きます）、エージェントの接続先を http://localhost:3041/mcp に設定してください。

アプリをローカルで開く。 APPS_DOMAIN=apps.localhost:3041 を設定します。ブラウザーでは すべての *.localhost 名がマシンに解決されるため、/etc/hosts に 追加する必要はありません。

ホスト	配信内容
http://<slug>--preview.apps.localhost:3041	コンパイル済みの最新バージョン
http://<slug>.apps.localhost:3041	公開済みバージョン（初回公開までは「まだ公開されていません」と表示されます）
http://<slug>--v<N>.apps.localhost:3041	バージョンNを指定

curlとNodeでは、どこでも *.localhost が解決されるわけではありません。代わりに、 Host ヘッダーでアプリのホストを指定してください。

curl -i -H 'Host: <slug>--preview.apps.localhost:3041' http://127.0.0.1:3041/

ブラウザーはプレーンな http://localhost 上で __Host- Cookieを拒否するため、HTTP開発スタック（NODE_ENV ≠ production）では、プレフィックスのない、ホスト限定の drobek_session / drobek_app_access / drobek_eu を使用します。本番環境とすべてのHTTPSオリジンでは __Host- 名を使用します。task dev:tls を実行すると、ローカルCAを使用して開発スタックをCaddy経由で https://localhost 上に起動できます。OAuth フローを使わないスクリプトでは、task api-key:create [email protected] NAME=laptop SCOPES=read,write を使用してください。

日常的に使うコマンド：

task dev          # build + start the stack, wait until healthy
task check        # host-side gate: install, doc-lint, build packages + app bundle, typecheck, lint, knip, unit tests
task logs         # tail the drobek service
task health       # curl the health endpoints
task e2e          # Playwright suite (incl. @local specs) vs the stack
task e2e:image    # what CI runs: the prod image behind Caddy + the whole suite
task e2e:smoke    # @smoke specs only (safe against any target, prod included)
task build        # build the production image ghcr.io/freema/drobek:<sha>
task prod:proof   # build + prove the prod image (size, non-root, fail-closed, live boot)
task dev:tls      # dev stack behind Caddy (tls internal); task dev:tls:down to leave
task db:generate  # drizzle-kit generate (journal __drizzle_migrations_core)
task down         # stop the stack (docker compose down -v also wipes the data)

コントリビューター向けルールとリポジトリ構成については、CLAUDE.md を参照してください。 公開リポジトリ、エージェントプラグインとサーバーモジュールの違い、外部利用者向けチェックについては、docs/ECOSYSTEM.md を参照してください。

エンドツーエンドテスト

tests-e2e は、2 つの段階からなる Playwright スイートです。

• @local — ローカルスタックが必要です。Postgres／Redis／ Mailpit を直接使ってデータを投入し、読み取ります。global-setup.ts は最初にコアテーブルを TRUNCATE しますが、ALLOW_DESTRUCTIVE=1 かつ DATABASE_URL のホストが許可リスト （localhost、127.0.0.1、postgres）に含まれる場合に限ります。

• @smoke — パブリック HTTP と MCP のみを使い、本番環境に対しても安全です。データベース、 Redis、Mailpit は決して使いません。MCP スモークループ（mcp-loop.spec.ts）は、 （環境変数からのみ読み込む）SMOKE_API_KEY の drk_ キーでサインインし、 smoke-* アプリを作成、プレビュー、公開して、後に何も残しません。 MCP には削除ツールがないため、このテストは対象に応じてクリーンアップします。ローカルスタック （TEST_ENV=local）に対しては、新しい smoke-<random> アプリを作成し、テストが失敗した場合も含めて 最後にダッシュボードの削除操作から削除します。サインインには、メール OTP（Mailpit）を使って スモークユーザーとしてログインします。それ以外の対象（本番環境）に対しては、キーごとに 安定したアプリを 1 つだけ再利用します。アプリ名は smoke-<key の SHA-256 の 12 桁の 16 進数> です （list_apps → get_app の後、新しいバージョンを作成して公開します）。これにより、本番環境には スモーク ID ごとにスモークアプリが常に 1 つだけ存在します。

  BASE_URL_WEB=https://drobek.app SMOKE_API_KEY=drk_… task e2e:smoke
  

  キーがない場合、localhost を対象とするとテストはスキップされ、それ以外の対象では失敗します。 task e2e では、ローカル DB に一時的なキーを作成します。

mcp-loop.spec.ts は、エージェントのエンドツーエンドループをテストします。OAuth プロバイダーを使った 公式 MCP SDK クライアントで（401 → ディスカバリー → DCR → Playwright が操作する PKCE 同意画面 → トークン）、 続いて list_apps → create_app → write_files（コンパイルエラー → 修正）→ プレビューホスト → publish → 本番ホスト → restore_version → get_app を実行し、90 秒以内に完了することを検証します。

task e2e は開発スタック（task dev）に対して実行します。task e2e:image は CI のフローです （.github/workflows/ci.yml は同じ scripts/e2e-image.sh を実行します）。 本番イメージをビルドし、docker-compose.e2e.yaml（プロジェクト名 drobek-e2e、専用のループバックポートを使用するため、開発スタックと並行して実行できます）で起動して、 Caddy の tls internal の背後で https://localhost:8443 と https://<slug>--preview.apps.localhost:8443 を公開します。新しい DB をマイグレーションした後、 @smoke と @local を実行します（フェーズ 1）。次に drobek を EMAIL_TRANSPORT=relay および PUBLISH_APPROVAL=approval で再作成し、これらを必要とするテストを 実行します（フェーズ 2）。その後、すべてを停止します。スキップガード （scripts/e2e-skip-guard.mjs）は、どちらのフェーズでも実行されなかったスイート内のテストがある場合、 実行を失敗させます。イメージは NODE_ENV=production で動作し、開発スタックの簡易設定を無視するため、 e2e スタックでは本番環境に近い代替サービスを用意します。具体的には、Caddy の背後で HTTPS 経由で動作する モック IdP（tests-e2e/mock-oidc.mjs）をサーバーの AUTH_OIDC_ISSUER として設定し、 開発用 DNS モックと同じ Redis キーから応答する DNS サーバー（tests-e2e/dns-mock.mjs）を DOMAINS_DNS_SERVERS に設定します。また、Caddy からのみ送信される TLS の要求と クライアントの X-Real-IP を受け取るため、drobek 自身のポートを 127.0.0.1:3451 で公開します。 DROBEK_IMAGE=… を指定するとビルドをスキップし、E2E_KEEP=1 を指定するとスタックを維持します。 追加の引数を指定すると、フェーズの代わりに Playwright を 1 回だけ実行します （task e2e:image -- tests/mcp-loop.spec.ts。E2E_PHASE=2 を指定すると、フェーズ 2 の設定で実行します）。

どちらのスタックにも、オペレーターが行う方法で 2 つの外部モジュールをインストールします。 examples/drobek-module-acme-crm と、オペレーター専用のテスト用フィクスチャ tests-e2e/fixtures/drobek-module-ops-probe です（開発スタックでは task module:example と task module:fixture、イメージのフローでは scripts/e2e-image.sh を使います）。このフィクスチャは、 どちらのスタックでもエラーレポーターとして動作します（ERROR_REPORTER=capture： レポートは e2e の proxy-echo に送信され、テストから読み取れます）。さらに、開発スタックでは メールトランスポートとして動作します（EMAIL_TRANSPORT=relay：すべてのメッセージが HTTP API 経由で Mailpit に送信されます）。イメージのフローでは、フェーズ 1 では組み込み SMTP を使い、 フェーズ 2 でリレーに切り替えます。

バージョンとアップグレード

drobek はセマンティックバージョニングに従います。0.x の間は、マイナーリリースで運用者による作業が必要になる場合があり、その内容はリリースノートに記載されます。各リリースには、Git タグ vX.Y.Z、不変のイメージ ghcr.io/freema/drobek:vX.Y.Z、GitHub リリース、およびCHANGELOG.mdのエントリーがあります。latest と previous はリリースごとに更新されます（docs/SELF-HOSTING.md → イメージタグ）。マイグレーションは前方にのみ実行され、task selfhost:upgrade の独立したステップとして実行されます。データベースより古いイメージは起動を拒否し、実行すべきリリースを示します。ロールバックする場合は、以前のイメージに戻し、リリースによってデータベースがマイグレーションされた場合は、その前に取得したバックアップを使用します（アップグレードとロールバック）。モジュールは必要とするコントラクトの範囲を宣言し、サーバーは対応できないモジュールがあると起動を拒否します（docs/MODULES.md → 互換性）。

drobek を拡張する：モジュールを作成する

アプリのバックエンドはプラットフォームモジュールの集合であり、誰でもモジュールを作成できます。公開されているコントラクトを使った npm パッケージを作成し、イメージをビルドせずに運用者がインストールできます。

npm create drobek-module@latest erp   # routes, SDK slice, migration, SKILL.md, tests

コントラクトは npm で @freema/drobek-modules として公開されています。スキャフォールドは、モジュールのコードでインポートする名前である @drobek/modules でインストールします（"@drobek/modules": "npm:@freema/drobek-modules@^X.Y.Z"）。

docs/MODULES.md → モジュールの作成では、コントラクトの使用方法、公開、インストールについて説明しています。動作するモジュールはexamples/drobek-module-hello、オプトインでイメージを使わずにインストールできるモジュールはexamples/drobek-module-acme-crmです。また、公開済みモジュールには、ほかの人がインストールできるモジュールが掲載されています。

貢献

Issue、質問、プルリクエストを歓迎します。詳細はCONTRIBUTING.mdをご覧ください。質問やアイデアはディスカッションへお寄せください。セキュリティ上の問題は非公開で報告してください（SECURITY.md）。

ドキュメント

ドキュメント	内容
docs/ARCHITECTURE.md	単一プロセス、オリジン、バージョン、コンパイラー、配信、モジュール、TLS、ジョブ
docs/SELF-HOSTING.md	クイックスタート、Compose、すべての環境変数、TLS、バックアップ、アップグレード、カスタムドメイン、不正利用
docs/MODULES.md	プラットフォームモジュールのコントラクトと組み込みモジュール
docs/AGENT.md	エージェントの接続、ツールとスコープ、ブリーフィング、スキル、llms.txt
docs/SECURITY.md	脅威モデルと脆弱性の報告方法
docs/LICENSING.md	AGPL-3.0 §13 と、ホスト型 drobek.app との境界
CHANGELOG.md	すべてのリリース

ライセンス

AGPL-3.0 — docs/LICENSING.mdをご覧ください。