さくらのVPSでDocker｜HTTPS公開・再起動耐性まで

さくらのVPSでn8nやDify、Ollamaを動かしたい人が最初につまずくのは、その前提になる「Dockerが動く土台」の作り方です。検索して出てくる手順の多くは古いOSやコマンドが前提で、さくらが用意している最短経路には触れていません。

読み終えるころには、申し込み画面で何を選べばDockerとDocker Composeが入った状態で立ち上がるかが分かります。初回のSSHログインからdocker compose up -dでの疎通確認、独自ドメインでのHTTPS公開、再起動しても消えない設定までを、迷わず一本の流れで進められるようになります。

さくらのVPSは実際に契約していません。さくら固有の仕様（用途の選択肢・対応OS・料金・パケットフィルタ）は公式ページとマニュアルで確認し、Docker自体の挙動（コマンドの違い・メモリの実際の消費量・再起動時の復旧）は同じメモリ制限をかけたローカルのDocker環境で実際に動かして確認しています。どちらの確認かは、本文でそのつど区別します。

迷ったらこれ：用途「Docker実行環境」を選ぶだけでいい

申し込み画面の「おすすめ構成で選ぶ」には用途の選択肢があり、用途を選ぶとスタートアップスクリプトの適用など初期設定が自動で完了する仕組みになっています（公式ページで確認・2026-09-07）。用途「Docker実行環境」を選ぶとDockerとDocker Composeが自動でインストールされると公式に案内されており、リポジトリを追加したりパッケージを1つずつ入れたりする作業は基本的に不要です。

公開まで含めて考えるなら、アプリのポートをそのままインターネットに出さず、リバースプロキシ（外部からの通信を一度受け止め、内部の適切なコンテナへ振り分ける仕組み）を前段に置いて自動HTTPSにする構成が最短です。ローカルでこの構成を組んで確認したところ、サービス名を指定するだけで裏側のコンテナに届き、ドメイン名ベースでHTTPS証明書が自動発行される流れが成立しました。

向く人: n8nやDify、Ollamaなど1〜2個のDockerサービスを常時稼働させたい個人開発者・副業エンジニア。向かない人: すでにKubernetesなど別の基盤を使っている人です。

プラン選びの目安も実測で見えています。n8nを1GBプランで起動すると、起動直後にメモリ使用量が一時的に63.92%（654.5MiB/1GiB）まで跳ね上がりました。ワークフロー実行時の余裕を考えると、2GB以上を選ぶのが無難です。

最初の5分でやること: 申し込み画面で用途「Docker実行環境」を選び、プランは2GB以上を選択します。

さくらのVPSでDockerを動かす3つの道

Dockerを入れる方法は3つあります。

経路	自動で入るもの	対応OS（確認できた範囲）	こんな人向け
用途「Docker実行環境」	Docker＋Docker Compose(v2)	Ubuntu 24.04（他OSの提供有無は未確認）	とにかく最短で始めたい人
スタートアップスクリプト「Docker Compose」	Docker＋Docker Compose(v2)	Ubuntu 22.04/24.04、Debian 11/12（2025年11月26日に追加）	用途の組み合わせにない構成でOSを選びたい人
手動インストール（apt公式手順）	選んだパッケージのみ	Ubuntu/Debianなどapt系全般	バージョンや構成を自分で管理したい人

手動インストールは、Docker公式のaptリポジトリを登録したうえでdocker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginの5パッケージを入れる手順です（公式ドキュメントで確認）。GPG鍵の登録やリポジトリ追加など複数のコマンドを順番に実行する必要があり、用途選択やスタートアップスクリプトに比べると手間がかかります。

ここで注意が必要なのは、docker-compose-pluginが提供するのはdocker compose（スペース区切り）であって、docker-compose（ハイフン区切り）ではないという点です。ハイフン版（Compose V1）は現在保守されておらず、公式もスペース版（Compose V2）への移行を案内しています。古い手順を参考にする場合は読み替えが必要です。

最短手順：サーバー追加からHTTPS公開・再起動テストまで

1. 申し込み画面で用途「Docker実行環境」を選んでサーバーを追加する（プランは前述の目安で選択）
2. 起動後にSSHでログインし、docker --versionとdocker compose versionで導入を確認する
3. 動作確認用のcompose.yamlを置いてdocker compose up -dを実行する
4. コントロールパネル（コンパネ）のパケットフィルタで公開に必要なポート（80/443など）を開ける
5. DNSのAレコードをVPSのIPアドレスへ向ける
6. リバースプロキシ入りのcompose構成に差し替えてHTTPS公開する
7. restart: unless-stopped（またはalways）を設定し、実際にサーバーを再起動して復旧を確認する

