DROP

DROP

デプロイ、実行、運用、公開

「フォルダーを置いてデプロイする」ワークフロー向けに設計された、軽量でセルフホスト可能な PaaS です。Node.js、Python、Go、静的サイト、コンテナ化されたアプリケーションを、設定不要でデプロイできます。

フォルダーを置けば、URL が手に入ります。80％のユースケースで設定は不要です。

機能

• 設定不要のデプロイ — アプリの種類を自動検出し、ビルドして起動します
• 複数のランタイムに対応 — Node.js、Python、Go、Docker、静的サイト、SPA に対応し、Next.js、Nuxt、SvelteKit、Astro、Express、FastAPI、Flask などのフレームワークも検出します
• ホスト名によるルーティングと HTTPS の自動設定 — Let's Encrypt 証明書、アプリごとのカスタムドメイン
• PostgreSQL の自動プロビジョニング — 各アプリに専用データベースを用意し、DATABASE_URL を設定します
• Redis の管理 — drop.yaml からオプトインできます
• ホットリロード — ファイルを編集すると、アプリが再ビルドされて再起動します
• モノレポ — 1 つのリポジトリから複数のサービスを実行し、同一オリジンの /api ルーティングでホスト名を共有できます
• MCP サーバー — Claude、Claude Code、Cursor などのエージェントからアプリをデプロイ、管理できます
• Docker による分離 — マルチユーザー構成向けに、リソース制限付きのコンテナでテナントアプリを実行します
• REST API とウェブダッシュボード — JWT と API キーによる認証を備えたフル API、リアルタイム監視 UI
• 永続データ — DROP_DATA_DIR を通じて、アップグレード後もアプリのデータを保持します
• クロスプラットフォーム — Windows、Linux、macOS

ドキュメント

完全なドキュメントは dropkit.sh/docs にあり、すべての CLI コマンドと API エンドポイントは リファレンス にまとめられています。この README では、DROP のインストール方法、公開する前に確認すべき信頼モデル、災害復旧について説明します。

トピック	場所
drop.yaml のフィールド、モノレポ、必須シークレット	ドキュメント → drop.yaml
環境変数（プラットフォームおよび設定される変数）	ドキュメント → 環境変数
永続データディレクトリ	ドキュメント → 永続データ
対応ランタイムと検出の仕組み	ドキュメント → ランタイムと検出
Caddy のルーティング、HTTPS、DNS-01 証明書、カスタムドメイン	ドキュメント → ルーティングと HTTPS
データベースの自動プロビジョニングと、その実行条件	ドキュメント → データベース
ログの取得と保持	ドキュメント → ログ
Claude、Cursor などのエージェントとの接続	ドキュメント → インテグレーション
すべての CLI コマンドと REST エンドポイント	リファレンス

このリポジトリには、HTTPS の設定、Git による再デプロイとカスタムドメイン、エージェントによるデプロイもあります。

エージェントは、deploy-to-drop スキルを使って、支援なしで DROP にデプロイできます（Claude Code、Cursor、および SKILL.md 互換のあらゆるエージェントに対応）。

要件

リリース版のインストール（推奨、Linux）： root アクセス権のある、Debian/Ubuntu を新規インストールしたマシンが必要です。install.sh が Node.js、PostgreSQL、Caddy、および（--isolation=docker を選択した場合は）Docker Engine をインストールするため、自分でツールチェーンをインストールする必要はありません。

ソースからビルドする場合： Node.js 20 以降、npm 9 以降、およびホスト名ルーティング用の Caddy 2.0 以降（任意）が必要です。

インストール

install.sh は curl からパイプで直接実行できません。動作にはディスク上のコピーが必要なため、まず保存してから実行してください。

curl -fsSL https://github.com/JulesNsenda/drop/releases/latest/download/install.sh -o install.sh && sudo bash install.sh --from-release --isolation=docker

--from-release を指定すると、公開済みの最新リリースをインストールします。git clone は不要で、お使いのマシンで TypeScript や Vite をビルドする必要もありません。（Node.js は引き続き必要ですが、インストーラーがセットアップします。npm が cpu-features のオプションのビルドに失敗したというログを出す場合がありますが、問題ありません。これは ssh2 用のオプションのネイティブアクセラレーターであり、なくてもインストールは完了します。）

