PR公式情報を2026年9月4日に確認

DOKPLOY ON XSERVER VPS

XServer VPSでDokployをGit連携から本番運用まで

Dokployは、Gitで管理するWebアプリを繰り返しデプロイしたい人に向きます。ただし「管理画面から公開できる」と「安全に運用できる」は別です。まず停止しても困らない1アプリで、公開・更新・復元まで通します。

Dokploy対応状況を公式で確認 8ステップを見る

DEPLOYMENT FLOW

Git push

対象ブランチ

Build

Nixpacks / Dockerfile

Deploy

Application container

Route

Domain / HTTPS

DB・アップロード・秘密情報は、アプリのコンテナとは分けて守ります。

GO LIVE GATE

公開前に4つそろえる

ADMIN

管理者作成済み

管理用ドメインをHTTPS化し、直接3000番を閉じる

SECRETS

秘密情報を分離

Gitへ入れず、環境・サービス単位で権限を絞る

DOMAIN

公開経路を確認

DNS・HTTPS・Target Port・リダイレクトを確認

RECOVERY

戻せる状態

アプリのロールバックとDB復元を別々に試す

FIT CHECK

Dokployが向くケース・急がないケース

向いている

Gitで管理するWebアプリやAPIを公開したい
同じアプリを継続して更新する
stagingとproductionを分けたい
小規模チームでデプロイ手順を共通化したい
障害時にログ確認・復元を担当できる

急がなくてよい

WordPressを1サイトだけ簡単に運用したい
OSやDockerの管理担当がいない
最初から停止できない本番サービスを載せたい
秘密情報や権限の管理ルールがない
バックアップから戻す方法を用意できない

管理画面型でも、障害時にはサーバー・Docker・アプリの切り分けが必要です。「誰が更新し、誰が戻すか」まで決められる場合にDokployの便利さが生きます。

公開範囲は最小限にする

XServer VPSの公式Dokployマニュアルが案内する通信を起点に、用途別の公開方針を決めます。管理用とアプリ公開用を混同しないことが重要です。

ポート	用途	公開方針	確認点
TCP 80	HTTP・証明書処理	公開	HTTPSへの転送と到達性
TCP 443	HTTPSアプリ公開	公開	独自ドメインと証明書
TCP 3000	Dokploy初期管理	初期設定時のみ	管理用HTTPS化後に直接アクセスを閉じる
TCP 22	SSH	使う場合だけ	SSH鍵・接続元制限・ログ
DBポート	PostgreSQL等	原則非公開	アプリ内部通信とバックアップ経路

最優先：初期管理画面へ到達したら、第三者より先に管理者を作成します。管理用ドメインとHTTPSを確認した後は、公式マニュアルの手順に沿ってIPアドレス:3000への直接アクセスを無効化します。

導入から公開までの8ステップ

用途と最初の1アプリを決める

まずは停止しても業務へ影響しない検証用アプリを1つ選びます。必要なメモリはDokploy本体だけでなく、ビルド処理、アプリ、データベースの合計で考えます。

本番アプリを最初の練習台にしない。

Dokployアプリイメージを選ぶ

XServer VPSの申込みまたはOS再インストール画面でDokployを選択します。既存サーバーへ入れ直す場合、OS再インストールでデータが消えるため、必要なデータをVPS外へ退避してから進めます。

現在の対応プランと動作要件は、申込み前に公式情報で確認する。

必要な通信だけ許可する

公式マニュアルを基準にTCP 80・443・3000を確認し、SSHを使う場合のみ22番も扱います。データベースのポートは、外部接続の明確な理由がなければ公開しません。

管理画面の初期設定が終わるまで、3000番を放置しない。

管理者を作り、管理画面をHTTPS化する

VPSのIPアドレスと3000番ポートで初期画面へ入り、すぐに管理者を作成します。次に管理用ドメインとHTTPSを設定し、確認後はIPアドレス:3000への直接アクセスを閉じます。

