GhostlyIncホスティングレビューラボ
DigitalOcean App Platformレビュー2026：PaaS料金、スケーリング、制限、最適な利用例
DigitalOcean App Platformは、サーバーを運用せずにウェブアプリ、API、静的サイト、ワーカー、スケジュールジョブを提供したい場合に強力なマネージドPaaSです。ルートアクセス、永続ローカルストレージ、詳細なネットワーク制御、最安のVPS料金が必要な場合は魅力が減ります。
簡単な判定
サーバー制御よりデプロイ速度を重視する場合にApp Platformは最適です
チームがGit連携デプロイ、管理されたビルド、HTTPS、ルーティング、ログ、スケーリング制御、DigitalOceanデータベース統合を一元管理したい場合はApp Platformを選択してください。SSH、カスタムネットワーク、ステートフルディスク、未対応のシステムパッケージ、特定のランタイム調整が必要な場合はDropletやKubernetes、他のクラウドを選びましょう。
購入者の概要
DigitalOcean App Platformの利点、制限、推奨ユーザー
購入のポイントはApp Platformがアプリをデプロイできるかではなく、ストレージ、シェルアクセス、ネットワーク、ランタイム制御の制約を受け入れてまでマネージドプラットフォームを望むかです。
App Platformが最も強みを発揮する場面
- Gitまたはコンテナイメージから公開本番URLへの高速パス
- 静的サイト、ウェブサービス、ワーカー、スケジュールジョブ、多コンポーネントアプリをサポート
- 自動HTTPS、カスタムドメイン、ロールバック、ログ、メトリクス、アラート、ヘルスチェックが日常運用の負担を軽減します
- BuildpacksはNode.js、Python、Go、PHP、Ruby、Rust、.NETなど一般的なスタックをカバーし、Dockerfileは多くのカスタムケースに対応します。
- リクエストベース自動スケーリングは、旧来のApp Platformレビューよりもトラフィック駆動サービスの調整を容易にします。
- DigitalOceanのマネージドデータベース、Spaces、コンテナレジストリ、OpenSearch、Kafka、VPCネットワークを既に使っている場合に適したエコシステムです。
他のホストが適している場合
- コンテナへのSSHやSFTPアクセスがなく、VPSに比べて深いデバッグは制限されます
- 永続ボリュームなし；ローカルファイルシステムのデータは一時的とみなすべきです
- 最安の共有CPUサイズは、ワーカー、ジョブ、データベース、転送、IPを含めると本番の全コストではありません。
- ビルドタイムアウト、Linux AMD64イメージ要件、SMTP制限、直接IPv6サービス接続なしなど、見落としやすい制限があります。
- CPUベースの自動スケーリングは専用CPUプランが必要で、CPU負荷の高いアプリのコスト計算に影響します。
- 特殊なランタイム、ネイティブ依存、カスタムデーモン、低レベルネットワークではDropletsやKubernetesより柔軟性が低いです。
目次
現在の製品イメージ
DigitalOcean App Platformが現在提供するもの
App PlatformはDigitalOceanのマネージドアプリケーション層で、Gitリポジトリからのビルド、コンテナイメージからのデプロイ、静的サイト、ウェブサービス、ワーカー、ジョブの実行、管理データベースやSpaces、OpenSearch、Kafka、VPCネットワークなど他のDigitalOceanサービスとの連携が可能です。
サービスとAPI
GitやコンテナレジストリからデプロイすべきNode.js、Python、Go、PHP、Ruby、Docker、その他HTTPサービスにApp Platformを使いましょう。
静的サイトとSPA
静的コンポーネントはマーケティングサイト、ドキュメント、ダッシュボード、フロントエンドアプリに有用で、DigitalOceanのCDN経由で配信可能なファイルにビルドできます。
ワーカーとジョブ
ワーカーはキュー消費者やバックグラウンド処理を担当し、ジョブはデプロイ時タスクやスケジュールされたcron形式の作業をHTTPルートを公開せずに処理します。
管理された連携
マネージドデータベース、オブジェクトストレージ、プライベートネットワーク、ログ転送、アラート、コンテナレジストリワークフローを追加すると価値が高まります。
ユースケース適合
App Platformが適切なホスティング選択となる場合
サーバー設定、パッチ適用、デプロイスクリプト、SSL、ロールバック、ログ、スケーリング作業を考慮すると、マネージドPaaSはVPSより安価になることがあります。ただし、低レベルの制御が必要な場合は高コストや制約が生じることもあります。移行前にこの表を参考にしてください。
| ワークロード | 適合 | 理由 |
|---|---|---|
| 小規模SaaSアプリ、API、社内ダッシュボード | 強い適合 | Linux、Nginx、プロセスマネージャー、SSL更新の管理なしにデプロイ、HTTPS、ログ、ロールバック、スケーリング制御が利用できます。 |
| 小規模API付き静的サイト | 適している | フロントエンドは静的コンポーネントとしてシンプルに保ち、APIはサービスとして実行しますが、転送量とサービス料金は無料とは限らないので確認してください。 |
| キューワーカーとウェブアプリ | 適している | ワーカーは一級アプリコンポーネントで、ウェブとバックグラウンドの負荷が1つのアプリ仕様と環境モデルを共有できます。 |
| DigitalOcean上のデータベース連携アプリ | 強い適合 | マネージドPostgreSQL、MySQL、MongoDB、Valkey、OpenSearch、Kafka、VPC機能は連携作業を軽減します。 |
| 永続的なローカルアップロードが必要なアプリ | 不向き | Spaces、マネージドデータベース、または他のプラットフォームを使いましょう。App Platformのローカルファイルシステムは一時的でボリュームシステムではありません。 |
| ルートデバッグ可能なカスタムサーバースタック | DropletsまたはKubernetesを使う | 通常の作業でSSH、SFTP、パッケージインストール、カスタムデーモン、システムログが必要なら、App Platformは制約を感じるでしょう。 |
料金の実態
DigitalOcean App Platformの料金は明確ですが、総額は構成要素によって変わります。
現在の料金モデルは、選択したコンテナサイズと稼働コンテナ数に基づき秒単位課金と最低料金があります。静的サイト専用アプリは小規模なら安価または無料ですが、本番アプリはウェブサービス、ワーカー、データベース、転送、可観測性、専用出口IPを含むことが多いです。
共有CPUは低価格から開始
現在のドキュメントでは、月額5ドルからの小規模共有CPUアプリサービスサイズが記載されています。これはシンプルなアプリの入り口として有用ですが、スケーリング、RAM、転送、追加コンポーネントが実際の請求額を左右します。
無料プランは制限が多い場合があります
DigitalOceanは現在、静的サイト専用アプリを最大3つまで小規模なアウトバウンドデータ許容量で許可しています。これはランディングページ向けの階層と考え、トラフィック用の無料本番プラットフォームとは見なさないでください。
専用CPUがコスト計算を変える
CPUベースの自動スケーリングは専用CPUプランが必要で、リクエストベースの自動スケーリングは共有・専用CPUプランの対象サービスで動作します。コストと応答性の両方を検証してください。
転送量、データベース、IPが重要
許容量超過のアウトバウンド転送、開発用データベース、マネージドデータベース、専用出口IPは別予算項目です。計算リソースだけでなくアプリ全体の構成を比較してください。
展開ワークフロー
最適なApp Platform設定は最初のデプロイ前から始まります
App Platformはデモリポジトリでは非常に簡単に感じますが、実際のアプリでは環境変数の範囲設定、ビルドコマンド、ヘルスチェック、マイグレーションジョブ、ログアクセス、ロールバック動作、ステージングから本番への明確な流れなど、より厳密な管理が必要です。
Gitかコンテナイメージを慎重に選択
GitHub、GitLab、Bitbucket、パブリックGit、DOCR、Docker Hub、GitHub Container Registryは便利な選択肢です。リリースプロセスで安全に繰り返せるものを選びましょう。
ランタイムバージョンを固定する
プラットフォームが検出するランタイムに依存せず、スタックで許可される場合はNode、Python、Go、PHP、Ruby、.NET、Dockerのベースバージョンを固定してください。
ビルドと実行時の変数を分ける
シークレット環境変数は慎重に使い、ビルド時、実行時、または両方で必要か判断してください。本番シークレットがプレビューに漏れないように注意しましょう。
マイグレーションを明示的に行う
適切な場合はマイグレーションやデプロイ後タスクにデプロイ時ジョブを使いましょう。起動ごとに静かにマイグレーションを実行するウェブサービスは理解しづらいです。
本格的なヘルスチェックを追加する
ヘルスチェックは、アプリがトラフィックを処理し重要な依存先に到達できることを示すべきで、半端な起動状態での静的なOK応答だけでは不十分です。
ロールバック手順を練習する
App Platformは最近の成功したデプロイをロールバックできますが、データベースのマイグレーションやキュー、外部連携は別途ロールバック戦略が必要です。
スケーリング
スケーリングは有効ですが、アプリに合わせて調整が必要です
App Platformはコンテナサイズ変更による垂直スケーリングと、コンテナ数変更による水平スケーリングをサポートします。CPUベースの自動スケーリングは専用CPUプランに紐づき、リクエストベースの自動スケーリングは共有・専用CPUプランの対象サービスで動作します。これにより、従来のレビューより柔軟なスケーリングが可能です。
| スケーリングの疑問 | テスト項目 | 重要な理由 |
|---|---|---|
| 垂直スケーリング | 本番に近い負荷でコンテナサイズを切り替える | メモリ制約や起動負荷が高いアプリでは、小さな複数のレプリカより大きなコンテナの方がコスト効率が良く安定する場合があります。 |
| 水平スケーリング | 最小・最大コンテナ数を増やす | 高可用性には2つ以上のコンテナも重要です。1つのコンテナは安価でも、実際は1つのランタイムインスタンスです。 |
| CPU自動スケーリング | CPUがボトルネックなら専用CPUプランでテストする | CPUはリクエスト圧力やキュー遅延と必ずしも一致しないため、実負荷から閾値を調整してください。 |
| リクエストベース自動スケーリング | HTTPサービスにはリクエスト毎秒またはP95レイテンシ目標を使う | これはCPU単体よりもウェブアプリに有用ですが、現実的なトラフィックとヘルスチェックが必要です。 |
| ゼロスケール | レイテンシ非敏感サービスのみで使用 | アイドルコストを削減できますが、コールドスタートや初回リクエストの挙動がユーザーや内部ワークフローで許容できる必要があります。 |
重要な制限
本番前に理解すべきApp Platformの制限
多くのApp Platformの不満は、通常のVPSのように振る舞うと誤解していることに起因します。そうではありません。境界のあるマネージドランタイムとして扱い、その境界が作業を減らすか阻害するかを判断してください。
| 制限 | 実務的影響 | より良いプラン |
|---|---|---|
| ローカルファイルシステム | 一時的利用のみ、小さなファイルシステム制限あり | アップロード、アセット、永続的な状態はSpaces、マネージドデータベース、または他の永続サービスに保存してください。 |
| SSHやSFTPなし | 通常のサーバーのようにコンテナをデバッグできません | ログ、メトリクス、ヘルスチェック、ローカル再現、コンテナイメージ管理に投資しましょう。 |
| ビルド制限 | ビルドにはCPU、メモリ、ディスク、タイムアウトの制限があります。 | 大規模モノレポや重いビルドは、完成イメージをプッシュする外部CIが必要な場合があります。 |
| コンテナアーキテクチャ | Linux AMD64イメージがサポート対象です | デプロイ前に適切なアーキテクチャ向けにイメージをビルド・テストしてください。 |
| ネットワーキング | 直接のIPv6サービス接続なし、SMTPポートも利用不可 | 生のSMTPではなくIPv4対応の依存関係とトランザクションメールプロバイダーAPIを使いましょう。 |
| コンプライアンス | すべての規制対象ワークロードに適合するわけではありません | 厳格なフィンテック、PCI、カスタムネットワーク、監査要件には、Droplets、Kubernetes、またはより広範なクラウドプラットフォームを比較してください。 |
運用
多くのチームにとって十分なセキュリティと可観測性ですが、万能ではありません
App Platformは自動HTTPS、デプロイ履歴、ログ、ヘルスチェック、アラート、メトリクス、プライベート接続オプション、暗号化環境変数などの基本機能を提供します。アプリのセキュリティ、シークレット管理、データベース権限、ヘッダー、バックアップ、インシデント対応は利用者の責任です。
良好なプラットフォーム基盤
自動HTTPS、DDoS対策、自動OSパッチ適用、環境変数、VPCオプション、専用出口IPが多くの一般的なセキュリティ要件を満たします。
ログとインサイトは有用です
App Platformのログ、インサイト、アラート、ヘルスチェック、ログ転送を早期に活用しましょう。SSHベースのデバッグの代替になります。
データベースは別途プランが必要です
開発用データベースは便利ですが、本番環境ではバックアップ、スケーリング、メンテナンス時間、アクセス制御を考慮したマネージドデータベースを使うべきです。
アプリのセキュリティは利用者の責任です
App PlatformはHTTPSを提供しますが、アプリケーションのヘッダー、認証、レート制限、入力検証、シークレットのローテーション、依存関係のパッチ適用は利用者の責任です。
代替案一覧
DigitalOcean App PlatformとDroplets、Render、Fly.io、Vercelの比較
避けたいことによって最適な代替は異なります。運用負荷を減らしたいならマネージドプラットフォームを、コスト削減と完全制御を望むならVPSやKubernetesを比較してください。
| 代替案 | 代わりに選ぶべき場合 | App Platformを使い続けるべき場合 |
|---|---|---|
| DigitalOcean Droplets | ルートアクセス、SSH、SFTP、カスタムサービス、永続ディスク、最安の常時稼働コンピュート価格が必要です。 | 管理されたデプロイ、HTTPS、ログ、スケーリング、サーバーメンテナンス軽減のために一部の制御を犠牲にしてもよい場合。 |
| DigitalOcean Kubernetes | Kubernetesのプリミティブ、カスタムネットワーク、サービスメッシュ、オペレーター、多サービスインフラパターンが必要です。 | よりシンプルなマネージドアプリランタイムを望み、Kubernetesの運用を避けたい場合。 |
| Render or Railway | 特定のアプリに対して開発者体験、アドオンモデル、料金体系、リージョン選択を好む場合。 | スタックが既にDigitalOcean上にあり、データベース、オブジェクトストレージ、ネットワーク、アプリデプロイを1つのアカウントで管理したい場合。 |
| Vercel or Netlify | アプリが主にフロントエンド、エッジ、コンテンツ、フレームワーク特化型で、そのエコシステムの恩恵を受ける場合。 | バックエンドサービス、ワーカー、ジョブ、DigitalOceanインフラを同じ運用モデルで扱う必要があります。 |
| Fly.io or Cloud Run | コンテナ優先のグローバル配置、エッジに近いリージョン、または異なる自動スケーリングとコンテナモデルが必要です。 | DigitalOcean内でより従来型のPaaSワークフローを望む場合。 |
GhostlyBridge
Dropletがより良いフォールバックとなる場合
App Platformはサーバー管理作業を省きますが、SSH、SFTP、永続ローカルディスク、ルートレベルのデバッグも使えません。これらが通常の作業に必要なら、DigitalOcean Dropletの方が適しており、GhostlyBridgeで日々のサーバー作業を一元管理できます。
App Platformを使う
標準的なウェブアプリ、API、ワーカー、スケジュールジョブのランタイムをプロバイダーに構築、デプロイ、ルーティング、スケーリング、パッチ適用させたい場合はApp Platformを選びましょう。
GhostlyBridgeとDropletsを使う
ルートアクセス、SSHベースのワークフロー、ファイル転送、カスタムサービス、永続ディスク、直接検査可能なサーバーが必要な場合はDropletsを選択してください。
調査メモ
本レビューで使用した最新のDigitalOcean情報源
これらのリンクは記事の最後に配置し読みやすさを優先していますが、上記の実用的な内容は現行のApp Platform製品ページとドキュメントに基づいています。移行前に料金と制限を必ず再確認してください。
最終評価
DigitalOcean App Platformは、ハイパースケールの複雑さなしでマネージドデプロイを望むチームにとって賢い中間選択です。
App Platformは小規模チーム、代理店、SaaSプロトタイプ、社内ツール、コンテンツアプリ、API、既にDigitalOceanのデータベースやオブジェクトストレージを使うアプリにおすすめです。生のVPSよりリポジトリから本番までの道のりが速く、AWSやKubernetesよりもクラウドの概念がシンプルです。
永続的なローカルストレージ、シェルレベルのデバッグ、カスタムカーネル、SMTP、IPv6専用依存、特殊なシステムパッケージ、非常にコストに敏感な常時稼働コンピュートが必要なアプリには避けるべきです。その場合はDroplet、マネージドKubernetes、または必要なランタイムに特化したプロバイダーから始めてください。
よくある質問
DigitalOcean App Platformは本番利用に適していますか？
はい、多くの標準的なウェブアプリ、API、静的サイト、ワーカー、スケジュールジョブに対応します。マネージドデプロイを望みプラットフォームの制限を受け入れるなら本番利用に適しています。SSH、永続ローカルストレージ、カスタムシステムサービス、低レベルネットワーク制御が必要な場合は不向きです。
App PlatformはDigitalOcean Dropletより安いですか？
必ずしもそうではありません。小規模なDropletは常時稼働コンピュートで安価な場合があり、特にLinux管理に慣れている場合です。App Platformはデプロイ設定、SSL、ログ、ロールバック、ヘルスチェック、スケーリングの手間とリスクを減らすことで実際には安くなることがあります。
App PlatformはDockerをサポートしていますか？
はい。Dockerfileや対応レジストリのコンテナイメージからデプロイ可能です。重いビルドはCIでイメージを作成し完成イメージをデプロイする方がプラットフォームのビルド制限を回避できます。
App Platformに永続ストレージはありますか？
App Platformコンテナには永続ボリュームがなく、ローカルファイルシステムは一時的で小さな一時ファイルのみ使用可能です。アップロードや状態管理にはSpaces、マネージドデータベース、他の永続ストレージを使いましょう。
App Platformは自動スケール可能ですか？
はい、重要な詳細があります。App Platformは手動スケーリングと自動スケーリングをサポートします。CPUベースの自動スケーリングは専用CPUプランが必要で、リクエストベースの自動スケーリングは共有・専用CPUプランの対象HTTPサービスコンポーネントで動作します。
App Platformは良いHeroku代替ですか？
特にDigitalOceanの料金体系が好みで、既にデータベース、Spaces、コンテナレジストリを使っている場合は適しています。Herokuは成熟したアドオンエコシステムがあり、最適な選択はスタック、サポート要件、利用中のDigitalOceanインフラ量によります。
App PlatformとKubernetes、どちらを使うべき？
マネージドアプリランタイムとシンプルなデプロイワークフローを望むならApp Platformを使い、Kubernetesネイティブの制御、サービスメッシュ、カスタムネットワーク、オペレーター、多数のインフラ調整が必要ならKubernetesを使いましょう。