初回インストール時には、分離モードを明示的に選択する必要があります。

• --isolation=docker（推奨）— テナントアプリは Docker コンテナー内でリソース制限付きでビルド、実行され、プラットフォームのシークレットにはアクセスできません。
• --isolation=none — テナントアプリは、プラットフォームの暗号化キーと JWT／OAuth シークレットを所有するユーザーと同じ drop システムユーザーとして実行されます。すべてのデプロイ担当者を完全に信頼できる単一のマシンでのみ選択してください。詳しくはセキュリティと信頼モデルをご覧ください。

DNS がサーバーを指すようになったら、--domain=example.com --https [email protected] を追加してください。最新リリースではなく特定のバージョンを指定するには、--from-release=v1.0.0 を使います。

サービスが起動したら、プラットフォームのログから一度限りの管理者パスワードを取得し、すぐに変更してください。

journalctl -u drop-platform -b --no-pager | grep -A1 'Default Admin Credentials'

Windows：install.sh は systemd／apt を使用する Linux マシンを対象としています。Windows では install.bat を実行するか、ソースからビルドし、drop serve を直接起動してください。Windows は isolation: none で完全にサポートされています。

root として実行する前に確認する

install.sh は、ダウンロードした tarball の SHA-256 チェックサムを、インストール前に自ら検証します。さらに、このリポジトリ独自の GitHub Actions によってビルドされたことも検証するには、ビルドの来歴証明を確認してください。

gh release download --repo JulesNsenda/drop -p drop-dist.tar.gz
gh attestation verify drop-dist.tar.gz --repo JulesNsenda/drop

このリポジトリが公開されてからビルドされた各リリースには、リリースワークフローによって証明が添付されています。gh attestation verify で特定のリリースに証明がないと報告された場合、そのリリースは証明が導入される前のものです。その場合は、公開されている drop-dist.tar.gz.sha256 を使用してください。これは install.sh が自動的にチェックします。

各リリースには、drop-dist.tar.gz（コンパイル済みサーバー、CLI、ダッシュボード）、その .sha256、および install.sh も添付されるため、ネットワークから隔離されたマシンでも手動で取得して確認できます。すべてのリリースはこちらに掲載されています。

ソースからビルドする

コントリビューター向け、またはリリースではなくブランチから実行する場合：

git clone https://github.com/JulesNsenda/drop.git
cd drop
npm install
(cd src/dashboard && npm install)   # the dashboard is a separate package
npm run build                       # compiles the server AND builds the dashboard
npm link                            # makes the 'drop' command available globally

バックエンドコードのみを変更した場合は、npm run build:server でダッシュボードのビルドをスキップできます。

初回起動時に、drop serve は一度限りの管理者パスワードをコンソールに表示します。すぐに変更してください。

クイックスタート

drop serve                               # start the platform
cp -r my-app /var/drop/data/webapps/     # drop a folder in (Windows: xcopy to C:\drop\data\webapps\)

DROP はアプリの種類を検出して依存関係をインストールし、ビルドします。アプリに必要な場合は PostgreSQL データベースをプロビジョニングし、割り当てられたポートで起動します。アプリには http://localhost:<port> からアクセスできます。Caddy がインストールされている場合は、http://my-app.localhost からもアクセスできます。ファイルを編集すると、自動的に再ビルドされて再起動します。

ダッシュボードには http://localhost:3000/dashboard からアクセスできます。アプリ一覧、アプリごとの起動／停止／再起動、シークレット、カスタムドメイン、デプロイ履歴、ログ、ユーザー管理、Claude コネクターの詳細が用意されています。

CLI と REST API については、リファレンスをご覧ください。DROP の稼働中は、/dashboard/docs と /dashboard/reference からもアクセスできます。

セキュリティと信頼モデル

完全には信頼できない相手に DROP を公開する前にお読みください。

DROP には、信頼性の保証が異なる2つの明示的な分離モードがあります。

