SaaSをVPSにデプロイする ― 個人開発のための本番公開手順を一気通貫で

手元で動くアプリと，世界中からアクセスできる本番サービスの間には，大きな隔たりがある．その溝を越えるのがデプロイ(公開)だ．第13回で押さえた独自ドメインに，いよいよ実際のサービスを住まわせる．

個人開発者がつまずきやすいのが，まさにこの公開フェーズだ．『ローカルでは完璧に動くのに，本番で公開できない』── アプリは書けても，サーバーへの配置やインフラの設定で手が止まる人は本当に多い．

この記事は，開発を終え，独自ドメインも取得し，いよいよ公開に挑む個人開発者に向けて書いている．VPSの選び方から，初期セットアップ，アプリの配置，リバースプロキシ，プロセス管理，デプロイの自動化まで，本番公開の手順を一気通貫で解説する．

扱う範囲は，デプロイの全体像 → VPSの選び方 → 初期セットアップ → アプリの配置 → リバースプロキシ → プロセス管理 → 環境変数と設定 → デプロイの手順化 → 公開後の確認 → よくある失敗，だ．読み終えたとき，あなたは自分のSaaSを本番のVPSで安定稼働させる道筋を理解している．

なぜ「VPSへのデプロイ」を学ぶ価値があるのか

アプリを公開するだけなら，お任せ型のPaaSを使う手もある．だが第6回で見た通り，長く運用するマイクロSaaSでは，コストと自由度の面でVPSが非常に強い．月千円台で1台持てば，複数サービスを同居させ，すべてを自分で制御できる．

VPSへのデプロイは，最初こそ手間に感じるが，一度身につければどんなサービスにも応用できる普遍的なスキルになる．Linux，Webサーバー，プロセス管理，セキュリティ── これらの基礎は，個人開発者の市場価値そのものを高めてくれる．

そして，自分でデプロイを制御できることは安心につながる．トラブルが起きたとき，コストを最適化したいとき，特殊な構成が必要なとき── 自分の手でサーバーを操れることが，PaaSの『お任せ』では得られない対応力をもたらす．

本記事のメッセージは，『恐れずに，しかし定石に従って，一歩ずつ本番環境を作る』ことだ．デプロイは難しそうに見えるが，手順を分解すれば，個人でも確実に越えられる．あなたのサービスを，世界に公開しよう．

デプロイの全体像 ― 何をすれば公開できるのか

まず，本番公開の全体像を掴もう．大まかには，『VPSを借りる → 初期設定する → アプリとDBを配置する → Webサーバー(リバースプロキシ)を立てる → ドメインをつなぐ → HTTPS化する』という流れだ．一つずつ分解すれば，難しくない．

ここで大切なのは，各ステップを切り分けて，一つずつ確実に進めることだ．全部を一度にやろうとすると，どこで失敗したか分からなくなる．『この段階まではできた』を積み重ねれば，つまずいても原因を特定しやすい．

本記事では，このうちVPSの準備からアプリの稼働までを扱う．本番環境の堅牢な構築(第15回)，HTTPS化と独自ドメイン接続(第16回)，デプロイの自動化(第17回)は，それぞれ次回以降で深掘りする．まずは『アプリがVPS上で動いて，ブラウザから見える』状態を目指そう．

全体像を持っておくと，今自分がどの段階にいるか分かり，迷子にならない．『借りる→整える→載せる→つなぐ→守る』という大きな流れを頭に入れて，一歩ずつ進めていこう．

ローカルと本番の違いを意識する

手元(ローカル)で動くことと，本番で動くことは違う．本番では，別のマシン・別のOS・別の設定・公開ネットワークという環境になる．ローカルの『なんとなく動く』設定のままでは，本番でつまずきやすい．

第6回で触れた『環境を再現可能にする』が，ここで効いてくる．ローカルと本番の差をできるだけ小さくし，設定を明示的に管理しておくと，デプロイのトラブルが減る．コンテナ技術を使えば，環境ごと持ち運べる．