管理者作成前の画面を第三者が操作できる状態にしない。

Project・Environment・Applicationを作る

用途ごとにProjectを作り、stagingとproductionをEnvironmentで分けます。その中へApplicationを作成し、同じ秘密情報やデータベースを安易に共有しない構成にします。

検証環境と本番環境の名前・ドメイン・変数を明確に分ける。

GitHubと対象リポジトリだけ連携する

GitHub Appを接続し、可能ならOnly select repositoriesで必要なリポジトリだけ許可します。Applicationにリポジトリとブランチを指定し、本番へつながるブランチを確認します。

最初から全リポジトリへの権限を与えない。

ビルド・環境変数・ポートを設定する

アプリに合わせてNixpacksまたはDockerfileを選びます。秘密値はGitへ書かずDokployの環境変数へ登録し、アプリが待ち受けるTarget Portを一致させます。

秘密値をログ、README、設定ファイルへ残さない。

検証してから本番公開する

Deploy後にビルドログ、起動ログ、ヘルスチェック、主要画面を確認します。独自ドメインとHTTPSを設定し、更新失敗時の戻し方とDB復元手順がそろってから本番の自動デプロイへ進みます。

『デプロイ成功』だけでなく、利用者の操作まで確認する。

Git連携は「本番へ届く範囲」を決める

便利な自動デプロイほど、リポジトリ権限とブランチの境界が重要です。GitHub Appは必要なリポジトリだけに限定し、productionへ届く変更にはレビューを挟みます。

環境	ブランチ例	デプロイ	役割
Preview	Pull Request	必要時に自動	レビュー前の一時確認
Staging	develop / release	自動または手動	本番と近い条件で動作確認
Production	main	承認後	レビュー済み変更だけ反映

Nixpacks

アプリを自動判定して素早く検証しやすい選択。検出されたランタイム、ビルドコマンド、起動コマンドを必ず確認します。

Dockerfile

依存関係や実行環境を細かく固定したい選択。再現性は高めやすい一方、イメージ更新と脆弱性対応も自分で管理します。

環境変数と秘密情報を分ける

APIキー、DBパスワード、認証シークレットはGitへ含めず、Dokployの環境変数として登録します。stagingとproductionで値を分け、漏えい時に交換できる単位へ細分化します。

# Gitに置くのは名前の例まで
DATABASE_URL=
APP_SECRET=
PUBLIC_BASE_URL=

# 実値はDokploy側で環境別に登録

独自ドメイン・SSLの確認順

STEP 1

DNS

AレコードをVPSのIPへ向ける

STEP 2

Domain

Dokployへドメインを登録

STEP 3

Port

アプリのTarget Portと合わせる

STEP 4

HTTPS

Let’s Encryptを有効化して確認

502 / Bad Gatewayが出たら

DNSやSSLより先に、アプリが起動しているか、0.0.0.0で待ち受けているか、DokployのTarget Portとアプリの待受ポートが一致しているかを確認します。

本番運用はヘルスチェックから始める

ゼロダウンタイムはスイッチを入れるだけでは成立しません。新しいコンテナが「起動した」だけでなく、リクエストを処理できる状態かをDokployが判断できるようにします。

HEALTH

ヘルスエンドポイント

DB接続など最低限の依存先も含め、短時間で応答する確認URLを用意。

OBSERVE

監視とログ

CPU・メモリ・ディスク、HTTP応答、デプロイログを分けて確認。

ROLLBACK

戻す基準

何分・どのエラー率で旧版へ戻すかを更新前に決める。

バックアップは4層で考える

アプリのソース

Gitリポジトリと、正常稼働したコミットを記録

Dokployの構成

プロジェクト・ドメイン・変数名・権限の棚卸し

永続ファイル

アップロードやVolumeをVPS外へ定期コピー

データベース

論理バックアップを取得し、別環境で復元テスト