isolation: none（デフォルト）— シングルユーザー／信頼できるデプロイ

アプリをデプロイするとは、ホスト上で DROP プロセスのユーザーとして、そのコード（インストール／ビルドスクリプトとアプリのプロセス）を実行することです。デプロイされたアプリ、またはそのビルドスクリプトは、ほかのアプリのデータやプラットフォーム自体のファイルを読み取ることができます。

次のような場合に使用してください： ご自身が所有または管理しているマシンで、デプロイアクセス権を持つ全員を信頼できる場合です。デプロイアクセスはシェルアクセスと同等に扱ってください。

• このモードでは allowSignup を絶対に有効にしないでください。有効にすると、DROP は起動時に拒否します。
• 信頼できるローカルマシンでのみ認証を無効にしてください（DROP_DISABLE_AUTH=true）。
• このモードは Windows を完全にサポートしています。

isolation: docker — マルチユーザー／招待ユーザー

アプリは、厳格なリソース制限（--cap-drop=ALL、--security-opt no-new-privileges、メモリ／CPU の上限、--pids-limit）を設定した Docker コンテナ内でビルドおよび実行されます。ビルドコンテナはプラットフォームのシークレットにアクセスできず、LAN やクラウドメタデータのエンドポイントにも到達できません。

正直に明示している残存リスク（隠さずに記載しています）：

• カーネルの共有：コンテナは VM ではありません。カーネルの脆弱性を悪用されると、ホストへの完全なアクセスを許してしまいます。この点はここに明記しており、軽減策はありません。
• 外部への通信：コンテナはインターネットに接続できます（パッケージのインストールに必要です）。コンテナから LAN／メタデータへの通信はブロックされますが、包括的な外部通信ポリシーは今後のリリースで対応予定です。
• 共有ドメインの Cookie：登録可能なドメインが同じサブドメインは、同一サイトのコンテキストを共有します。a.yourdomain.com と b.yourdomain.com のアプリは、互いの Cookie を読み取ることができます。マルチテナントで使用する場合は、専用の baseDomain を使用するか、Public Suffix List に登録してください。
• オープンなサインアップ（allowSignup: true）を有効にすると、ユーザーが自分で登録できるようになります。悪用対策ツール、サービス停止手順書、悪意のあるパブリックアクセスに対する外部通信の制御は、今後対応予定です。それまでは、インターネットに公開した状態でのサインアップは、明記されている残存リスクとして扱ってください。
• 依存関係はアプリのディレクトリ内に配置する必要があります。 ビルドと実行は、/app のバインドマウントのみを共有する別々の一時コンテナ内で行われます（イメージのコミットはありません）。そのため、実行環境に引き継がれるのは、アプリのディレクトリ内に書き込まれた依存関係だけです。Node（node_modules）、Go（コンパイル済みバイナリ）、Python（bin/ が実行時の PATH に追加される /app 内の .venv）はいずれも、そのディレクトリ内に配置されます。カスタムビルドコマンドでシステムの site-packages やグローバルプレフィックスにインストールしたものは、ビルドコンテナとともに破棄されます。ビルドは「成功」しても、アプリは起動時にインポートエラーで失敗します。

このモードには Linux 上の Docker Engine が必要です（Windows／macOS の Docker Desktop は、開発用／ベストエフォートのサポートに限られます）。

ビルドコンテナは、CAP_DAC_OVERRIDE を必要とせずにアプリのソースを書き込めるよう、プラットフォーム自体の（非 root）ユーザーとして実行されます。DROP 経由でデプロイされたアプリ（git デプロイ、webhook、drop deploy）は、自動的にそのユーザーの所有になります。代わりに、フォルダーを data/webapps/ に手動で配置する場合は、プラットフォームユーザーの所有にしてください（例：chown -R drop:drop）。別のユーザーが所有するフォルダー（root として実行した sudo cp など）は、EACCES によりビルドに失敗します（フェイルクローズ設計です。DROP は回避策として信頼できないビルドを root で実行しません）。

両モードで強化されている項目