まず小さく公開して確かめる

いきなり完璧な本番構成を目指すより，まず『アプリが動いて見える』最小の状態を作るのがおすすめだ．第5回のMVPの発想と同じで，小さく動かして確かめながら，堅牢化していく．

最初の公開で全部を完璧にしようとすると，手が止まる．『とりあえず動いた』をまず作り，そこからHTTPS化やバックアップなどを足していく．段階的な前進が，確実な公開への近道だ．

VPSの選び方 ― 個人開発に合った1台

デプロイの第一歩は，VPSを借りることだ．VPS選びでは，スペック(CPU・メモリ・ストレージ)，価格，ストレージの速さ，信頼性，管理のしやすさを見る．個人開発のマイクロSaaSなら，最小〜小規模のプランから始めて十分だ．

とくに注目したいのがストレージの速さだ．高速なNVMe SSDを使ったVPSは，データベースの読み書きやアプリの応答が速く，ユーザー体験に直結する．第4回でも触れたが，表示の速さは成約率や信頼にも影響する．

また，OSテンプレートの豊富さや，管理画面の使いやすさも，個人開発では重要だ．よく使われるLinuxディストリビューションがすぐ選べ，再インストールやスナップショットが簡単にできると，試行錯誤しながら学ぶのに向いている．最初は小さく借り，必要になったらプランを上げればよい．

第6回でも述べた通り，1台のVPSに複数のサービスや環境を同居させられるのもVPSの強みだ．最初の1台を借りれば，本番アプリ・DB・検証環境までまとめて動かせ，収益に対するインフラ費を極小に抑えられる．まずは身軽に1台から始めよう．

スナップショットで「戻れる」状態に

多くのVPSには，サーバーの状態をまるごと保存するスナップショット機能がある．大きな変更の前にスナップショットを取っておけば，失敗しても元に戻せる．学びながら構築する個人開発では，この『戻れる』安心感が大きい．

第9回のバックアップとは別に，サーバー全体の状態を保存できるのは心強い．設定をいじって壊しても，スナップショットから復元すればやり直せる．恐れずに試行錯誤するための，強力な保険になる．

リージョン(設置場所)を選ぶ

VPSの設置場所(リージョン)は，主な利用者に近い場所を選ぶと応答が速くなる．日本向けサービスなら国内リージョンが基本だ．物理的な距離は通信の速さに影響するため，対象顧客に合わせて選びたい．

個人開発の初期は，あまり神経質にならなくてよいが，日本のユーザーを相手にするなら国内に置くのが素直だ．後述のHTTPSやCDN(第50回)と合わせて，表示速度を最適化していける．

初期セットアップ ― 安全な土台を作る

VPSを借りたら，まず安全に使うための初期設定を行う．借りたままの初期状態は，セキュリティ的に無防備なことが多い．アプリを載せる前に，土台を安全に整えることが重要だ．これを怠ると，公開した途端に攻撃を受ける．

最低限やるべきは，『OSを最新に更新する』『作業用の一般ユーザーを作る(rootで常用しない)』『SSHを鍵認証にする』『ファイアウォールで必要なポートだけ開ける』ことだ．これらは，第7回のセキュリティの考え方を，サーバーレベルで実践するものだ．

とくにSSHの鍵認証とファイアウォールは，公開サーバーの基本防御だ．パスワードログインを無効にして鍵だけにすれば，総当たり攻撃を大幅に防げる．ファイアウォールで，Web(80/443)とSSH以外を閉じておけば，攻撃の入口を最小化できる．

初期セットアップの例(イメージ)

# OSを最新化
sudo apt update && sudo apt upgrade -y
# 作業用ユーザーを作成し，sudo権限を付与
sudo adduser deploy
sudo usermod -aG sudo deploy
# ファイアウォールで必要なポートだけ開ける
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