動作確認用の最小構成はこれだけです。

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    restart: unless-stopped

同じ形の構成をローカルで起動して確認したところ、docker compose up -dの実行からHTTP 200の応答まで数秒で完了しました。

公開時はアプリのポートを直接開けず、リバースプロキシを前段に置きます。

services:
  proxy:
    image: caddy:2-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
    restart: unless-stopped
  backend:
    image: nginx:alpine
    restart: unless-stopped

# Caddyfile
app.example.com {
    reverse_proxy backend:80
}

Caddyはドメイン名を書くだけで証明書の発行と更新を自動化する仕組みを持っています。ローカルでは内部CA（自己署名相当）を使って確認しましたが、backendというサービス名だけで裏側のコンテナに届き、ドメイン名ベースでHTTPS終端が成立することは確認できました。公開ドメインでの実際の証明書発行は、インターネットから到達できるVPSとDNS設定が前提になるため未確認です。仕組み自体は公式ドキュメントに記載された標準機能なので、DNSをVPSに向ければそのまま使えます。

再起動テストのやり方には注意点があります。詳しくは次の「つまずき」で説明します。

OSにRocky Linuxなど別系統を選ぶ場合は、初期ログインユーザーがrootではなく専用ユーザー（rocky）になる仕様があります。公式マニュアルでログイン方法を確認してから作業してください。

AIツール（n8n / Dify / Ollama）を載せるならどのプランか

コンテナの実際のメモリ使用量を計測しました。

プラン（月額・石狩）	メモリ	n8n（1個起動）	Ollama 0.5Bモデル	Ollama 1.5Bモデル
512MB（643円）	512MB	起動時にクラッシュ	484MB前後で起動はできるが余裕なし	非対応
1GB（880円）	1GB	起動可・起動直後は654MB前後（63.92%）	508MB前後・余裕あり	非対応
2GB（1,738円）	2GB	余裕あり	余裕あり	1.35GB前後（67.40%）
4GB（3,520円）	4GB	複数サービスの同時運用に向く	余裕あり	余裕あり

n8n（公式イメージ・デフォルト設定）は512MBプランでは起動時点でクラッシュしました。ログにはJavaScriptのヒープ（メモリ領域）不足によるエラーが出ており、Node.jsの初期化自体が失敗する形です。1GBプランなら起動できますが、常時稼働の余裕を考えると2GB以上が安心です。

Ollamaは、使用済みモデルを一定時間メモリに保持し続ける仕組み（keep-alive）を持っています。0.5Bモデルと1.5Bモデルを続けて使うと、切り替え直後は両方がメモリに残り、2GBプラン上限の88.7〜89.0%まで積み上がりました。複数の小型モデルを切り替えて使う運用なら4GB以上を検討してください。

Difyのメモリ使用量は今回のセッションでは計測していません。DifyをVPSにセルフホストする費用の分岐点で詳しく扱っているので、そちらを参照してください。

デプロイのやり方3通りを比較

VPSへの反映方法は主に3通りです。

• VPS上でbuild: git pullしてからdocker compose up -d --buildをVPS上で実行する最小構成
• レジストリ経由: ローカルやCIでビルドしたイメージをレジストリへpushし、VPS側はdocker compose pullだけで済ませる
• CIからSSH: CI上でビルドし、SSH経由でVPSにデプロイコマンドを実行させる

どの方法を選ぶかは、ビルド時のメモリの挙動と関係します。実際に試したところ、興味深い結果が出ました。

コマンド	メモリ制限	結果
docker build --memory=512m（600MB使用処理）	512MB	成功・2.09秒
docker build --memory=512m（2000MB使用処理）	512MB	成功・68.81秒（データ量は3.3倍なのに約33倍遅い）
docker run --memory=256m（600MB使用処理）	256MB	メモリ不足による強制終了（OOMKilled）

docker run --memoryは今回の環境で確実にメモリ制限として機能し、超えると強制終了しました。一方docker build --memoryは同じ環境で制限を超えても失敗せず、極端に遅くなるだけでした。つまり「安いプランではビルドが落ちる」というより「気づかないうちに異常に遅くなる」方が実態に近いということです。さくらのVPS実機（Ubuntu上のネイティブなDocker Engine）で同じ挙動になるかは確認していません。