• API 認証（JWT + API キー）、ロール階層（readonly／user／admin）
• ソケットの接続元アドレスをキーにしたレート制限（偽装可能な x-forwarded-for は使用しません）
• すべてのファイル入出力およびデプロイパスに対するパストラバーサルとパス包含のチェック
• webhook および git-clone URL に対する SSRF ガード（プライベートアドレス範囲 + DNS 解決チェック）
• 厳格な drop.yaml スキーマ（未知のキーは拒否。TLS パスはアプリのディレクトリ内に制限）
• drop.yaml の値が docker run の引数やマウント設定に直接渡されることはありません
• .git メタデータを含むアップロードアーカイブは、無条件で拒否されます
• Git 認証情報は環境経由で Git に渡され、.git/config に書き込まれたり、ps で表示されたりすることはありません
• すべてのデプロイ／ビルド／起動／シークレット／一時停止操作の監査ログ
• 同梱の PostgreSQL は scram-sha-256 に固定。Unix ソケット認証は peer 認証に制限

セキュリティに関わるすべての設定については .env.example を参照してください。

バックアップと復元

DROP の重要な状態は、data/drop-svc/ 以下のファイルストア（認証情報、暗号化されたシークレット、暗号化キー、Webhook、アプリの状態）と PostgreSQL（内部の drop_internal データベースおよびプロビジョニングされたアプリごとのすべてのデータベース）に保存されています。以下でそのすべてをスナップショットします。

drop backup            # writes data/backup/backup-<timestamp>/
drop backup --keep 14  # keep the newest 14, prune the rest

バックアップには、JSON/YAML ストア、encryption.key、drop_internal の pg_dump、databases/ 以下に保存されたアプリごとの各データベースの pg_dump -Fc（およびアプリの DB ロールを再作成する、生成された databases/restore-roles.sql）が含まれます。スケジュールはご自身で設定してください（cron／Task Scheduler）。DROP はバックアップを自動実行しません。アプリごと、内部、またはデータベース一覧の取得でダンプに失敗すると、バックアップコマンドはゼロ以外の終了コードを返します。そのため、終了コードだけを確認する cron ジョブでも、部分的なバックアップを検出できます。

注意：バックアップは同一プラットフォーム間でのみ使用できます。 Windows で取得したバックアップは Linux では復元できません（逆も同様です）。同梱の PostgreSQL バイナリとデータレイアウトはプラットフォーム固有です。

復元

drop restore はバックアップを復元します。破壊的な操作であり、現在のファイルストアとデータベースを上書きするため、プラットフォームの稼働中は実行できず、--confirm が必要です。また、最初に実行計画を表示します。

drop restore data/backup/backup-<timestamp>/            # prints the plan, writes nothing
drop restore data/backup/backup-<timestamp>/ --confirm  # actually restores

• 最初にプラットフォームを停止してください。 稼働中の drop serve は状態をメモリに保持しているため、復元内容を上書きしてしまいます。drop restore は、デーモンが検出された場合、またはフォアグラウンドのプラットフォームが API ポートで応答している場合に実行を拒否します。

• ファイルストア（data/drop-svc/、data/appconf/webapps/）は、モードを維持したままコピーして戻されます（シークレットは 0600 のままです）。

• データベースは、同梱の psql／pg_restore で復元されます。ただし、drop server stop は同梱の PostgreSQL も停止するため、通常の手順では drop restore は PostgreSQL に接続できず、データベースごとの正確なコマンドを表示して、自動 DB 手順をスキップします。データベースを自動で復元するには、先に PostgreSQL を単独で起動してから、再実行してください。

  "<dropRoot>/apps/drop-svc/pgsql/bin/pg_ctl" -D "<dropRoot>/data/db" start
  drop restore data/backup/backup-<timestamp>/ --confirm
  

DB 手順では、バックアップ内のコピーではなく、現在稼働中のサーバーの data/drop-svc/.pg-superuser を使って認証します（ファイルが上書きされる前に読み取ります）。復元後、次にプラットフォームを再起動するまでは、稼働中のサーバーのパスワードと復元されたファイルの内容が異なる場合があります。

手動で行う場合（drop restore が実行する処理と同等で、DB 手順をスキップした際に表示される内容です）。