これらの初期設定は，本番環境のセキュリティの土台であり，軽視できない．次回(第15回)で，この本番環境の構築をさらに詳しく掘り下げる．まずは『更新・一般ユーザー・SSH鍵・ファイアウォール』の4点を，アプリを載せる前に必ず済ませておこう．

rootで常用しない

サーバーの全権を持つrootユーザーで日常作業をするのは危険だ．作業用の一般ユーザーを作り，必要なときだけ管理者権限(sudo)を使うのが鉄則．これは第7回で触れた，アプリをrootで動かさないのと同じ発想だ．

万一の操作ミスや侵入があっても，一般ユーザーなら被害を限定できる．最小権限の原則は，アプリだけでなくサーバー運用でも基本になる．最初に作業用ユーザーを作る習慣をつけよう．

SSHの鍵認証を設定する

サーバーへのログインは，パスワードではなくSSH鍵認証にする．手元で鍵のペアを作り，公開鍵をサーバーに登録すれば，対応する秘密鍵を持つ自分だけがログインできる．パスワードログインは無効にしておく．

これにより，世界中から来る総当たりのパスワード攻撃を，根本から防げる．鍵認証は最初の設定こそ手間だが，一度設定すれば安全で快適だ．公開サーバーの基本中の基本として，必ず設定したい．

アプリの配置 ― コードをサーバーに載せる

土台が整ったら，いよいよアプリのコードをサーバーに配置する．最も一般的なのは，第6回で導入したGitを使う方法だ．コード管理サービス(GitHub等)からサーバーにコードを取得(clone/pull)すれば，確実かつ再現可能に配置できる．

手元のファイルを直接アップロードする方法もあるが，Git経由なら，バージョンが明確で，更新も『pullするだけ』で済む．第6回で『1人でもGit必須』と述べたのは，こうしたデプロイの土台にもなるからだ．コードはGitで管理し，サーバーへはGitで配る．

コードを配置したら，依存パッケージのインストール，データベースのマイグレーション(第9回)，必要なビルドを行い，アプリが起動できる状態にする．これらの手順は，後述する通りスクリプト化しておくと，毎回のデプロイが楽になる．

ここで，第7回で触れた秘密情報(DBパスワード，APIキー等)を，コードに含めず環境変数で渡すことが重要になる．本番の秘密情報は，コードとは別にサーバー上で安全に設定する．この分離が，安全なデプロイの基本だ(詳しくは後述)．

本番用のデータベースを用意する

アプリと合わせて，本番用のデータベースをVPS上に用意する(または第6回で触れたマネージドDBを使う)．第9回で設計したスキーマを，マイグレーションで本番DBに適用する．本番DBは，第9回の通りバックアップを必ず設定しておく．

ローカルのテストデータと本番データは厳格に分ける．本番DBには本物の顧客データが入るのだから，アクセス制限・バックアップ・安全な認証情報の管理を，最初から徹底しておきたい．

コンテナを使う選択肢

アプリと環境をコンテナ(Docker等)にまとめて配置する方法もある．環境ごと持ち運べるため，ローカルと本番の差をなくせ，デプロイが安定する．少し学習コストはあるが，再現性の高さは大きな魅力だ．

個人開発の初期は，コンテナを使わずに直接配置しても構わない．慣れてきたら，コンテナ化で環境の再現性とデプロイの楽さを得る，という段階的な導入でよい．まずは確実に動かすことを優先しよう．

リバースプロキシ ― 入口を1つにまとめる

アプリを起動できても，それをブラウザから適切に見せるには，Webサーバー(リバースプロキシ)が要る．リバースプロキシは，外部からのアクセスを受け取り，裏で動くアプリへ取り次ぐ『受付係』のような役割を果たす．

なぜ必要かというと，アプリを直接インターネットに晒すのは，安全でも効率的でもないからだ．リバースプロキシを前段に置くことで，HTTPS化(第16回)，複数アプリの振り分け，静的ファイルの効率配信，アクセス制御などをまとめて扱える．