手段	戻せるもの	戻らないもの
アプリのロールバック	アプリのイメージ・コード	DB内のデータ、外部サービス、削除済みファイル
DBの復元	取得時点のDBデータ	アプリコード、Volume、バックアップ後の更新

スキーマ変更を含む更新では、旧アプリが新しいDBを読めない場合があります。コードを戻す手順とDBを戻す手順をセットで検証してください。

よくあるトラブルの切り分け

症状	最初に見る場所	主な確認
ビルドが失敗	Deployment logs	ランタイム、依存関係、ビルド方式、コマンド
502が出る	Application logs	起動状態、待受IP、Target Port、ヘルスチェック
SSLが発行されない	DNS / Domains	Aレコード、80・443番、ドメイン表記
pushしても反映されない	Git provider	GitHub App権限、リポジトリ、対象ブランチ
環境変数が反映されない	Environment settings	変数の範囲、保存、再デプロイ
突然ビルドできない	Disk / Images / Logs	ディスク残量、古いイメージ、ログ、バックアップ

本番公開チェックリスト

最初の管理者アカウントを作成した

管理画面を独自ドメイン＋HTTPSへ移した

IPアドレス:3000への直接アクセスを閉じた

GitHub Appを必要なリポジトリだけに限定した

stagingとproductionのブランチ・変数を分けた

秘密値がGitやログに残っていない

ドメイン・SSL・Target Portを確認した

ヘルスチェックと主要操作を確認した

CPU・メモリ・ディスク・HTTP監視を決めた

アプリのロールバックを試した

DBと永続ファイルをVPS外へ保存した

別環境で復元できることを確認した

運用担当と復元手順が決まったら申込みへ

プラン、料金、キャンペーン、アプリイメージの対応状況は変わります。契約直前に公式画面で最新条件と支払総額を確認してください。

XServer VPSの最新条件を見る

よくある質問

Dokployを使えばサーバー運用は不要になりますか？

いいえ。Git連携、ビルド、ドメイン設定は管理画面から行いやすくなりますが、OS・Docker・Dokployの更新、アクセス制御、監視、容量管理、バックアップと復元は利用者側の運用です。

NixpacksとDockerfileはどちらを選べばよいですか？

まず短時間で検証したい一般的なアプリならNixpacksが候補です。OSパッケージ、ビルド工程、実行ユーザー、イメージを細かく固定したい場合はDockerfileが向きます。本番では再現性を確認して選んでください。

GitHubへpushすると自動で公開できますか？

GitHub Appと対象ブランチを設定すれば自動デプロイに使えます。ただし、本番ブランチはレビューや承認を経て更新し、stagingで確認してから反映する運用が安全です。

Dokployの管理画面は3000番ポートで公開したままでよいですか？

初期設定では使用しますが、公式マニュアルは管理用ドメインとHTTPSの設定後にIPアドレス:3000へのアクセスを無効化する手順を案内しています。設定後に外部から到達できないことまで確認してください。

ロールバックすればデータベースも元に戻りますか？

通常、アプリのロールバックとデータベースの復元は別です。旧アプリが新しいDBスキーマを読めない場合もあるため、変更前にDBの論理バックアップを取得し、復元手順を検証してください。

独自ドメインとSSLは設定できますか？

DokployはTraefikを使ったドメイン設定とLet’s EncryptによるHTTPSに対応しています。DNSのAレコード、80・443番ポート、Target Portが正しいかを順に確認します。

確認した公式情報

広告・免責：本記事にはアフィリエイト広告が含まれます。申込みが成立すると当サイトが報酬を受け取る場合があります。掲載内容は確認日時点の情報であり、料金・仕様・提供条件を保証するものではありません。契約・作業前に必ず公式情報とバックアップをご確認ください。

XServer VPSの申込み・初期設定 Dockerを直接使う方法 ConoHa VPSとの比較