BIN=<dropRoot>/apps/drop-svc/pgsql/bin ; export PGPASSWORD="$(cat data/drop-svc/.pg-superuser)"
# 1. Recreate app roles (clean server runs clean; on a re-run, "role already exists" is expected/benign)
"$BIN/psql" -h 127.0.0.1 -p 5433 -U postgres -d postgres -f databases/restore-roles.sql
# 2. Recreate + restore each database, drop_internal included (--create makes the DB AND restores REVOKE CONNECT)
"$BIN/pg_restore" -h 127.0.0.1 -p 5433 -U postgres --create -d postgres databases/drop_<app>.dump
#    (re-run over existing DBs: add --clean --if-exists ; check exit codes, don't ignore stderr)

システムの Postgres クライアントではなく、apps/drop-svc/pgsql/bin 以下の同梱の pg_restore／psql を使用してください。メジャーバージョンが一致しないと復元が破損する場合があります。バックアップは同一プラットフォーム間でのみ使用できます（Windows のバックアップは Linux では復元できません）。また、DB 復元の一連の処理は自動テストの対象外です。まず本番環境以外で検証してください。

削除前のデータベースダンプ

アプリ（drop remove <app>／DELETE /api/v1/apps/:name）を削除すると、プロビジョニングされたデータベースはダンプ後に削除されます。データベースを削除する前に、DROP は data/backup/pre-delete/<db>-<timestamp>.dump に pg_dump でダンプし、対応する <db>-<timestamp>.restore-role.sql も作成します（-Fc にはロールが含まれないため、ロールを再作成します）。ダンプの検証に成功した場合にのみ削除されます。pg_dump に失敗した場合、または Postgres が停止している場合は、データベースを失わないよう、そのまま残します。削除前ダンプは DROP_PREDELETE_RETENTION_DAYS 日間（デフォルトは3）保持され、その後の削除時に自動的に整理されます。恒久的に保存したいものは、それまでに別の場所へコピーしてください。

drop remove --keep-data <app> を実行すると、ダンプ後の削除をスキップし、データベースをそのまま残します。

削除前ダンプを復元するには、上記の復元セクションと同じ手順を使用します。.restore-role.sql を psql で実行し、続いて .dump ファイルを pg_restore --create で復元してください。

アップグレード

DROP は、プラットフォームの再起動中も PM2 管理下のアプリプロセスを稼働させます。ただし、同梱の PostgreSQL と Caddy はプラットフォームとともに停止・再起動するため、アップグレード中はデータベース接続とルーティングが一時的に途切れることがあります。

• まずバックアップを取ってください（drop backup）。
• デーモンを実行している場合は、アップグレード後に drop server stop を実行し、その後 drop serve -d を実行してください。通常の pm2 restart では、PM2 のダンプに保存された古い引数やパスがそのまま使われます。
• 注記： v1.0 以降、drop serve -d は、以前は無視されていた --root/--domain/--https/... フラグを有効にします。これまで効果のなかったフラグを指定していた場合、今後は有効になります。アップグレード前に内容を確認してください（たとえば、不要な --https があると、HTTPS が有効になり、ドメイン設定の検証が行われます）。

破壊的変更は、CHANGELOG の各リリースノートの冒頭に記載されています。

開発

npm run dev          # start in development mode
npm run build        # build server + dashboard
npm test             # run tests
npm run lint         # lint

ブランチモデルと規約については、docs/GIT-BRANCHING-MODEL.md をご覧ください。ロードマップの詳細については、docs/VERSION-ROADMAP.md をご覧ください。

ロードマップ

• ゼロ設定のデプロイ、ホットリロード、PostgreSQL の自動プロビジョニング、REST API とウェブダッシュボード、Caddy リバースプロキシ、自動 HTTPS (0.1.0–0.3.0)
• Docker による分離、ホスト型 MCP サーバーと OAuth 2.1、モノレポ／マルチサービスのデプロイ、マネージド Redis、カスタムドメイン (1.0.0)
• ログの集約と検索
• マルチノードクラスタリング

ライセンス

MIT License — 詳細については LICENSE をご覧ください。