代表的なリバースプロキシには，定番のものから，設定が簡単で自動HTTPS化してくれるものまで，いくつか選択肢がある．第6回で触れた『1台のVPSで複数サービスを同居』も，このリバースプロキシがドメインごとに振り分けることで実現する．1つの入口から，複数のサービスへ案内できるのだ．

リバースプロキシは，第16回のHTTPS化と密接に関わる．多くのリバースプロキシは，無料のSSL証明書を自動で取得・更新する機能を持ち，これを使えばHTTPS化が驚くほど簡単になる．リバースプロキシは，本番公開の中核となる部品だと覚えておこう．

ドメインとアプリを結びつける

リバースプロキシでは，『このドメイン(やサブドメイン)に来たら，このアプリへ取り次ぐ』という設定を行う．第13回で取得した独自ドメインのDNSをVPSに向け，リバースプロキシでドメインとアプリを結びつければ，独自ドメインでサービスが表示される．

これにより，第13回で設計したサブドメイン構成(app.〜，api.〜など)も実現できる．リバースプロキシが，ドメインという『住所』と，アプリという『住人』を，正しくつなぐ役割を担う．

静的ファイルは効率的に配信

画像やCSS・JSといった静的ファイルは，アプリ本体を経由せず，リバースプロキシから直接配信すると効率的だ．アプリの負荷が減り，表示も速くなる．多くのリバースプロキシは，これを簡単に設定できる．

細かな最適化は後からでよいが，リバースプロキシがこうした役割も担えることを知っておくと，表示速度の改善(第6回・第35回)に役立つ．入口を1つにまとめることの恩恵は，思いのほか大きい．

プロセス管理 ― アプリを動かし続ける

アプリを起動できても，『落ちたら自動で復帰する』『サーバー再起動後も自動で立ち上がる』仕組みがなければ，本番運用には耐えない．手動で起動したプロセスは，何かあれば止まったまま放置され，サービスが落ち続ける．

そこで使うのがプロセス管理の仕組みだ．Linuxの標準的なサービス管理機能や，言語ごとのプロセス管理ツールを使い，アプリを『サービス』として登録する．これにより，OSがアプリの起動・監視・自動復帰を肩代わりしてくれる．

重要なのは，『クラッシュからの自動復帰』と『サーバー起動時の自動起動』だ．アプリは必ずどこかで落ちる．落ちたまま放置されるか，秒で復帰するかは，このプロセス管理の設定次第．これがあって初めて，安心して眠れる本番運用になる．

プロセス管理は，アプリのログ収集とも関わる．アプリの出力するログを，きちんと記録・確認できるようにしておくと，トラブル時の原因究明が楽になる．これは第18回の監視にもつながる．まずは『落ちても自動で戻る』状態を確実に作ろう．

自動復帰と自動起動を設定する

プロセス管理では，『異常終了したら自動で再起動』『サーバー起動時に自動で立ち上がる』を設定する．これにより，一時的なクラッシュからは自動で立ち直り，サーバーの再起動後もサービスが勝手に復帰する．

ただし，起動直後に即クラッシュするバグがあると無限再起動に陥ることもあるので，再起動の間隔や回数の制限も設定しておくと安全だ．『落ちても戻るが，暴走はしない』バランスを目指そう．

ログを確認できるようにする

アプリが出力するログを，確認できる場所に集約しておく．エラーが起きたとき，ログがなければ原因が分からず，対処できない．プロセス管理の仕組みと連携して，ログを記録・閲覧できるようにしておこう．

ログは，トラブル対応の生命線だ．第18回の監視・アラートとあわせて，『何が起きているか分かる』状態を作っておくことが，安定運用の基盤になる．

環境変数と設定 ― 秘密情報を安全に渡す

第7回でも強調したが，本番の秘密情報(DBパスワード，APIキー，各種シークレット)を，コードに書き込んではいけない．コードに書くと，リポジトリ経由で漏洩する．これは個人開発で頻発する重大事故だ．

