Dokploy/dokploy — 優良食堂詳しい解説

01 / 概要

何をするものか一文で言うと

ひとことでVercel、Heroku、Netlifyに代わる無料でセルフホストできるPaaS。VPS上にアプリケーションやデータベースをデプロイ・管理できます。

Dokployは、VercelやNetlify、Herokuの代替となるオープンソースのセルフホスト型PaaSです。VPS上にNode.js・PHP・Python・Goなどのアプリケーションやデータベースをデプロイし、Docker Composeやマルチノードのクラスタも管理できます。Traefikによるルーティング統合とバックアップ、監視機能まで一体化しているのが特徴です。

02 / 構造

どう動くのか中核のしくみ

読み方動きの流れを図と一緒にほどきました。

コアはNext.jsベースの`apps/dokploy`で、tRPC経由でデプロイ要求を受け付けます。デプロイ処理は`apps/api`のHonoサーバーが担当し、Inngestという非同期ジョブ基盤にイベントを送信して実行します。`deployJobSchema`はzodの判別共用体で、application・compose・application-previewの3種類のデプロイ形態を型で分離しています。デプロイ完了・失敗はInngestイベント（`deployment/completed`・`deployment/failed`）として通知され、UI側はBullMQ風の行データに変換して表示します。本番用Dockerfileでは、ビルド時にNixpacksやRailpack、buildpacksといった複数のビルドエンジンをインストールし、Dockerコマンド自体もコンテナ内に組み込んでいます。起動時はtiniをPID1に据えて、postgres待機・マイグレーション・サーバー起動の順に実行するシェルスクリプトが動く構成です。認証やAPIキー、セッション管理にはzodスキーマによる厳格な入力検証があり、`__test__`配下には200件近いテストファイルがあることからコマンドインジェクションやIDOR、Secret漏えいへの防御を意識した実装であることがうかがえます。

03 / 体験

入れるとこんな体験になりますギット飯が実際にたどった順序

所要ギット飯が実際に導入・実行しながらたどった順序です。

STEP 01
VPS上で`curl -sSL https://dokploy.com/install.sh | bash`を実行すると、Dockerのインストールと初回セットアップスクリプトが走り、しばらく待つとDokployの管理画面がポート開放される様子が確認できます。
STEP 02
ブラウザで管理画面にアクセスすると、管理者アカウント作成画面が表示され、初期設定として組織名やサーバー情報の入力を求められます。
STEP 03
GitHubなどのGitプロバイダを接続し、リポジトリを選択してアプリケーションを新規作成すると、ビルド方式（Nixpacks・Dockerfile・Railpackなど）を選ぶ画面に進みます。
STEP 04
デプロイボタンを押すと、リアルタイムログがWebSocket経由でストリーミングされ、Nixpacksなどによるビルドとコンテナ起動の様子が逐次表示されます。
STEP 05
デプロイ完了後はドメイン設定画面でTraefikのルーティングとSSL証明書発行状況が表示され、実際にURLへアクセスするとアプリが稼働していることを確認できます。
STEP 06
データベースリソースを作成すると、PostgreSQLやMongoDBなどのコンテナが起動し、バックアップ設定画面から外部ストレージ先を登録できる操作感が体験できます。

04 / 成果物

何が手に入るのか導入後に手元に残るもの

1台のVPSに、Git連携によるアプリケーションの自動ビルド・デプロイ、複数種類のデータベース管理、Traefikによる自動ルーティング、バックアップと監視までを備えた管理画面付きのPaaS環境が手に入ります。テンプレート機能を使えば、PlausibleやPocketbaseなどのOSSアプリをワンクリックで追加できる点も実運用上の価値になります。

05 / 注意

ここは先に知っておいてください先に知っておくとよいこと

正直なところ誰にでも合うとは言いにくいところです。

デプロイ実行部分はNixpacks・Railpack・buildpacksなど複数の外部ビルドツールをコンテナ内にインストールする構成のため、初回イメージサイズやビルド時間はそれなりに大きくなると見られます。

`apps/api`のInngest連携やREST APIは`API_KEY`によるヘッダー認証のみで、ネットワーク到達性の管理（ファイアウォールなど）は利用者側の責任になります。

テストディレクトリには`compose-command-injection`や`registry-node-injection`など攻撃想定のテストが多数存在し、裏を返せばDocker Compose設定やGit URLの取り扱いにコマンドインジェクションのリスクが元々あった領域であることを示しています。

READMEやDockerfileから読み取れる範囲では、Docker Swarmによるマルチノード運用の実際の安定性や、大規模アプリでのリソース消費については具体的な数値情報がなく、判断材料が不足しています。

06 / 結論

ギット飯の結論食べてみる価値のある一膳か

ギット飯の最終判断優良食堂

自前のVPSでVercel・Heroku的な体験を求める個人開発者や小規模チームには、Git連携から監視・バックアップまで一体化している点で導入価値が高いと判断できます。判断根拠は、実際のデプロイ経路（tRPC→Inngest→ビルドエンジン→Traefik）がソースコードとDockerfileの記述から具体的に追跡でき、かつコマンドインジェクション対策を意識した大量のテストが存在することにあります。ただし、複数ビルドツールを内包する重量級のコンテナ構成である点と、マルチノード運用時の挙動については、README・ソースの記述だけでは十分な裏付けが取れないため、大規模本番導入前には自身の環境での検証を推奨します。