メモリに余裕がないプランでビルドを実行する予定なら、ローカルやCIでビルドしてレジストリ経由で配る方法の方が安全です。

運用：更新・ロールバック・バックアップの最小セット

• 更新: git pull && docker compose up -d --build
• ロールバック: 直前のイメージタグを残しておき、タグを指定してdocker compose up -dで戻す。またはgitのタグ・コミットを指定してcheckoutしてから再ビルドする
• バックアップ: 永続化データはnamed volume（Dockerがホスト側で確保・管理する保存領域）にまとめ、docker run --rm -v <volume>:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz -C /data .のような形でtar化する
• ディスクの掃除: 使わなくなったイメージやビルドキャッシュはdocker system dfで使用量を確認し、docker system pruneで定期的に片付ける

つまずきトップ3

1. パケットフィルタとOS側ファイアウォールの「二段構造」

さくらのVPSのパケットフィルタはステートレスに動作し、ICMPやフラグメント、NTP、外部通信の戻りパケット用ポート範囲は自動で許可され、それ以外は破棄されます。公式マニュアルには「OSのファイアウォール設定とパケットフィルターの動作が重複する可能性がある」「サーバー内でファイアウォール設定をしている場合はパケットフィルターを利用しないことを推奨」「スタートアップスクリプト利用時は、スクリプトが使用するポートによりパケットフィルターを併用できない可能性がある」と明記されています。compose.yamlのports設定はコンテナ側の話であり、それをインターネットから実際に通すかどうかはパケットフィルタとOS側ファイアウォールの両方が関わります。公開前に両方の設定を確認してください。

2. restart policyの確認方法を間違えると「効いていない」と誤解する

nginx:alpineを--restart=alwaysと--restart=noの2本で起動し、外部からdocker killで停止したところ、5秒後・25秒後のいずれもalways側は自動復旧せず、両方とも停止したままでした（RestartCount=0）。ところが、コンテナ内部からnginxのプロセスだけを終了させたところ、always側は5秒後に自動的に再起動し（Up 13 seconds、RestartCount=1）、no側は復旧しませんでした。

つまり「動いているコンテナをdocker stopやdocker killで止めてみて、勝手に立ち上がるか見る」という確認方法では、restartポリシーは正しく検証できません。外部からの意図的な停止・強制終了は復旧の対象にならないためです。実際に確かめたいなら、VPSそのものを再起動するか、コンテナ内部のプロセスが予期せず落ちる状況を再現する必要があります。

3. docker-compose（v1・ハイフン）とdocker compose（v2・スペース）の記法差

apt公式手順で入るのはdocker-compose-pluginで、これはdocker compose（スペース区切り）を提供するパッケージです。docker-compose（ハイフン区切り・V1）は現在保守されておらず、実際にdocker compose（スペース）でcompose.yamlを起動して疎通確認したところ正常に完了しました（HTTP 200）。古い手順で見かけるdocker-compose up -d（ハイフン）のコマンドは、さくらのVPSを含む現行のapt公式手順の環境ではそのままでは動かない可能性が高いです。

次の一歩

今日やるなら、無料トライアルで用途「Docker実行環境」を選び、上で紹介した動作確認用のcompose.yamlを1つ起動してHTTP応答を確認するところまでが現実的な最初の一歩です。ローカル環境では、compose.yamlを配置してからdocker compose up -dを実行し、応答を確認するまで数秒で完了しました。同じコマンドはさくらのVPS上でもそのまま使えます。

もっと詳しく

• プラン別の料金は年額払いと月額払いで実質単価が変わります。年額払いは総額を12で割った月額換算がおよそ91.7%になるため、長期利用が決まっているなら年額払いを検討してください。
• OSをRocky Linuxにする場合は、初期ログインユーザーがrootではなく専用ユーザー（rocky）になる仕様があります（公式マニュアル確認）。
• ストレージ変更オプションの手数料は本記事では確認できていません。申し込み前に公式ページで確認してください。

個別アプリの導入手順は別記事にまとめています。

• n8nをVPSにセルフホストする手順
• OllamaをVPSで動かすメモリ構築ガイド
• DifyをVPSにセルフホストする費用の分岐点
• n8n用VPSの比較（ConoHa・XServer・さくら）
• さくらのVPSクラウドとの比較（SLA・料金）