正しい方法は，秘密情報を環境変数や専用の設定ファイルとして，サーバー上に安全に置くことだ．アプリは，起動時にそれを読み込んで使う．これにより，コードと秘密情報が分離され，コードを公開しても秘密は漏れない．

本番とローカルで設定を切り替えられるようにしておくことも重要だ．『開発用の設定』と『本番用の設定』を分け，環境に応じて適切な方を読み込む．データベースの接続先や，外部サービスのキーが，環境ごとに正しく切り替わるようにする．第6回の『環境を明示的に管理する』が，ここで活きる．

秘密情報の管理は奥が深く，本シリーズ第39回でさらに掘り下げる．だが本番デプロイの段階では，まず『コードに秘密を書かない・環境変数で渡す・本番とローカルを分ける』という基本を，確実に守ることが最優先だ．

設定ファイルの権限に注意

秘密情報を含む設定ファイルは，そのファイルを読める人を限定(権限を絞る)する．サーバー上の他のユーザーやプロセスから読まれないようにする．第7回・第15回のセキュリティの考え方を，設定ファイルにも適用する．

せっかくコードから分離しても，ファイルの権限が緩ければ漏洩しうる．秘密情報は『コードからも，不要なアクセスからも』守る．地味だが，本番運用では欠かせない配慮だ．

デプロイの手順化 ― 毎回同じく，確実に

デプロイは一度きりではない．機能を追加するたびに，本番を更新するデプロイを何度も繰り返すことになる．そのたびに手作業で複数の手順を踏むと，手順を忘れたり，ミスしたりして，本番を壊しかねない．

そこで，デプロイの手順をスクリプト(またはドキュメント)としてまとめる．『コードを取得し，依存をインストールし，マイグレーションを実行し，アプリを再起動する』── この一連を，毎回同じように，確実に実行できるようにする．

これは，第17回で扱うCI/CD(自動デプロイ)の土台でもある．まずは手順を明文化・スクリプト化し，慣れてきたら『git pushしたら自動でデプロイされる』仕組みへ発展させる．最初は手動でも，『毎回同じ手順』を確立することが，安全なデプロイの第一歩だ．

手順化のもう一つの利点は，『何をしているか記録に残る』ことだ．第6回・第9回で繰り返した『再現可能にする』が，デプロイでも効く．手順が残っていれば，サーバー移行や再構築のときも，迷わず再現できる．

デプロイ前にバックアップを取る

本番を更新するデプロイの前には，必ずデータベースのバックアップを取る(第9回)．とくにマイグレーションを伴うデプロイは，万一失敗するとデータに影響しうる．『デプロイ前にバックアップ』を，手順の最初に組み込んでおこう．

バックアップがあれば，デプロイに失敗しても元に戻せる．この安心感が，思い切った改善を可能にする．デプロイとバックアップは，常にセットで考えたい．

ダウンタイムを最小にする工夫

デプロイ中に一時的にサービスが止まる(ダウンタイム)のを，できるだけ短くしたい．更新作業を素早く済ませ，再起動の瞬間だけに止める時間を絞る工夫をする．利用者が少ない時間帯を選ぶのも一つの手だ．

より高度には，無停止デプロイの手法もあるが，個人開発の初期はそこまで作り込まなくてよい．まずは『短時間で確実に』を目指し，必要になったら第17回の自動化とあわせて洗練させていこう．

公開後の確認 ― 本当に動いているか

デプロイが完了したら，本当に正しく動いているかを確認する．『デプロイした＝動いている』とは限らない．ローカルでは動いても，本番環境特有の問題で動かないことは珍しくない．公開後の確認は必須の工程だ．

確認すべきは，『独自ドメインでアクセスできるか』『主要な機能が動くか』『登録・ログイン・課金の一連が通るか』『メールが届くか』などだ．これまでの章で実装した認証・課金・メールが，本番でも正しく機能するかを，実際に操作して確かめる．

とくに，本番環境でしか起きない問題に注意したい．環境変数の設定漏れ，本番DBの接続，ドメインやHTTPSの設定，メールの到達── これらは本番で初めて顕在化することが多い．一通りの操作を，自分で実際に試してから，ユーザーに案内しよう．

公開後の継続的な確認は，第18回の監視につながる．『落ちたら気づける』『エラーを検知できる』仕組みを整えることで，公開後も安心して運用できる．まずは公開直後に，自分の目で一通り動作を確認することが，最初の関門になる．

本番の全シナリオを通しで試す

公開後，新規登録から，ログイン，主要機能の利用，課金，解約までの一連を，実際に通しで試す．これまで各章で『公開前に試す』と述べてきたことを，本番環境で総合的に確認するイメージだ．

とくに，お金が絡む課金(第10回)と，認証・メール(第7・11回)は，本番でこそ慎重に確認したい．テスト環境では動いても，本番のキーや設定で動かないことがある．実際に動かして，初めて公開は完了する．

デプロイでやりがちな失敗

最後に，個人開発のデプロイでありがちな失敗を確認しよう．いずれも，公開でつまずいたり，セキュリティや安定性を損なったりするものだ．

• 初期セキュリティ設定を飛ばす：公開した途端に攻撃を受ける
• 秘密情報をコードに含める：リポジトリ経由で漏洩する
• プロセス管理をしない：落ちたら止まったまま・再起動で消える
• デプロイ前にバックアップしない：失敗時にデータを失う
• 公開後に動作確認しない：本番特有の不具合に気づけない

共通する教訓は，『定石に従って土台を安全に整え，手順化して確実にデプロイし，公開後に必ず確認する』ことだ．デプロイは難しそうに見えるが，一歩ずつ分解すれば個人でも越えられる．恐れず，しかし丁寧に，あなたのサービスを世界に公開しよう．

一度経験すれば次は速い

最初のデプロイは，調べながらで時間がかかるかもしれない．だが，一度やり遂げれば，その手順はあなたの資産になる．次のサービスでは，同じ手順をなぞるだけで，はるかに速く公開できる．

VPSへのデプロイスキルは，個人開発者にとって一生モノの武器だ．最初の一回を乗り越えれば，『公開できない』という最大の壁を，あなたは越えたことになる．自信を持って，次のステップへ進もう．

補論 ― 公開の土台は「自分で制御できるVPS」で

本記事で見てきた通り，SaaSの公開は，自分でコントロールできる本番環境があって初めて成り立つ．アプリの配置，リバースプロキシ，プロセス管理，セキュリティ── これらをすべて自分の手で整えられることが，個人開発の対応力と安心につながる．

その土台となるのが，高性能で自由度の高いVPSだ．高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような高速NVMeのVPSなら，アプリもデータベースもリバースプロキシも1台で安定して動かせ，月千円台で本格的な本番環境を持てる．豊富なOSテンプレートとスナップショット機能で，学びながら試行錯誤するのにも向いている．そして，その本番環境につなぐサービスの顔となる独自ドメインは，第13回で触れた通り取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で取得しておこう．独自ドメイン＋自分で制御できるVPSという組み合わせが，プロフェッショナルな公開体制を作る．

『定石に従って安全な土台を作り，自分の手で確実にデプロイする』── これが個人開発の公開の正解だ．アプリがVPS上で動き始めたら，次はその本番環境をさらに堅牢にする番だ．次回は『本番環境の構築』を，アプリ・DB・リバースプロキシを安全に立てる観点から深掘りする．

よくある質問(FAQ)

Q1．PaaSではなくVPSにデプロイする利点は？

長く運用するマイクロSaaSでは，コストと自由度でVPSが強いです．月千円台で1台持てば複数サービスを同居でき，すべてを自分で制御できます．さらにVPSへのデプロイスキルは，Linux・Webサーバー・セキュリティなど普遍的な資産になり，トラブル対応やコスト最適化の対応力ももたらします．

Q2．VPSはどう選べばいいですか？

個人開発のマイクロSaaSなら，最小〜小規模プランから始めて十分です．メモリ（アプリ＋DBが動くか），ストレージの速さ（NVMe等だと体験が良い），価格，管理機能（再構築・スナップショット）を見ます．1台に複数サービスを同居できるのも強み．日本向けなら国内リージョンを選びましょう．

Q3．デプロイ前にまず何をすべきですか？

初期セキュリティ設定です．『OSを最新化』『作業用の一般ユーザーを作りrootで常用しない』『SSHを鍵認証にしパスワードログインを無効化』『ファイアウォールでWebとSSH以外を閉じる』の4点を，アプリを載せる前に必ず済ませてください．これを飛ばすと公開した途端に攻撃を受けます．

Q4．アプリのコードはどうサーバーに載せる？

第6回で導入したGitを使い，コード管理サービスからサーバーに取得（clone/pull）するのが一般的で，バージョンが明確で更新もpullだけで済みます．配置後，依存インストール・マイグレーション・ビルドを行います．秘密情報はコードに含めず環境変数で渡してください．コンテナ（Docker）でまとめて配置する方法もあります．

Q5．リバースプロキシは何のために必要ですか？

外部アクセスを受け取り裏のアプリへ取り次ぐ『受付係』です．アプリを直接インターネットに晒すのは安全でも効率的でもありません．リバースプロキシを前段に置くことで，HTTPS化（第16回），複数アプリの振り分け，静的ファイルの効率配信，独自ドメインとの結びつけをまとめて扱えます．1台で複数サービスを同居させる要にもなります．

Q6．アプリを動かし続けるにはどうすれば？

プロセス管理の仕組み（Linux標準のサービス管理や言語ごとのツール）でアプリを『サービス』として登録します．これで『異常終了したら自動再起動』『サーバー起動時に自動起動』が実現し，落ちても自動復帰します．手動起動では落ちたまま放置されるので，本番運用には必須です．再起動の回数制限で暴走も防ぎましょう．

Q7．本番の秘密情報（パスワード等）はどう扱う？

絶対にコードに書かず，環境変数や専用の設定ファイルとしてサーバー上に安全に置き，アプリが起動時に読み込みます．コードに書くとリポジトリ経由で漏洩します（個人開発で頻発する重大事故）．本番用とローカル用の設定を分け，設定ファイルは読める人を限定（権限を絞る）してください．詳細は第39回も参照を．

Q8．デプロイのたびに手作業なのが不安です

デプロイ手順をスクリプト（またはドキュメント）化し，毎回同じく確実に実行できるようにします．これは第17回のCI/CD（自動デプロイ）の土台です．デプロイ前には必ずバックアップ（第9回）を取り，公開後は必ず動作確認を．慣れたら『git pushで自動デプロイ』へ発展させましょう．

まとめ ― 一歩ずつ，確実に世界へ公開する

手元で動くアプリを，世界からアクセスできる本番サービスにするのがデプロイだ．難しそうに見えるが，『借りる→整える→載せる→つなぐ→守る』と分解すれば，個人でも確実に越えられる．

鍵は，『初期セキュリティを固める』『Gitでコードを配置』『リバースプロキシで入口をまとめる』『プロセス管理で動かし続ける』『秘密情報は環境変数で』『手順化して確実にデプロイ』『公開後に必ず確認』ことだ．

VPSへのデプロイスキルは，一度身につければ一生モノの武器になる．最初の一回は時間がかかっても，それを乗り越えれば『公開できない』という個人開発最大の壁を越えたことになる．恐れず，しかし定石に従って進もう．

アプリがVPS上で動き始めたら，次はその本番環境をさらに堅牢にする番だ．次回は，アプリ・DB・リバースプロキシを安全に立てる『本番環境の構築』を，セキュリティと安定性の観点から深掘りする．