Redmine運用に強いおすすめVPS｜コスパ・安定性・拡張性で比較

Redmineは、課題管理・進捗・履歴を一元化できる便利なOSSです。
ただし「自前で運用する」と決めた瞬間、サーバー選びが“成果”を左右します。

「Redmineを立ち上げたいけど、どのVPSを選べばいいの？」
「料金が安いだけで選んで、遅い／落ちる／復旧できないってならない？」
「テンプレやDockerで“簡単”って聞くけど、結局どこまで楽なの？」
「人数が増えたら、メモリやストレージはどれくらい必要？」
「バックアップやスナップショットって、どこまでやれば安心？」
「社内利用だからこそ、セキュリティ（IP制限や権限設計）も不安…」

こうした悩みは、Redmineが“動くか”よりも、止めずに運用できるかに直結します。
特にVPSは自由度が高い反面、更新・障害対応・セキュリティの責任が利用者側に寄るため、最初の選定ミスが後から効いてきます。

この記事では、Redmine運用で後悔しないために、VPSを コスパ・安定性・拡張性の3軸で整理して比較します。

• 料金は「月額」だけでなく、初期費用・日割り・長期割引まで含めて判断
• “運用の楽さ”は、テンプレ／Docker／手動の違いを分解して評価
• 公式情報（料金・スペック・提供機能）を優先し、比較の根拠が追える形でまとめる

「どれが一番か」ではなく、あなたの使い方に合う最適解が見つかるように、選び方から導入・運用の要点まで一気通貫で解説していきます。

おすすめ比較のセクションへはこちらからジャンプできます。

まず結論：目的別の最適解（迷ったときの指針）

Redmineを「レンタルサーバーで動かす」なら、基本は VPS（管理者権限あり） か Redmineのクラウド型（運用を任せる） の二択です。
共用サーバーは、Rails＋DB＋常時稼働の都合でつまずきやすいので、初心者ほど最初からVPS寄りで考えるのが安全です。

初心者でも迷いにくいバランス重視の選び方

迷ったら、次の“失敗しにくい基準”で選ぶとブレません。

• プラン変更が簡単（後からCPU/メモリ増強できる）
• バックアップ手段が確保しやすい（スナップショット、世代管理など）
• 課金体系が分かりやすい（試用→本番移行でコストが読みやすい）
• 情報量が多い（公式ドキュメント・利用者が多いほど詰まりにくい）

初心者向けの“まずの目安”としては、検証なら小さめでも動きますが、実運用なら メモリ2GB以上 を起点にして、重くなったら増強できるサービスが安心です。

候補の置き方（例）

• 短期の検証〜小規模運用まで幅広く：ConoHa VPS（通常料金＋時間課金の切替がある）
• 料金表が明確で堅実に運用：さくらのVPS（プランが細かく、段階的に上げやすい）
• “使った分だけ”寄りで試しやすい：KAGOYA CLOUD VPS（日額計算・上限あり、推奨プラン提示）

とにかく短時間で立ち上げたい場合の考え方（テンプレ活用）

「すぐ使いたい」なら、ゼロから手動インストールよりも、次の順で検討すると早いです。

1. スタートアップスクリプト（自動でセットアップしてくれる）
2. アプリ（テンプレ）イメージ（OS再構築時に選ぶだけ）
3. Docker構成（compose等）（再現性は高いが、最初の理解が必要）

注意点として、テンプレは“いつも同じ”ではありません。たとえば ConoHa は アプリケーションテンプレートのRedmine新規提供を終了し、代替として スタートアップスクリプトの利用を案内しています（既存利用は継続可だが再構築時に選べない点に注意）。

同じく、KAGOYAはRedmine向けページでテンプレ導入の流れを示しつつ、Bitnami Redmine の公開を一時停止している旨も明記しています。

テンプレ/自動化を使う前提で“最低限これだけ”は最初にやってください👇

• 管理者パスワードの変更（初期情報の扱い注意）
• HTTPS化（証明書）
• メール送信設定（通知が生命線）
• DBと添付ファイルのバックアップ方針（復元テストまで）

ランニングコスト最優先で選ぶときの見方

安くするコツは「最小プランを固定で使う」ではなく、“必要になるまで上げない”設計にすることです。見るべきはこの3点です。

• 課金の粒度：月額固定か、日額/時間課金か
• 上限の有無：使い方でコストが暴れないか
• 増強のしやすさ：重くなったときの移行コスト

たとえば ConoHa は「月額＋時間課金の自動切替」を明確に説明しており、短期利用で無駄が出にくい設計です。
KAGOYAはRedmine向けに 日額と月額上限を出しており、「お試し」「小規模」「大規模」の目安も提示しています。
さくらのVPSも、メモリ別の月額料金が一覧で見えるため、段階的に上げる計画が立てやすいです。

参考（“試用〜小規模”のイメージを掴むための例）

方向性	料金設計の特徴	例として把握しておく数字
できるだけ小さく試す	日額＋月額上限	KAGOYA：1GBが日額20円（上限550円）など
月額固定で分かりやすく	月額（＋長期割引など）	ConoHa：通常料金は月額751円〜の案内
安い帯から段階的に上げる	明確な月額表	さくら：512MB 643円〜など

※RedmineはDBや添付が増えると“ストレージ容量”より“IO性能”が効いてくるので、安さ一点買いは避けるのが無難です。

人数・案件が増える前提で押さえるべき基準

Redmineは「人数」と「チケット数」と「添付」で、ある日急に重くなります。
“増える未来”があるなら、最初から次を満たすサービス/設計にしておくと後が楽です。

• 上位プランへ移行が容易（停止時間を最小化しやすい）
• バックアップの運用が回る（自動化・世代管理・復元の手順化）
• 監視/障害対応の導線がある（再起動だけで直る話ばかりではない）
• セキュリティの基本が揃う（FW/セキュリティグループ、SSH、更新）

具体的には、次の考え方が現実的です。

• 小規模でも「いずれ増える」なら、最初から 2GB〜 を起点にして、重ければ 4GB以上へ（プラン変更で吸収）
• 添付やDBが増えるなら、スナップショットだけに頼らず、DBダンプ＋添付の同期など“二段構え”にする
• 長期運用ほど「移行が難しい」ので、更新手順（Redmine/Rails/DB）を作業メモ化しておく

KAGOYAは「使用頻度が増えたらコントロールパネルからスペック変更しやすい」趣旨を示しています。

サーバー管理を避けたいならクラウド型も候補に入れる

「Redmineは使いたいけど、OS更新や障害対応はやりたくない…」なら、クラウド型（ホステッドRedmine）が合理的です。
判断軸はシンプルで、自由度より“運用を捨てる価値”が勝つかです。

クラウド型が向く人

• サーバー担当がいない / 兼務で限界
• すぐに利用開始して、運用は任せたい
• 多少の月額増より、工数削減を優先したい

クラウド型の注意点

• プラグインや改造の自由度が制限されやすい
• ユーザー数課金で、人数増に弱い場合がある
• データ移行の自由度（エクスポート/バックアップ範囲）を要確認

例として、My Redmine はプランごとの月額（例：スタンダード月額10,000円）や上限ユーザー数などを明示しています。
Planio も利用人数ベースの料金体系でプランを提示しています。

比較の前提：この記事の評価軸

Redmineの「レンタルサーバー選び」は、WordPressのように“とりあえず動けばOK”になりにくい分野です。
理由はシンプルで、常時稼働・DB・通知・バックアップ・セキュリティが運用の中心になるから。

そこでこの記事では、初心者でも判断を再現できるように「比較軸」を先に固定します。
（ここを決めておくと、広告や評判に引っ張られにくくなります）

何を重視してサービスを比べるか（再現できる比較軸）

Redmine向けのサーバー比較では、次の7点を“同じものさし”として使うのがおすすめです。

1. 性能（伸びしろ含む）
   • CPU/メモリ/ストレージ容量だけでなく、あとから増強しやすいか
   • 例：プラン変更、スケールアップ、ディスク拡張など
2. 安定運用のしやすさ
   • 再起動・復旧・監視の導線が用意されているか
   • 障害時に「復元の手順」が作りやすいか
3. バックアップの取りやすさ
   • スナップショット、バックアップ、世代管理などが現実的に運用できるか
   • Redmineは“DB＋添付ファイル”の両方が重要なので、二段構えにできるかがポイント
4. セキュリティの基本機能
   • ファイアウォール（セキュリティグループ）、SSH、アクセス制限など
   • OS/ミドルウェアの更新を“運用として回せる”仕組みがあるか
5. 構築のしやすさ（ただし後述の定義で）
   • テンプレ・スクリプト・Dockerなど、何が用意されているか
   • それが“今も提供され続けているか”（提供終了がないか）
6. サポートと情報量
   • 公式ドキュメントが分かりやすいか
   • つまずいたときに調べて解決できる“母数”があるか
7. コストの見通し
   • 月額だけでなく、日割り/時間課金、上限、長期割引などを含めて比較できるか

迷わないための簡易スコア例（初心者向け）

細かいベンチマークを取らなくても、次のように〇△×で整理すると判断が速くなります。

• 運用しやすさ：バックアップの設計が立つか／復元が現実的か
• 構築の手軽さ：最短で立ち上げられる仕組みがあるか
• 料金の分かりやすさ：課金ルールがシンプルか、上限があるか
• 将来性：プラン変更や移行がやりやすいか

この“評価軸テンプレ”を先に作っておくと、あとから比較表を作るときもブレません。

料金は「月額」だけで判断しない（初期費用・従量・長期割）

Redmine運用で料金比較を失敗しやすいパターンは、月額の安さだけで決めてしまうことです。
初心者ほど、次の4点セットで見てください。

料金比較で必ず見る4点

• 初期費用：無料か、有料か
• 課金の単位：月額固定／時間課金／日額課金
• 上限の有無：従量でも“青天井”にならないか
• 長期割引：年額や長期契約で安くなるか（ただし縛りも確認）

代表的な課金パターンと、向いている人

課金タイプ	特徴	向いている人
月額固定	予算を立てやすい	ずっと稼働させる本番運用
時間課金（＋自動切替）	短期利用の無駄が出にくい	まず試したい、検証を繰り返す
日額課金（＋月額上限）	“使った分”で試しやすく、上限で読みやすい	まず小さく始めて様子を見たい
年額（割引）	安くなる代わりに条件が出やすい	長期運用が確定している

💡初心者の結論としては、
「短期検証 → 本番化」を想定するなら、

• 検証時：時間課金/日額などでムダを抑える
• 本番化：月額固定や年額割引で安定させる
  という流れが合理的です。

“見落としやすいコスト”にも注意

Redmineは、使い続けるほど次のコストが効いてきます。

• バックアップ保存先（別ストレージ、別サーバー、外部サービス等）
• 監視・通知（無料範囲で足りるか／運用を自分で回せるか）
• ストレージ増設・プラン変更（容量よりもI/Oがボトルネックになりやすい）

月額が安くても、ここが弱いと“結局乗り換え”になりがちです。
「月額＋運用のしやすさ」でトータル判断するのが、結果的に安くなります。

“簡単に構築できる”の定義（テンプレ／Docker／手動の違い）

「簡単に構築できる」という言葉は、人によって意味が違います。
この記事では、必要な知識・再現性・保守のしやすさまで含めて次の3分類で整理します。

テンプレート／スタートアップスクリプト型

特徴

• 管理画面で選ぶだけ、またはスクリプトで自動セットアップ
• 最短でRedmineを起動しやすい（初心者の成功率が高い）

メリット

• 初期構築が速い
• “とにかく動かす”までの障壁が低い

注意点（重要）

• 提供が終了・変更される可能性がある
• Redmineや周辺ソフトのバージョンが固定/前提になりやすい
• “何がどう入ったか”を把握しないと、更新や移行で詰まりやすい

✅おすすめの使い方
まずテンプレ系で立ち上げ、構成メモ（OS/DB/Redmine/パス/バックアップ）を必ず残す。
その後、運用が固まってからDockerや自動化へ移行しても遅くありません。

Docker型（composeなど）

特徴

• 仕組みとしてはテンプレより“中身が見える”
• 同じ構成を別サーバーでも再現しやすい

メリット

• 再現性が高い（移行・復元が楽になりやすい）
• サーバーを替えても構成を持っていきやすい

注意点

• 最初にDocker/composeの理解が必要
• DBと添付の永続化をミスると、障害時に復旧しづらい

✅おすすめの使い方
“チーム運用”を見据えるなら最有力。
ただし初心者は、最初にバックアップと復元テストまでセットで設計すると安全です。

手動インストール型（OSに直接入れる）

特徴

• 自由度が最大
• その分、手順の難易度と責任も最大

メリット

• 好きな構成にできる（DB分離などもやりやすい）
• トラブルシュート力がつきやすい

注意点

• 初心者は“環境差”でつまずきやすい
• 更新・移行が属人化しやすい（手順書がないと危険）

✅おすすめの使い方
学習目的や、社内にインフラ経験者がいる場合に向きます。
“最短で運用開始”が目的なら、最初から手動にこだわる必要はありません。

まとめ：初心者が選ぶならこの順が失敗しにくい

1. テンプレ／スクリプトで最短起動（成功体験を作る）
2. バックアップ・復元・通知まで整備（運用を成立させる）
3. 必要になったらDocker/自動化へ（再現性と保守性を上げる）

「簡単さ」は“初回だけ”ではなく、更新・障害・移行が楽かどうかまで含めて判断すると、長期運用で後悔しにくくなります。

Redmineの基礎：できることと向き不向き

Redmineは「チケット（課題）」を中心に、プロジェクトの情報を一か所に集めて進めるためのWebアプリです。
レンタルサーバー選びの前に、Redmineが“何を得意としていて、何が苦手か”を押さえると、後悔が減ります。

Redmineが担う役割（課題管理・進捗・履歴の一元化）

Redmineの本質は、やることを“チケット化”して、仕事の流れを見える化することです。
具体的には、次の情報を1つの場所に集約します。

• 課題（チケット）：やること／期限／担当／優先度／状態
• 進捗の見える化：ガントチャート、カレンダー
• 履歴（いつ・誰が・何を）：変更ログ、コメント、添付の更新履歴
• プロジェクトの情報置き場：Wiki、ドキュメント、ファイル、掲示板（フォーラム）
• 通知：メール通知、フィード（状況変化が追いやすい）
• 時間の記録：作業時間（工数）・予定工数の管理
• 開発と連携しやすい要素：リポジトリ連携（Git等）、REST API、メールでチケット作成など

初心者目線でのポイントは、Redmineは「何となくの会話」よりも、
“仕事を記録しながら進める”運用に向いていることです。

レンタルサーバー選びに直結する“地味だけど重要”な前提

Redmineは便利なぶん、次の要素が運用に影響します。

• 通知をちゃんと活かすなら メール送信（SMTP）の設計が必要
• 添付・ファイルが増えると ストレージ容量だけでなく、ディスクI/Oやバックアップが重要
• チケットが増えると DBの負荷が効いてくる（メモリも重要）

「動いた！」で終わらず、運用まで見越してサーバーを選ぶべきなのはこのためです。

OSSならではの強み（拡張性・自由度・データ管理）

Redmineが長く使われている理由は、OSS（オープンソース）としての性質にあります。

1) 自分たちの運用に合わせて“型”を作れる

Redmineは、次のような“業務ルール”をシステム側に落とし込みやすいです。

• 役割ごとの権限（閲覧・編集・承認など）
• ステータス遷移（例：新規→進行中→レビュー→完了）
• チケットの種別（バグ／要望／タスク…）
• 入力項目の追加（カスタムフィールド）
  • 例：顧客名、影響範囲、再現手順、検収日など

この「ルールを統一してブレを減らす」力が、Redmineの大きな価値です。

2) データを自分で握れる（ロックインしにくい）

クラウド型の管理ツールは、料金改定や機能変更、契約条件の影響を受けやすいです。
一方、Redmineはセルフホストなら データの保存先・バックアップ・移行を自分でコントロールできます。

• 監査・コンプラの都合で「データを社内（自社）で管理したい」
• ベンダー都合の仕様変更に振り回されたくない
• 長期運用を前提にしたい

こういったケースでは、OSSのメリットが効きます。

3) 連携しやすい（外部ツールとつなぎやすい）

RedmineはREST APIを提供しており、外部システムとの連携や自動化の余地があります。
「Slack通知」「CI/CD」「社内台帳」などに広げたい場合の選択肢が作れます。

※ライセンス（GPL）絡みは、配布や改変の扱いで注意点が出ることがあります。ビジネス利用そのものが禁止という話ではありませんが、“自社の使い方”に応じて確認するのが安全です（必要なら法務へ）。

自前運用で得する点／苦労しやすい点

「Redmineをレンタルサーバーで動かす」＝セルフホストは、自由度と引き換えに責任も増えます。
ここを納得できるかが、最大の分かれ道です。

メリット：カスタマイズ・権限設計・運用ルールの統一

セルフホストで得しやすいのは、次のような状況です。

• チームのやり方が決まっている／決めていきたい
  • ステータス、担当範囲、レビュー手順などを“運用ルール”として固定しやすい
• 権限設計が重要
  • 閲覧範囲、操作権限をロールで整理しやすい
  • プロジェクトごとに役割を変える運用とも相性が良い
• 入力項目や帳票の癖が強い
  • カスタムフィールドで“必要な情報を取りこぼさない”運用を作りやすい
• データの主導権を持ちたい
  • バックアップ、移行、ログ保管などを自分で設計できる

まとめると、セルフホストの旨みは 「自社の運用に最適化できる」点にあります。

注意点：保守・セキュリティ・障害対応の責任が発生

一方で、初心者が見落としやすい負担もはっきりあります。

• アップデート対応が必要
  • OS、DB、Redmine本体、プラグイン…更新対象が複数ある
• セキュリティの基本を自分で守る
  • SSH、FW、パスワード、アクセス制限、脆弱性情報の確認
• 障害時に止まると自分たちが困る
  • 復旧の手順（バックアップから戻す、切り戻す）を用意しておく必要
• メール通知がハマりやすい
  • “送れる状態”にしないとRedmineが急に使いにくくなる

ここを雑にすると、「最初は安い・自由」でも、後から運用コスト（時間）が膨らみがちです。

要点まとめ（判断を間違えないための着眼）

初心者が判断するなら、次のチェックでかなり整理できます。

• 自前運用が向く人
  • 多少のサーバー管理を受け入れられる（担当がいる／学ぶ意志がある）
  • 権限や運用ルールを固めて、チームで回したい
  • データを自社で管理したい（監査・ポリシー事情など）
• 自前運用が向きにくい人
  • サーバー運用を任せられる人がいない（トラブル対応が無理）
  • すぐ使えて、保守を極力ゼロにしたい
  • 料金よりも「止まらないこと」を最優先したい（SaaSの方が安心な場合が多い）

結論として、Redmineは “運用を設計できるチーム”ほど強くなるツールです。
逆に、運用が成立しないと「難しい・面倒」に感じやすいので、レンタルサーバー選びの前にここを確認しておくのが大切です。

どの方式が合う？ ホスティング形態の全体像

Redmineは「Webアプリ＋データベース＋添付ファイル＋メール通知」を継続運用する前提のツールです。
そのため、サーバー選びでは “最初の構築の楽さ” だけでなく “運用が回るか” を軸に考えると失敗しにくくなります。

まずは代表的な4方式を、ざっくり俯瞰しておきましょう。

方式	ざっくり言うと	向いている人
共用サーバー	みんなで1台を分け合う	“Redmineはお試し”で、要件が軽い人（ただしハマりやすい）
VPS	自分専用に近い仮想サーバー	低コストで自由度も欲しい人（最有力になりやすい）
クラウドサーバー	拡張しやすいIaaS	成長前提、冗長化や分離構成まで視野に入れる人
マネージド型	Redmineをサービスとして使う	サーバー運用を避け、使うことに集中したい人

共用サーバーが相性悪くなりやすい理由（権限・性能・運用）

結論から言うと、Redmineは共用サーバーだと “動かせたとしても運用で詰まる” ことが多いです。
理由は、共用サーバーの制約が Redmine の前提とぶつかりやすいからです。

1) 権限の制約で「必要なことができない」ことがある

• OSパッケージの追加・更新が自由にできない
• 必要なミドルウェア（DBや周辺ライブラリ）を入れられない/バージョンが合わない
• 常時稼働させたい処理（バッチ等）を走らせにくい

2) 性能が読みにくく、突然重くなる

共用サーバーは他ユーザーと資源を分け合うため、以下が起きやすいです。

• ピーク時間帯にレスポンスが落ちる
• CPU/メモリの上限に当たりやすい
• DBやストレージI/Oの影響を受けやすい

Redmineは、チケット・コメント・履歴・添付が増えるほど、地味に負荷が積み上がります。
「最初は軽い」が当てにならないのが難点です。

3) 運用（バックアップ/メール/セキュリティ）でハマりやすい

• メール通知：送信制限・認証要件・ポート制限などでつまずくことがある
• バックアップ：DBと添付ファイルを“確実に”定期取得しづらい
• セキュリティ：アップデート運用・アクセス制限の自由度が低い

共用サーバーを検討するなら最低限の確認ポイント

どうしても共用で試したい場合は、次を事前に確認しておくと「時間が溶ける」リスクを減らせます。

• Ruby/RailsやDBを含め、必要な実行環境が揃うか
• cron等の定期実行が許可されているか
• DB作成やバックアップ導線があるか
• メール送信（SMTP）の設定が実現できるか

とはいえ、初心者で「ちゃんと使い続ける」なら、最初からVPSかマネージド型へ寄せる方が現実的です。

VPSが向くケース（自由度とコスパの両立）

VPSは、Redmine運用で 最も選ばれやすい落としどころ です。
理由はシンプルで、Redmineが必要とする要素（権限・DB・運用）を満たしやすいから。

VPSが向く人

• できるだけ費用を抑えつつ、自由度も欲しい
• バックアップや更新など、最低限の運用を自分（またはチーム）で回せる
• プラグイン導入や設定カスタムも視野にある
• 小〜中規模（個人〜数十名程度）で始めたい

VPSのメリット

• 管理者権限がある：必要なソフトを入れて、更新も自分でできる
• 性能が読みやすい：プラン（CPU/メモリ/SSD）を明確に選べる
• 伸びしろがある：重くなったら上位プランに上げやすい
• 構築方法を選べる：テンプレ/スクリプト/Docker/手動など選択肢が広い

VPSの注意点（初心者がつまずきやすいところ）

• セキュリティ（SSH、FW、更新）を“自分の責任”でやる必要がある
• バックアップは「取る」だけでなく 復元できるかテスト が必要
• メール通知（SMTP）設定ができないと、Redmineの価値が半減しがち

初心者向けの現実的な使い方

• 最初は テンプレ/スクリプトで早く起動 → 成功体験を作る
• その後に バックアップ・更新・監視 を整えて“運用を成立”させる
• 余裕が出たら Docker化や自動化で再現性を上げる

クラウドサーバーが向くケース（拡張・冗長化のしやすさ）

ここで言う「クラウドサーバー」は、一般に IaaS（必要なものを組み合わせて作る） のイメージです。
VPSより自由で強力ですが、その分 “設計” が必要になります。

クラウドサーバーが向く人

• 初期は小さく始めつつ、将来的に増えるのがほぼ確定
• 重要プロジェクトで、止まると困る（冗長化を考えたい）
• DBやストレージを分離して、性能と保守性を上げたい
• インフラに明るい人がいる/外部に任せられる

クラウドの強み（Redmine目線）

• 構成を分けやすい
  • 例：WebサーバーとDBを分離
  • 例：添付ファイルをオブジェクトストレージへ
• スケール戦略が取りやすい
  • 垂直スケール（スペックアップ）も、構成分離（水平）も選べる
• 運用部品を活用できる
  • ロードバランサ、監視、バックアップ、スナップショット、マネージドDBなど

注意点：コストと難易度が“複合課金”になりやすい

• 単純な月額比較がしづらい（通信量、ストレージ、バックアップ等が別料金になりがち）
• 設計が甘いと、性能が出ない／費用が増える
• “便利機能”が多い分、初心者は選択疲れしやすい

初心者がクラウドを選ぶなら

いきなりフル構成にせず、まずは VPSに近い単体構成 で始め、
必要になってから「DB分離」「ストレージ分離」を段階的に足す方が安全です。

マネージド型（クラウドRedmine）が向くケース（運用負荷の削減）

マネージド型は、Redmineを “アプリとして借りる” 方式です。
サーバーの構築・保守が不要になり、使うことに集中できます。

マネージド型が向く人

• サーバー運用を避けたい（担当がいない／兼務で限界）
• 早く使い始めたい、止めたくない
• セキュリティや更新を自分で追いかけたくない
• 初期費用より 運用工数の削減 を優先したい

メリット

• 導入が速い：環境構築がほぼ不要
• 運用負荷が軽い：更新・保守・バックアップがサービス側に寄る
• 安定運用を期待しやすい：監視や冗長化が整っている場合が多い

注意点（契約前に必ず確認）

• プラグインや改造の自由度：できることが制限される場合がある
• 料金体系：ユーザー数課金などで、人数増に弱いケースがある
• データの扱い：バックアップ範囲、エクスポート、移行のしやすさ
• 運用ルールの自由度：細かな要望が通らない場合もある

“運用を捨てる価値”で考えると判断しやすい

迷ったら、次の問いが答えになります。

• Redmineを止めないための運用（更新・復旧）を、自分たちでやりたい？
• それとも、月額が少し上がっても 運用を外部化 したい？

「使うことに集中したい」なら、マネージド型は非常に強い選択肢です。

Redmineセルフホストの要件整理（必要スペックと構成の考え方）

Redmineは「Webアプリ＋データベース＋添付ファイル＋通知（メール）」で成り立ちます。
つまり、サーバー要件も CPU/メモリだけでは決まりません。

• 同時に触る人数（同時アクセス）
• チケット数・履歴の増え方
• 添付ファイルの量（画像・PDF・設計資料など）
• 通知メールの量（チケット更新が多いほど増える）
• プラグイン導入やカスタム（追加機能は負荷も増えやすい）

この前提を踏まえて、初心者でも見立てやすい「目安」を整理します。

推奨スペックの目安（小規模〜大規模の見立て）

Redmine公式は「◯GB以上」といった固定の推奨スペックを明示していません。
そこでここでは、セルフホストでつまずきやすいポイント（DB・添付・メール）を含めて、現実的な“最初の着地”を提示します。迷ったら 1段階上を選ぶのが安全です。

ざっくり早見（最初の目安）

規模のイメージ	人数 / 使い方	目安のvCPU	目安のメモリ	ディスク（SSD推奨）	コメント
小規模	〜5人、軽め（添付少なめ）	2	2〜4GB	30〜50GB	まずはこれで始めやすい
中規模	10〜30人、毎日使う	2〜4	4〜8GB	80〜150GB	体感が重くなる前に余裕を持つ
大規模	50人〜、プロジェクト多数	4〜8	8〜16GB	200GB〜	DB分離やストレージ設計も検討
かなり重い	100人〜、添付多い、連携多数	8〜	16GB〜	500GB〜	構成を分けないと安定しにくい

※「人数」は目安です。実際は 同時アクセスと添付の量で負荷が大きく変わります。

ボトルネックになりやすい順（初心者が見落としがち）

• メモリ不足：Ruby/Rails系はメモリが足りないと一気に苦しくなります
• ストレージI/O：添付が増えると読み書きが増えて体感が落ちやすい
• DB性能：チケット・履歴が増えるとDBが効いてきます
• メール送信：通知が使えないと運用が回りにくい（=実質使い物にならない）

DBは何を選ぶべき？

本番運用では、まず PostgreSQL または MySQL/MariaDB から選ぶのが無難です。
SQLiteは手軽ですが、複数人での本番運用には向きません。

構成パターン（単体運用／DB分離／ストレージ重視）

Redmineの構成は、最初から完璧にしなくてOKです。
ただし「どの方向に伸ばすか」を先に決めておくと、移行の痛みが減ります。

パターン1：単体運用（まず動かす最短ルート）

構成：1台に Redmine（Web/アプリ）＋DB＋添付 を全部置く

• 向いているケース
  • 小〜中規模で、まずは運用を開始したい
  • コストを抑えたい
  • いずれスケールするか未確定
• メリット
  • 構築が簡単
  • 障害切り分けがシンプル（全部同じ箱）
• デメリット
  • 重くなったとき「全部増強」が基本（原因が混ざりやすい）

初心者のおすすめ：まず単体で始めて、バックアップと更新運用を固める → 重くなったらDB分離へ。

パターン2：DB分離（重くなってきたら効く定番）

構成：Redmine（Web/アプリ）とDBを別サーバーに分ける

• 向いているケース
  • 体感の遅さが出てきた
  • 同時利用者が増える、プロジェクトが増える
  • DBのバックアップや監視を強化したい
• メリット
  • DBにメモリを寄せられる（効きやすい）
  • 障害の切り分けがしやすい
  • 将来的な冗長化にもつなげやすい
• デメリット
  • 構成が複雑になる（ネットワーク、セキュリティ、費用）

コツ：DB分離を見越すなら、最初から「DBと添付を別ボリュームに置く」設計にしておくと移行が楽です。

パターン3：ストレージ重視（添付が多いチーム向け）

構成：Redmine本体は普通、添付ファイル領域だけを大きく速くする（別ディスク/別ボリューム）

• 向いているケース
  • 仕様書や画像、PDFをよく添付する
  • 「検索より、添付の出し入れ」が日常的に発生する
  • バックアップ対象が肥大化しやすい
• 具体策（例）
  • 添付用ディスクを別にする（容量とI/Oを確保）
  • 添付保存先を切り替える（設定でパス変更）
  • バックアップを「DBは毎日、添付は差分で」など運用を分ける

注意：添付が増えるほど、バックアップ/復元の設計が重要になります（“取れてる”ではなく“戻せる”が大事）。

周辺要素も忘れずに（メール通知・SSL・ドメイン・バックアップ）

ここを後回しにすると、「動くのに使えない」になりがちです。最低限、次の4点はセットで考えましょう。

メール通知（運用の生命線）

Redmineは通知がある前提で運用すると、情報共有が一気に楽になります。

• まず押さえること
  • 送信に使うSMTP（社内メール、外部SMTP、Gmail/Google Workspace、Microsoft 365等）
  • 送信元アドレスの設計（例：redmine@あなたのドメイン）
  • 迷惑メール対策（SPF/DKIM/DMARCが関係するケースも）
• つまずきやすいポイント
  • SMTPのポート制限
  • TLS設定
  • 認証方式（ログイン/プレーン等）

実務的には：「SMTP設定ができる環境か？」は、サーバー選びの必須チェック項目です。

SSL（HTTPS）は最初から前提にする

RedmineはID/パスワードやチケット内容（業務情報）を扱います。
外部公開でも社内利用でも、基本はHTTPSが前提です。

• Let’s Encrypt等で証明書を用意
• 可能ならHTTP→HTTPSリダイレクト
• 管理画面も含めて常時HTTPSに

ドメイン（アクセスしやすさ＝定着率）

IPアドレス直打ちは、運用が続きません。

• 例：redmine.example.com のようなサブドメイン運用がおすすめ
• DNSのAレコードを設定（将来移行するときも切り替えが楽）
• チームが増えるなら、社内ポータル等からリンクを固定

バックアップ（最重要：DB＋添付の両方）

Redmineのバックアップは 「DBだけ」「ファイルだけ」では不十分です。

• 最低限のバックアップ対象
  • DB（チケット・履歴・設定）
  • 添付ファイル（アップロードされた資料）
• 運用の目安（例）
  • DB：毎日（世代管理あり）
  • 添付：毎日差分＋週1フル、など現実的な設計に
  • そして、復元テストを最低でも最初に1回やる（ここが抜けがち）
• ありがちな事故
  • 添付の保存先を変えたのに、バックアップが元の場所だけで“実質ゼロバックアップ”
  • DBは戻せたが、添付がなくて業務が止まる

サーバー選定チェックリスト（ここを外すと失敗しやすい）

Redmineは「Webアプリ＋DB＋添付ファイル＋通知（メール）」を継続運用する前提のツールです。
そのため、サーバー選びで大事なのは “最初に動くか”より“運用が回るか”。

ここでは、初心者がつまずきやすい順にチェックポイントを整理します。

即時構築の手段はあるか（テンプレ／プリセット／イメージ）

「すぐ使える仕組み」があると、初手の難易度が一気に下がります。
ただし、“ワンクリック”にも種類があるので、次のように分けて確認するのがコツです。

よくある即時構築のタイプ

• アプリイメージ／テンプレート：OS＋必要ソフトが入った状態で立ち上がる
• スタートアップスクリプト：作成時に自動インストール・自動設定が走る
• Dockerテンプレ（compose等）：再現性は高いが、最初の理解は必要

初心者が必ず確認したい“落とし穴”

• 再構築（作り直し）時にも選べるか？
  → 「今はある」でも、提供終了・切り替えが起きることがあります。
• 対応OSが固定されていないか？
  → 例：スクリプトが特定のUbuntuだけ対応、など。
• 初期管理者パスワードの扱い
  → 自動生成される場合、控え方を間違えると詰みます。
• “どの構成で入るか”が明記されているか
  → DB種類、Webサーバー、Redmineのバージョン方針など。

実務的な結論

• とにかく早く立ち上げたいなら、スタートアップスクリプト／アプリイメージがあるサービスを優先。
• ただし「提供終了・仕様変更」があり得るので、公式の更新情報（リリースノート等）を見てから決めるのが安全です。

CPU・メモリ・SSDの見方（体感速度に効くポイント）

Redmineは「メモリ不足」と「ディスクI/O不足」で体感が落ちやすいタイプです。
CPUはもちろん重要ですが、初心者は優先順位を間違えないのが大切です。

体感速度に効きやすい順（目安）

1. メモリ：足りないと全体が苦しくなる（レスポンス悪化、落ちやすい）
2. SSDの質（I/O）：添付や履歴が増えると効いてくる
3. CPU（vCPUコア数）：同時アクセスや処理量が増えたときに効く
4. 容量（GB）：添付が増えるなら必要。ただし“速さ”はI/O次第

初心者向けの読み方（迷わないルール）

• 迷ったら メモリを優先して1段階上（後悔が少ない）
• 添付が多い運用なら、容量より先に SSD/NVMeなどストレージ性能を意識
• “最初のプランが安い”より、後から増強できるかを重視（プラン変更のしやすさ）

追加で見ておくと失敗しにくい項目

• ストレージの増設が簡単か（後から詰む原因になりやすい）
• プラン変更でIPが変わるか（ドメインやアクセス制御に影響）

運用を楽にする仕組み（スナップショット／自動バックアップ）

Redmine運用で一番痛い事故は「戻せない」ことです。
だから、バックアップは “あるかどうか”ではなく“戻せる設計か”で判断します。

バックアップの種類を整理（混ぜると危険）

• スナップショット（サーバー丸ごと）
  • 速い／手軽／復元もしやすい
  • ただし容量・ファイル数など制限がある場合もある
• アプリとしてのバックアップ（Redmine運用としての正解）
  • DB（チケット・履歴）＋添付ファイルを別々に確実に取る
  • 復元テストがしやすい（壊れ方に強い）

チェック項目（最低ライン）

• 定期スナップショットが作れるか（手動だけだと忘れがち）
• 世代管理（何世代残るか）が現実的か
• 復元の手順が分かりやすいか（UIで戻せるか／手動コマンドか）
• 別筐体（別の場所）にもバックアップできるか
  • 同一サーバー内だけだと、障害時に一緒に吹き飛びます

初心者がやりがちなミス

• 「スナップショットがあるから安心」と思い、DB＋添付の運用バックアップを作らない
• バックアップはあるのに、復元テストを一度もしていない

管理画面の使いやすさ（再起動・スケール・復元の手間）

初心者ほど、管理画面の使いやすさが“継続運用できるか”を左右します。
Redmineは一度動かして終わりではないため、次の操作がストレスなくできるかが重要です。

最低限チェックしたい操作

• 再起動／停止／作り直し（再構築）が迷わずできる
• スナップショット作成・復元がUIで分かりやすい
• スペック変更（スケール）が簡単
  • ダウンタイムがどれくらいか／IPが変わるかも確認
• FW（セキュリティグループ）設定が分かりやすい
  • SSH、HTTP/HTTPS、管理用アクセスの制御がしやすい

“地味に効く”確認ポイント

• コンソール（ブラウザからログイン）が使えるか
  → SSH接続で詰んだときの保険になります。
• 操作履歴や通知があり、何をしたか追えるか（チーム運用で重要）

サポート品質と情報量（困ったときに詰まらないか）

Redmineは「設定が多い＝調べる機会も多い」ツールです。
初心者ほど、サポート品質よりも “情報量”が効きます。

チェック項目

• 公式ドキュメントがあるか（手順が最新か・更新されているか）
• テンプレ／スクリプトの仕様が明記されているか
  • 対応OS、初期パスワード、導入される構成など
• トラブル時に相談できる窓口があるか
  • チャット／メール／電話（事業用途なら重要）

判断のコツ

• 「スペックや価格」よりも、初心者はまず “詰まったときに抜けられる導線”を重視すると失敗しにくいです。

セキュリティ機能（FW・SSH・アクセス制限・更新体制）

Redmineには業務情報が集まります。
そのため、セキュリティは“オプション”ではなく“必須作業”として考えましょう。

最低限ほしい機能・運用

• FW（セキュリティグループ）で、不要なポートを閉じられる
• SSHは可能なら 鍵認証＋パスワードログイン無効
• 管理画面は IP制限できると安心（社内固定IPやVPN経由など）
• アップデート運用を回せる
  • OS更新・ミドルウェア更新・Redmine更新（＋プラグイン互換性）

初心者の現実的な落としどころ

• 最初から“完璧なセキュリティ設計”を目指すより、
  FW＋SSH鍵＋HTTPS＋バックアップの4点を先に固める方が実用的です。

お試し／返金／日割りなど“始めやすさ”の条件

初心者は「合わなかったらやめる」ができる条件が大切です。
ここは料金表より先に見る価値があります。

“始めやすさ”のチェック項目

• 初期費用が無料か
• 最低利用期間があるか（縛り）
• 時間課金／日額課金があるか（短期検証がしやすい）
• 月額上限のような“暴れ止め”があるか（従量でも安心）
• 停止中も課金されるか（サービスによっては 停止＝無料 ではない）

初心者向けのおすすめ判断

• まずは 短期検証しやすい課金体系で試す
• 使い続けると決めたら、長期割引（年額等）を検討する
  • ただし途中解約の扱いは必ず確認

5分で確認できるチェック表（コピペ用）

項目	OKの目安	NGサイン
即時構築	テンプレ or スクリプトがあり仕様が明記	仕様が不明／提供終了が近い
体感性能	メモリを上げやすい／SSD性能が期待できる	プラン変更が面倒／I/Oが弱そう
バックアップ	定期スナップショット＋DB/添付の運用バックアップ	手動のみ／復元手順が曖昧
管理画面	再起動・復元・FW設定が迷わない	何がどこにあるか分かりにくい
情報量	公式ドキュメントが充実	記事はあるが古い情報ばかり
セキュリティ	FW/SSH/IP制限/HTTPSが揃う	設定できない／制限が強い
始めやすさ	初期費用なし＋日割り/時間課金など	縛りが強い／解約が厳しい

主要VPSの比較早見（プラン選びを短縮するための整理）

「Redmineを動かす」だけなら多くのVPSで実現できますが、“どれだけ迷わずに始められて、どれだけ安全に運用できるか”で体験は大きく変わります。

ここでは、国内で候補に上がりやすい主要VPSを「意思決定しやすい粒度」に落として整理します（細かなスペック差よりも、まずは“選ぶ軸”を揃えるのが目的です）。

比較表で確認すべき項目（課金方式・テンプレ対応・運用機能）

比較で迷ったら、以下の順にチェックすると決めやすいです。

• 課金のクセ
  • ずっと稼働前提：月額（＋長期割）が向く
  • 触る日だけ起動：時間課金・日額上限などが向く
• “すぐ立ち上がる”手段
  • アプリイメージ（最短）／スタートアップスクリプト（自動構築）／Docker（柔軟）／手動（自由度）
  • ※ConoHaはRedmineのアプリテンプレ提供が終了し、スクリプト利用が現実的なルートになっています
• 運用をラクにする仕組み
  • スナップショット・バックアップ（頻度、世代数、料金）
  • 例：KAGOYAは自動スナップショットの方式・世代が明記されています
• 伸びたときの逃げ道
  • メモリ増設（スケールアップ）の手軽さ、ストレージ追加の可否、DB分離のしやすさ
• 初心者が詰まりにくい要素
  • 管理画面の操作感、公式ドキュメント量、トラブル時の導線（問い合わせ・障害情報）

主要VPS比較サマリー（まずは“違い”だけ掴む）

※金額は最小付近の目安として捉え、最終判断は最新の公式表示で確認してください（キャンペーン・更新時価格・税込表記の違いがあるため）。

サービス	課金の特徴	Redmineの立ち上げ方（最短ルート）	運用面で見ておく点	向く人のイメージ
ConoHa VPS	時間課金と長期割（まとめトク）の2系統	スタートアップスクリプトで自動構築（Redmine用テンプレあり）	自動バックアップ等はオプション体系を要確認（512MBは制限あり）	「短期で試す→良ければ長期運用」に寄せたい人
さくらのVPS	月額が分かりやすい（2週間の無料お試しあり：条件あり）	基本は手動構築（スタートアップスクリプトは用意）	“まずは動かす”までの手順は自分で組む前提。学習コンテンツは豊富	手順を追って構築したい／堅実に始めたい人
シンVPS	低〜中価格帯のプランが多い（プラン刻みが細かい）	アプリイメージ（Redmine）の更新・提供あり	情報量は大手より少なめになりがち（詰まった時の検索性を意識）	コスパ重視で、ある程度自走できる人
XServer VPS	月額系（キャンペーン等で見え方が変わる）	アプリイメージ（Redmine）が利用可能	“速さ”は評価されやすい一方、価格は安さ一本ではない	性能・安心感を優先し、最短で環境を作りたい人
KAGOYA CLOUD VPS	1日単位＋月額上限の考え方がある	Docker系のイメージ活用が現実的（ただしRedmine系は提供状況を要確認）	スナップショット仕様が明記（頻度・世代）	「使った分だけ」寄りで運用したい／検証〜本番まで段階運用したい人

この表を“プラン決定”に落とす簡単ルール

最後に、初心者でも判断を進めやすいように、表の使い方をルール化します。

• 最短で動かしたい
  → 「アプリイメージ」か「Redmine用スクリプト」があるVPSを優先（手動は後回し）
• 毎月のコストを読みやすくしたい
  → 月額中心（＋長期割があるなら比較）
• “使う日だけ”の運用も想定
  → 時間課金・日額上限のような課金体系を優先
• バックアップを自分の運用から外したい
  → 自動バックアップ／スナップショットの仕様が明確なサービスを優先

サービス別の特徴と向いている人（セルフホスト向け）

Xserver VPS

すぐに使える状態を優先したい人向け（アプリイメージで短縮）

Redmineを「最初から動く形」で立ち上げたい人に向きます。サーバー作成時にRedmineのアプリイメージを選べるため、手作業の工程を減らしやすいのがポイントです。

強み：初期構築の手戻りを減らしやすい／復旧用の“丸ごと保存”が使える

• Redmineのアプリイメージが用意されており、OSと一緒に環境を作りやすい
• いざという時のために、サーバー状態を丸ごと保存して戻せる仕組み（イメージ保存）をバックアップ用途で使える
• 手順が定型化しやすく、社内共有（運用ルール・手順書）とも相性が良い

注意点：プラン最適化をしないと割高になりやすい

• “テンプレで楽”な分、必要以上に大きいプランを選ぶとコストが膨らみがち
• アプリイメージは「用意されたOS・構成」が前提なので、独自構成（Webサーバー変更など）にしたい場合は結局手作業が増える
• セキュリティ更新や障害対応はセルフホストの責任範囲（ここを軽視すると事故りやすい）⚠️

相性が良い利用シーン例

• まずは社内でRedmineを試験導入し、短期間で“使える状態”にしたい
• 構成をシンプルに保ち、運用手順を標準化して回したい
• 失敗時にすぐ戻せる仕組みを前提に、安心して更新・検証を回したい

XServer VPS 公式サイト

ConoHa VPS

割引や特典を取り込みつつ、段取り良く始めたい人向け

「できるだけ早く使い始めたい」「ただし費用も気になる」というタイプに向きます。Redmine用のスタートアップスクリプトが用意されていて、初期構築の時間を削りやすいです。

強み：スタートアップスクリプトが実務向けに整っている／契約特典が分かりやすい

• Redmine用スタートアップスクリプトがあり、対応OS・主要ソフトのバージョンまで明記されている
• 初期管理者（admin）のパスワードが自動生成されるなど、最初のセキュリティ事故を減らす設計
• 長期割引の契約でSSL特典が付くなど、“追加費用になりがちな要素”を抑えられる場合がある
• 時間課金と長期割引（まとめトク）の併用で、使い方に合わせてコスト設計しやすい

注意点：提供方式の変化を前提に、手順を公式で確認する

• 以前の「アプリケーションテンプレート」と、現在の「スタートアップスクリプト」では提供方式が異なるため、古い記事の手順をそのままなぞるのは危険
• スクリプト完了まで“数分〜数十分”かかることがあり、待ち時間やログ確認も運用に組み込む必要がある
• 便利な反面、公開ポート（HTTP/HTTPS）や仮想FW（セキュリティグループ）を理解せずに進めると、公開事故につながりやすい⚠️

相性が良い利用シーン例

• 最短で立ち上げつつ、公式手順で堅実に運用したい
• SSLや周辺設定を「あとで足す」ではなく、最初から整えたい
• スモールスタート→利用人数に合わせて拡張、の流れを想定している

ConoHa VPS 公式サイト

シンVPS

添付やログが増える運用を見据え、メモリとディスクのバランスを取りたい人向け

“運用が軌道に乗ってデータが膨らむ”ことを想定して、早めに余裕を確保したい場合に向きます。アプリイメージにRedmineがあるので、初期構築も短縮できます。

強み：アプリイメージで始めやすい／増設オプションが明確

• Redmineのアプリイメージが用意され、構築の最短ルートを取りやすい
• NVMe SSDのストレージを増やすオプションがあり、データ増に合わせた設計がしやすい
• AIチャットを含むサポート強化の取り組みがあり、初学者の“詰まりポイント”を潰しやすい

注意点：情報量が少ない領域は自分で検証する前提を持つ

• 大手に比べてノウハウ記事が少ないケースがあるため、構成変更やプラグイン導入は検証しながら進めるのが安全
• “動けばOK”で放置すると、Ruby/Rails系の更新・脆弱性対応で後から苦労しやすい
• バックアップ設計（何を・どの頻度で・どこへ）を先に決めないと、事故ったときに復旧が遅れる⚠️

相性が良い利用シーン例

• 添付ファイル・ログが増えやすい運用を想定している（社内利用、複数案件など）
• まずはテンプレで立ち上げ、運用しながら少しずつ最適化したい
• メモリ/ディスクの“余裕”を最初から取り、ストレスを減らしたい

シンVPS 公式サイト

KAGOYA CLOUD VPS

日割りで試しつつ、テンプレートで素早く検証したい人向け

「まず触って確かめたい」「検証環境を作って壊して戻す」を繰り返す用途と相性が良いタイプです。Redmineのテンプレートも用意されています。

強み：日額課金＋上限設計で試しやすい／スナップショットの運用がしやすい

• Redmineテンプレート（Bitnami-Redmine）で自動構築しやすい
• 日額課金でスタートでき、月額上限があるため、短期利用でも読みやすい
• スナップショットを定期取得でき、世代管理もできる（復旧の段取りを作りやすい）
• Dockerテンプレートなど“検証向けテンプレ”があり、学習・実験用途に寄せやすい

注意点：テンプレ任せにしすぎない（本番運用に必要な詰めが残る）

• テンプレで立ち上がっても、運用要件（権限設計、バックアップ、監視、更新）を決めないと長期運用が不安定になりがち
• スナップショットや追加リソースは課金対象になりうるため、運用コストを「月額固定」と思い込みすぎない
• Bitnami系は構成が分かりやすい反面、独自チューニングの前に“標準構成の理解”が必要

相性が良い利用シーン例

• PoC（試験導入）や検証で、まずRedmineを触れる状態にしたい
• 定期スナップショット前提で、安心して検証→復元を回したい
• Dockerやテンプレートを使って、手戻り少なく環境を組みたい

KAGOYA CLOUD VPS 公式サイト

さくらのVPS

老舗の安定感と、プランの選びやすさを重視したい人向け

“派手さより堅実さ”を取りたい人向けです。テンプレでの即時構築が前提というより、OSから自分の手で整える運用に向きます。

強み：小さく始めて段階的に育てやすい／長期運用の安心感

• 小さめのプランから始めやすく、用途に合わせて段階的に上げていける
• シンプルなVPSとして、自由度の高い運用設計を組みやすい
• “手順が枯れている”タイプの運用（OS→ミドルウェア→Redmine）を好む人に向く

注意点：テンプレ前提ではないので、導入手順を先に見積もる

• 自動構築が前提のサービスと比べると、初期構築は手作業が増える可能性がある
• Ruby/Rails系は更新・依存関係のハマりどころがあるため、構築手順をドキュメント化しておくのが重要
• “バックアップ・復元”の実装は利用者側の設計になりやすいので、運用開始前に方針を決めておくと安心

相性が良い利用シーン例

• 長く堅実に運用する前提で、最初から構成を理解しながら作りたい
• 既にLinux運用の経験があり、テンプレよりも自由度を取りたい
• 余計な機能より「基本の安定運用」を優先したい

さくらのVPS 公式サイト

サーバー不要で使う選択肢（クラウド型Redmine）

「Redmineを使いたいけど、サーバー管理はできれば避けたい」という場合は、クラウド型（ホステッドRedmine）が現実的です。
ブラウザでログインして使い始められ、OS更新・ミドルウェア管理・障害対応の多くを事業者側に寄せられます。

一方で、自由度（プラグインや構成の裁量）はVPSより下がりやすいので、「何を手放して、何を得るか」を最初に決めるのがコツです。

My Redmine：運用の手間を抑えて使い始めたい場合

My Redmineは、Redmineを日本国内向けにクラウド提供しているタイプのサービスです。
「まず動く状態で使いたい」「日本語での運用を前提にしたい」なら候補になります。

ざっくり特徴

• ✅ 申し込み後すぐ使える（セルフ構築の手順が不要になりやすい）
• ✅ データ保管は日本国内（国内リージョン運用を明示）
• ✅ プランは月額固定で、ユーザー上限・ストレージ上限がわかりやすい
• ⚠️ 任意プラグインの追加は不可（必要な拡張がある場合は要注意）
• ⚠️ 復元できる範囲に限界がある（“誤操作”は基本的に自力でリカバリ設計が必要）

プランの見方（初心者向けの要点）

My Redmineは「月額料金＋上限（ユーザー数・ストレージ）」で考えると迷いません。

• 小規模〜標準：まずは下位プランで開始し、添付ファイル増加で上位へ
• 添付が多い運用：ストレージ上限を先に見積もる（議事録PDFや画像が溜まりやすい）

特にRedmineは「チケット本文」よりも、添付ファイル（画像・資料・ログ）が容量を押し上げがちです。
運用ルールとして「添付はURL共有に寄せる」「ログは一定期間で整理」などを決めると、プランアップの頻度を抑えられます。

バックアップの考え方（重要）

クラウド型は“バックアップしてくれる”と思いがちですが、実際は次の2点が重要です。

• 障害対策としてのバックアップ（事業者が持つ）
• 誤操作・運用ミス対策（ユーザー側の設計が必要）

例：誤ってチケットを削除／設定を壊した／権限をミスった…などは、クラウド側の標準バックアップで救えないケースがあります。
そのため、定期的なCSVエクスポートや、移行・バックアップ取得の手段を「いざという時の保険」として把握しておくのが安全です。

Planio：連携や拡張を重視したい場合

PlanioはRedmineベースのホステッドサービスで、Redmine運用を“業務ツール一式”として整えたいときに検討しやすい選択肢です。

ざっくり特徴

• ✅ 無料トライアルありで試しやすい（クレカ不要を明示）
• ✅ SSL・継続アップデート・バックアップ・保守をプランに含める設計
• ✅ Git / Subversionなど開発運用の周辺もまとめやすい
• ✅ 解約時にSQLエクスポートを案内しており、「データを持ち出せる」設計が明確
• ⚠️ 料金は外貨建てが基本で、為替・VATなどの見え方に注意
• ⚠️ プラグイン要件はプラン次第になりやすい（必要なら事前に確認）

料金プランの見方（初心者向けの要点）

Planioはプランごとに「アクティブなユーザー数」「アクティブなプロジェクト数」「ストレージ」が決まっています。
この“アクティブ”の定義は運用次第で効いてくるので、

• 退職者・停止案件を「非アクティブ化」できる運用か
• プロジェクトの棚卸しを回せるか

を先に考えると、無駄な上位プランを回避しやすいです。

クラウド型を選ぶ際の注意点（権限・データ・バックアップ・契約）

最後に、クラウド型で失敗が起きやすい論点だけをチェックリスト化します。
ここを押さえると「思ってたのと違う…」が減ります。

権限（アクセス設計）

• ロール設計（管理者を増やしすぎない／閲覧専用の扱い）
• IP制限・SSOの要否（社内からのみアクセス、Google/Microsoft連携など）
• 外部メンバー（協力会社・顧客）を入れる場合の権限テンプレを先に決める

データ（持ち出し・保管場所）

• データ保管場所（リージョン）を要件に合わせる（国内限定/海外OK）
• エクスポート手段（CSV/SQL/移行サポートの有無）
• 添付の扱い：容量上限・最大ファイルサイズ・保持ルール

バックアップ（復元できる範囲）

• 「障害復旧」はカバーされても、誤操作は対象外のことがある
• 復元の粒度（DB全体？ 添付だけ？）と保持期間を把握しておく

契約（コストの落とし穴）

• 初期費用の有無、日割りの有無、長期割引、オプション課金
• 解約の条件（締め日、データ受け取り手順、移行の支援範囲）
• サポート窓口（日本語/英語、対応時間、問い合わせ回数の目安）

主要2サービスの違いを超ざっくり比較

観点	My Redmine	Planio
データ保管場所	日本国内を明示	ドイツ国内を明示
無料お試し	あり（最大2ヶ月）	あり（30日）
プラグイン自由度	持ち込み不可（導入済みのみ）	プラン・要相談になりやすい
バックアップ/復元	障害対策中心、誤操作復元は基本対象外	バックアップを提供、解約時のSQLエクスポート案内あり
向く人の傾向	「日本語・国内運用・手間削減」を優先	「周辺機能や連携も含めて整えたい」人向け

導入手順の選び方（最短ルートから本格運用まで）

Redmineの導入方法は大きく4つあります。結論から言うと、初心者が失敗しにくいのは次の流れです。

• まずは テンプレ／プリセット で動かして「運用の型」を作る
• 本格運用で再現性や移行性が必要なら Docker
• 自由度と深い理解が必要なら 手動インストール
• 複数台・継続運用まで見据えるなら Ansible等で自動化

「どれが正解か」ではなく、いまの目的（早く使う／長く守る／移す／増やす）で選ぶのがコツです。

テンプレ／プリセットで立ち上げる（最速で開始）

VPS側に用意された「アプリイメージ」「スタートアップスクリプト」などで、OS作成と同時にRedmineを入れてしまう方法です。
最短で“使える状態”に到達しやすいのが最大のメリット。

ざっくり手順（初心者でも迷いにくい流れ）

1. VPSを作成（テンプレ／スクリプトを選択）
2. 公開範囲を決める（例：最初は社内IPだけ許可）
3. 初期情報を確認（管理者パスワード、URL、開放ポートなど）
4. 初回ログインして adminパスワード変更
5. HTTPS（SSL）・メール通知（SMTP）・バックアップ方針を設定
6. テスト用にチケットを作り、通知・添付・検索が動くか確認

向いている人

• 「とにかく早く運用を始めたい」
• 手順書より、まず画面を触ってルールを決めたい
• Redmineに慣れていないので、構築で燃え尽きたくない

注意点（テンプレ導入で詰まりがちなところ）

• “テンプレで入る構成”が固定になりやすい（DB種類、Webサーバー構成など）
• 初期構築が早い分、バックアップと更新運用が後回しになりがち（ここが事故の原因）
• 古い記事の手順が通らないことがある（提供方式が変わるケースがある）

Dockerで構築する（再現性と移行のしやすさ）

Dockerは「Redmine＋DB」をコンテナとしてまとめ、同じ構成を何度でも再現できます。
VPSを乗り換えるときも、基本は コンテナを移して起動に寄せやすいのが強みです。

どんな構成が初心者に現実的？

最初はこの2コンテナ構成が分かりやすいです。

• Redmineコンテナ（Webアプリ）
• DBコンテナ（PostgreSQL or MySQL）

添付ファイルは永続化が必須なので、ボリューム（ホスト側の保存領域）を必ず用意します。

最小の compose 例（雰囲気が分かる版）

services:
  redmine:
    image: redmine
    restart: always
    ports:
      - "8080:3000"
    environment:
      REDMINE_DB_POSTGRES: db
      REDMINE_DB_USERNAME: redmine
      REDMINE_DB_PASSWORD: secret
      REDMINE_DB_DATABASE: redmine
      SECRET_KEY_BASE: "change-me-long-random"
    volumes:
      - redmine_files:/usr/src/redmine/files
    depends_on:
      - db

  db:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: redmine
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: redmine
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  redmine_files:
  db_data:

Dockerが向く人

• 今後、別VPSへ移す可能性がある（移行の痛みを減らしたい）
• 検証→本番の環境差分を減らしたい
• チームで「同じ手順」を共有して運用したい

Dockerの注意点（本番でハマりやすい）

• SQLite構成は手軽ですが、複数人の本番運用に不向き（DBコンテナ推奨）
• コンテナを消すとデータも消えるので、ボリューム設計が最重要
• 直公開より、Nginx等でHTTPS終端（リバプロ）にするほうが運用しやすいことが多い
• アップデートは「イメージ更新→起動→DBマイグレーション」が絡むため、更新手順を決めてから本番に入ると安全

手動インストール（自由度最大・学習コスト高め）

OSにログインし、Ruby、DB、Webサーバー、Redmine本体を自分で揃える方法です。
自由度は最大ですが、初心者は「動いたけど保守できない」に陥りやすいので、目的が明確な場合におすすめです。

手動が向く人

• 既にLinux運用に慣れていて、構成を細かく最適化したい
• 社内要件で「このOS／このWebサーバー構成」が決まっている
• プラグインや周辺ツール（監視、ログ収集、SSO等）まで含めて設計したい

手動の基本ステップ（やることの全体像）

• DB（PostgreSQL / MySQL）を用意して接続設定
• Ruby環境と必要ライブラリを整備
• Redmine本体配置 → 依存関係インストール → DB初期化・マイグレーション
• Webサーバー（例：Passenger / Puma＋Nginx）で常駐化
• HTTPS、メール通知、バックアップ、ログ管理、更新手順を確立

注意点

• 依存関係が多いので、手順を残さないと 次回更新で再現できない
• プラグインを入れるほど、更新時の互換性確認が必要になる
• 「構築が完了＝運用が完成」ではなく、更新・復旧・監視までがセット

Ansible等で自動化する（運用負担を下げる）

Ansibleは、手動インストールの手順を「コード化」して再現できるようにする方法です。
本番運用に入るなら、最終的にここへ寄せると強いです。

どういう時に効く？

• メンバーが増え、担当が変わっても同じ状態を作りたい
• 検証環境（ステージング）を定期的に作り直したい
• OS更新やRedmine更新を 定例作業として回したい

初心者が失敗しない導入パターン

• いきなり全部自動化しない
  → まずは「OS初期設定」「FW」「ユーザー作成」「バックアップ」など土台から
• Redmineは段階的に
  → ①DB準備 → ②Redmine起動 → ③HTTPS/SMTP → ④バックアップ → ⑤更新手順

注意点

• Ansibleの役割（role）はコミュニティ製も多く、対応OSやRedmineバージョンが古いことがあります
• “動く”より“運用できる”が目的なので、変数の管理（Vault等）と、復旧手順の整備が重要

それぞれの向き不向き比較

方法	立ち上げ速度	再現性（同じ環境を作れる）	自由度	運用の手間	こんな人におすすめ
テンプレ／プリセット	◎	△	△	○	最短で開始して、まず運用ルールを作りたい
Docker	○	◎	○	○	移行・再現性・チーム共有を重視したい
手動インストール	△	△（手順書次第）	◎	△	構成を細部まで最適化したい／学習目的
Ansible等の自動化	○（最初は△）	◎	◎	◎	長期運用・複数環境・属人化回避を狙いたい

運用で差がつくポイント（安定稼働・セキュリティ・拡張）

Redmineは「導入したら終わり」ではなく、継続運用の設計が品質になります。
ここでは、初心者でも“事故らない運用”に寄せるための要点を、手順ベースでまとめます。

バックアップ設計（DB／添付／設定を分けて守る）

Redmineのバックアップは、最低でも DB と 添付ファイル の2本立てが必須です。
それに加えて、復旧を現実的にするなら 設定ファイル・プラグイン もセットで守ります。

何をバックアップするか（最低ライン＋実務ライン）

• 最低ライン（これがないと復旧できない）
  • DB（チケット、Wiki、ユーザー、設定、履歴）
  • 添付ファイル（アップロード資料）
• 実務ライン（復旧のスピードと再現性が上がる）
  • Redmineの設定（例：メール通知などの設定ファイル）
  • plugins / themes（カスタム・拡張を戻すため）
  • Webサーバー設定（Nginx/Apache などの設定）
  • cron（定期処理があるなら）

バックアップ頻度の決め方（迷ったらこの考え方）

• DBは“変更が多い” → こまめに（毎日〜数時間おき）
• 添付は“容量が大きい” → 差分・世代管理を意識（毎日差分＋週次フルなど）
• 設定・プラグインは“変更が少ない” → 変更時に必ず保存（＝変更管理に組み込む）

ありがちな失敗を潰すチェック

• ✅ バックアップは 別ストレージ（別筐体/別リージョン） に置く
• ✅ 「取れている」だけでなく、復元テストを1回はやる
• ✅ バックアップの世代（何日分残すか）を決める
• ✅ いつ・誰が・どこへ復元するか（権限含む）を決める

アップデート方針（Redmine本体・OS・ミドルウェア）

更新は「止めない」ことより、安全に更新できる型を作ることが大事です。
おすすめは、次の3層を分けて管理するやり方です。

更新対象を3つに分ける

• Redmine本体（Railsアプリとしての更新）
• OS（セキュリティ更新、パッケージ更新）
• ミドルウェア（DB、Webサーバー、Ruby周り、SSLなど）

更新の基本フロー（テンプレ）

1. 要件確認（新バージョンの前提：Ruby/DBなど）
2. バックアップ（DB＋添付＋設定）
3. 検証環境で事前確認（できれば同じ構成で）
4. 本番更新（手順は固定化）
5. DB更新・動作確認（ログイン、チケット作成、通知、添付）
6. 問題があればロールバック（戻し方も手順化）

実務のコツ

• 「毎回やること」を減らすほど安全になります
  → DockerやAnsibleに寄せる価値がここで効きます。
• “更新しない”は最大のリスク
  → 少なくとも セキュリティ修正を含む更新情報 は定期的にチェックする運用に。

監視と通知（死活・容量・レスポンス・エラー）

監視は高機能にする前に、「気づける」状態を作るのが最優先です。

最低限やるべき監視（これだけで事故が減る）

• 死活監視（HTTPが返るか、ログイン画面が出るか）
• ディスク容量（添付で埋まりやすい）
• メモリ使用量（足りないと一気に不安定に）
• DB稼働（DBが落ちるとRedmineは動けない）
• エラーログ監視（アプリログ/Webサーバーログ）

通知設計のコツ

• 通知先は最低2系統（メール＋チャットなど）
• “警告”と“致命”を分ける（全部緊急だと誰も見なくなる）
• 容量は早めに警告（例：80%で警告、90%で緊急）

アクセス制御（VPN／IP制限／二要素／権限設計）

Redmineは業務情報の集約点になりやすいので、入り口を絞るだけで安全性が大きく上がります。

入口（ネットワーク）でまず守る

• 公開範囲を絞る
  • 可能なら VPN経由、難しければ IP制限
• 不要なポートは閉じる（FW/セキュリティグループ）
• SSHは鍵認証中心＋管理者の権限を絞る

アプリ側（Redmineの権限）で守る

• 権限ロールを最初に作る（例：閲覧のみ／一般／管理）
• プロジェクトの公開範囲を安易に広げない
• 管理者アカウントを増やしすぎない（運用上の事故が増える）

補足（現実的な落としどころ）

• 二要素認証やSSOは、環境・サービス次第で実現方法が変わります
  → まずは VPN/IP制限＋HTTPS＋権限設計 を固めるだけでも効果が大きいです。

プラグイン運用の勘所（互換性・検証環境・更新手順）

プラグインは便利ですが、運用を壊す原因にもなります。
導入前に 互換性と更新の型 を決めると、後で詰まりにくいです。

導入前チェック（これだけは見る）

• 対応Redmineバージョンが明記されているか
• 更新頻度（放置されていないか）
• 既知の不具合・注意点（IssueやREADMEで把握）
• セキュリティ修正が含まれる更新があるか

運用の型（おすすめ）

• 本番に入れる前に、同じ構成の検証環境で試す
• プラグインは「増やす」より「厳選する」
• 更新手順を固定化（停止 → バックアップ → 更新 → 動作確認 → 失敗時復旧）

速度が落ちたときの見直し（DB・ストレージ・メモリ）

「遅い」の原因は、だいたい次の順で見つかります。焦ってサーバー増強する前に切り分けるのがコツです。

切り分けの順番（初心者向け）

1. ディスク容量・I/O（添付が増えると最初に効く）
2. メモリ不足（スワップが増えると体感が急落）
3. DB負荷（履歴・検索・集計で重くなる）
4. プラグイン影響（画面表示やフックで遅くなる）
5. ネットワーク/HTTPS終端（構成次第）

すぐ効く対処（“まずやる”）

• 添付の運用ルール見直し（大きいログは外部保管など）
• プラグインを一時無効化して影響確認
• DBのチューニングより前に、メモリ増強が効くことが多い
• 重い操作（検索・一覧表示）の再現条件を記録しておく

障害時の復旧手順（スナップショット／復元の手順化）

復旧は、気合ではなく 手順書 で決まります。
最低限、次の“型”だけでも文章化しておくと、復旧スピードが変わります。

まず決める（RTO/RPOの簡易版）

• RTO：何時間以内に復旧させたいか（例：2時間）
• RPO：どこまでデータ損失を許容するか（例：直近6時間）

復旧手順テンプレ（コピペ用）

1. 状況判断：Redmineが落ちたのか、DBか、ネットワークか
2. 影響範囲：全員か、特定プロジェクトか
3. 一次対応：再起動／設定戻し／直近変更の取り消し
4. 復旧方針の決定：
   • スナップショットで丸ごと戻す（早いが巻き戻りが発生）
   • DB＋添付を復元する（時間はかかるが復元粒度を調整できる）
5. 復旧後チェック：ログイン、チケット作成、添付、通知、権限
6. 再発防止：原因、再発条件、恒久対策、手順書更新

よくある落とし穴

• スナップショット復元は速いが、巻き戻り分の作業が消える
  → RPOとセットで判断できるようにしておくのが大切です。

規模別おすすめ構成（チームの成長に合わせて選ぶ）

Redmineの構成は、最初から“完璧な正解”を作るよりも、チーム規模に合わせて破綻しない形にしておき、詰まりが出たら段階的に分離・拡張するのが現実的です。

ここでは「セルフホスト前提」で、ありがちな詰まり方から逆算しておすすめ構成を整理します。

個人〜少人数（〜10名）で現実的な落とし所

最初は 1台のVPSにまとめる構成が分かりやすく、運用も軽くて済みます。
“シンプルに保つこと”が最大の安定策です。

おすすめ構成（まずはこれでOK）

• VPS 1台（アプリ＋DBを同居）
• DB：PostgreSQL または MySQL/MariaDB
• Web：Nginx（リバプロ）＋ Redmine（Puma等）
• 添付：ローカル保存（後から分離できる設計にしておく）
• バックアップ：DB＋添付（files）を分けて取得

スペック目安（迷う人向けのざっくり）

• vCPU：2
• メモリ：4GB（不安なら最初から8GBでも損しにくい）
• ストレージ：50〜100GB（添付が増えるなら早めに余裕を）

ここだけは最初に決めておくと失敗が減る

• 公開範囲：いきなり全世界公開にしない（VPN / IP制限を優先）
• バックアップ：
  • DBは毎日（重要なら数時間おき）
  • 添付は毎日差分（容量が増えやすい）
• プラグイン：最小限から（増やすのは“運用が回ってから”）

中規模（10〜50名）で詰まりやすいポイントと対策

10名を超えてくると「遅い」「重い」「復旧が怖い」が現実味を帯びます。
原因はだいたい、メモリ不足・ディスクI/O・DB負荷・プラグイン肥大のどれかです。

詰まりポイント1：添付の増加でディスクが苦しくなる

対策の方向性は2つです。

• まずやる：ストレージ増強／監視（容量80%で警告）
• 次の一手：添付を別ボリュームに分ける（復旧が楽になる）
• 将来的：オブジェクトストレージ等に逃がす（運用設計が必要）

詰まりポイント2：更新と検証が回らない

人数が増えるほど、更新は「やる／やらない」ではなく手順化できるかが重要です。

• 検証環境（ステージング）を1つ作る
  • 本番と同じ構成で、Redmine本体更新・プラグイン更新を先に試す
• “戻し方”まで含めて更新手順にする
  • スナップショット復元で戻すのか
  • DB＋添付を復元するのか

おすすめ構成（中規模の現実解）

• VPS 1台にまとめたままでも良いが、余裕は持つ
  • vCPU：4 目安
  • メモリ：8〜16GB 目安
• 余裕が出てきたら、先に“運用の面倒”を分離
  • 添付を別ボリュームへ
  • バックアップ保存先を別ストレージへ

中規模で効く運用ルール（地味だけど効く）

• 添付の扱いを決める（ログや動画は別保管、など）
• “重い画面”が出たら条件をメモしておく（再現できないと改善できない）
• プラグインは「増やす＝維持コスト」だと全員で合意する

大規模（50名〜）で検討すべき構成（DB分離・容量・冗長化）

50名を超えると、1台構成は「動くけど不安」「止まると影響が大きい」になりやすいです。
この段階では、性能のためだけでなく“障害時の切り分け・復旧速度”のために分離します。

おすすめ構成（基本形）

• アプリ（Redmine）サーバー：1台以上
• DBサーバー：別筐体に分離（ここがボトルネックになりやすい）
• 添付ストレージ：別ボリューム／別サーバー（容量と復旧を考えて設計）
• 監視：死活＋容量＋レスポンス＋エラー（通知先は複数）

冗長化を考える順番（初心者でも判断しやすい）

1. バックアップの強化（復元できることが最優先）
2. DBの保護（レプリケーションやバックアップの世代強化）
3. アプリ側の冗長化（ロードバランサ＋複数台）
4. ストレージの冗長化（要件次第。ここはコストが跳ねやすい）

“大規模あるある”の落とし穴

• 構成を分けたのに、復旧手順が1台構成のまま
  → 障害時に「どこが悪いか分からない」になりがちです。
• プラグインが増えすぎて、更新時に止まる
  → 検証環境と更新手順（ロールバック含む）を先に作るのが安全です。

将来の移行を楽にする設計（最初に決めておくこと）

「いずれ別VPSへ」「いずれクラウドへ」を想定するなら、最初から次の4点を押さえるだけで移行難易度が大きく下がります。

1) データの置き場所を“分けて考える”

• DB（チケット・履歴）
• 添付（files）
• 設定（database.yml 等）
• プラグイン／テーマ（plugins / themes）

特に添付は、後から移すのが面倒になりやすいので、早い段階で
「どこに置くか」「どこへ逃がせるか」を決めておくと楽です。

2) “設定の外出し”を意識する

• 環境変数や設定ファイルで管理し、手作業の設定を減らす
• パスワード・秘密鍵はコードや手順書に直書きしない（運用ルール化）

3) 変更管理（いつ何を変えたか）を残す

• プラグインの追加・更新
• 設定変更（メール、権限、HTTPS周り）
• OS/ミドルウェア更新

これが残っていると、障害時も移行時も“戻す／再現する”ができます。

4) いきなり凝らない（でも逃げ道は作る）

• 最初はテンプレで開始でもOK
• ただし「データ（DB＋添付）が取り出せる」「戻せる」状態だけは最初から作る
  → ここができていれば、後からDocker化・分離・移行が現実的になります。

よくある疑問（検索されやすい論点をまとめて解消）

共用サーバー運用は現実的に可能？

「不可能ではないが、初心者向きではない」というのが結論です。

共用サーバーでも、以下が揃えば動く可能性はあります。

• SSHが使える（bundle install や設定変更が必要）
• Ruby / Bundler / DB（PostgreSQL/MySQL）を要件どおりに用意できる
• Webアプリとして動かせる仕組み（Passenger等）が許可されている
• cron（定期処理）やログ閲覧ができる

ただし共用サーバーは、そもそも

• root権限がなく、依存関係で詰まりやすい
• 常駐プロセスや構成の自由度に制限がある
• 速度低下時に原因切り分けが難しい

…などの理由で、運用を続けるほど負債になりがちです。
最初からVPS（またはクラウド型Redmine）で始める方が、結果的に近道になりやすいです。

最低限どれくらいのメモリが必要？

RedmineはRailsアプリなので、メモリが少ないと「遅い」より先に「不安定」になりがちです。迷ったら次の目安で考えると外しにくいです。

• まず動かす最低ライン：2GB
  • 個人利用・検証・少人数で「軽めに使う」なら成立することはある
• 実務のスタート地点：4GB推奨
  • 〜10名程度で、通知や添付が増えても運用しやすい
• 中規模寄り：8GB〜
  • 10〜50名、プラグイン導入、検索・履歴が増える前提なら現実的
• 大規模：16GB〜（＋DB分離も検討）
  • 50名〜、負荷が高い操作が増える、停止時の影響が大きい場合

ポイントは「最初の最低ライン」より、“増やせる前提（スケールアップ）”と監視です。
メモリが足りない兆候（スワップ増加、レスポンス急落）が見えたら、先に増やすのが効きやすいです。

HTTPS化はどう進める？

HTTPS化は「暗号化」だけでなく、ログイン情報や運用情報を守る基本です。進め方はシンプルに次の順が安全です。

1. ドメインを決める
   • redmine.example.com のようにサブドメイン運用が管理しやすい
2. DNSを設定する
   • Aレコード（IPv4）でVPSのIPへ向ける
3. 通信の入口を整える
   • 80/443を開ける（必要最小限で）
4. 証明書を用意する
   • Let’s Encrypt（certbot等）または、提供側のHTTPS機能を使う
5. Webサーバー側でHTTPSへ誘導
   • HTTP→HTTPSリダイレクト
6. Redmine側のURL設定を揃える
   • メール通知のリンクが正しくなるように、管理画面で「ホスト名/プロトコル」を正しく設定

「Redmineを直接インターネットに晒す」のではなく、Nginx等でHTTPS終端（リバプロ）に寄せると、運用が安定しやすいです。

メール通知が飛ばない／届かないときの切り分け

メールは「設定ミス」か「到達性（迷惑メール/ブロック）」のどちらかで止まることが多いです。次の順で切り分けると早いです。

1) Redmine側の設定確認（まずここ）

• config/configuration.yml にSMTP設定が入っているか
• 送信元アドレス（From）が設定されているか
• 管理画面で通知の対象（どの操作で通知するか）が有効か
• 「ホスト名/プロトコル」が正しいか（リンクが変になる原因）

2) サーバー→SMTPの疎通確認（次にここ）

• SMTPサーバーへ接続できるか（ポート、TLS/STARTTLS）
• 認証情報（ユーザー/パスワード）が正しいか
• VPS側で 25番ポートが制限されていないか
  → 制限がある場合は、587/465を使う外部SMTPを選ぶのが現実的です

3) “届かない”問題の確認（最後にここ）

• 迷惑メールへ入っていないか
• 送信ドメインのSPF/DKIM/DMARCが未整備で弾かれていないか
• 同じ宛先に短時間で大量送信していないか（レート制限）

コツは、「送信エラーが出ているのか」「送れているが届かないのか」をログで分けることです。
“送れているが届かない”なら、Redmineよりメール側（到達性）の問題であることが多いです。

別VPSへ引っ越すとき、何を移せばいい？

Redmineの引っ越しは、必要なものがはっきりしています。最低限は次の2つです。

• DB（データベース）
• 添付ファイル（attachments_storage_path）

実務では、さらに“復旧や再現が楽になるセット”として次も移します。

• config/database.yml（接続先の再設定に使う）
• config/configuration.yml（メール通知、添付保存先など）
• plugins/ と themes/（入れている場合）
• Webサーバー設定（Nginx/Apache）、SSL証明書（運用に応じて）
• cron（定期処理を入れている場合）

引っ越し手順の考え方（失敗しにくい）

• 同じRedmineバージョン同士で移すのが一番安全
  → バージョンも上げるなら、移行とは別に「アップグレード手順」で進める
• “移行だけ”なら、基本的にDB移行とファイル移行が中心
• バージョンを変えるなら、アップグレードの手順に従ってDBマイグレーションも行う

自動バックアップはどの範囲まで必要？

結論としては、「DB＋添付」までは必須、その上で「復旧速度」を上げたいなら範囲を広げます。

必須（これがないと復旧不能）

• DBのバックアップ
• 添付ファイルのバックアップ（attachments_storage_path）

あると強い（復旧が早くなる）

• configuration.yml（メール、添付パス等の設定）
• plugins/ themes/（カスタムがある場合）
• Webサーバー設定、TLS証明書（環境により）

“自動バックアップ”の現実的な組み合わせ

• VPSのスナップショット（サーバー丸ごと）
  • 速いが、巻き戻り（RPO）が発生しやすい
• アプリ運用としてのバックアップ（DBダンプ＋添付同期）
  • 運用の手間は増えるが、復元粒度を調整しやすい

おすすめは「スナップショットだけ」に寄せず、DBダンプ＋添付バックアップを別経路でも持つことです。
そして最重要なのは、一度でいいので復元テストをすること。取れているつもりが一番危険です。

まとめ：Redmine運用で後悔しないサーバーの決め方

Redmineのサーバー選びで失敗しやすいのは、「料金の安さ」や「テンプレがあるか」だけで決めてしまい、運用（バックアップ・更新・復旧）まで含めた“継続可能性”を見落とすパターンです。
後悔を避けるために、判断は次の順で組み立てるのがいちばん堅実です。

1) まず「運用責任」をどこまで持つか決める

最初にここが決まると、選択肢が一気に整理されます。

• サーバー管理をできるだけ避けたい
  → クラウド型（ホステッドRedmine）を優先
  • メリット：構築・保守の手間が少ない
  • 注意：自由度（プラグイン等）が制限されやすい
• データ管理やカスタマイズを自分で握りたい
  → VPS（セルフホスト）を優先
  • メリット：構成・拡張の自由度が高い
  • 注意：更新・障害対応は自分の責任になる

✅ 迷ったら「管理を避けたいならクラウド」「自由度が必要ならVPS」で大枠を決めるとブレません。

2) VPSなら「最短導入」より「運用で詰まらない」基準で決める

テンプレ（アプリイメージ／スタートアップスクリプト）は確かに便利ですが、長期運用で効いてくるのは次の観点です。

• 復旧の速さ：スナップショットやイメージ保存など“戻せる仕組み”があるか
• バックアップの組みやすさ：DBと添付を分けて守れるか（保存先を分離しやすいか）
• 拡張のしやすさ：メモリ増設・ディスク拡張・プラン変更がやりやすいか
• 情報量とサポート：困ったときに詰まらないか（公式/コミュニティ/サポート）

🎯 選び方のコツは「今の最小構成」だけでなく、“増えたときに逃げ道があるか”で見切ることです。

3) プランは「平均」ではなく「増えやすい要素」から逆算する

Redmineは、使い方によって伸びる場所が変わります。特に影響が大きいのはここです。

• 添付ファイル：議事録PDF、画像、ログでストレージが増えやすい
• 履歴と検索：人数や運用期間が増えるとDB負荷が効いてくる
• プラグイン：便利だが、更新・互換性チェックの手間が増える

最初から大きくしすぎる必要はありませんが、次の姿勢が大事です。

• 小さく始めて、詰まる前に増強できる前提にする
• 監視で「容量」「メモリ」を早めに検知できる状態にする

4) 導入方法は「再現性」と「移行性」を意識して選ぶ

導入手順は、目的で選ぶと失敗しにくいです。

• 最速で開始：テンプレ／プリセット
  • 最初のハードルが低い。まず運用ルール作りに集中できる
• 移行しやすさを重視：Docker
  • 構成の再現がしやすく、引っ越しや検証環境の用意が楽になりやすい
• 自由度最大：手動インストール
  • 学習コストは高いが、細部まで最適化したい場合に向く
• 運用負担を下げる：Ansible等で自動化
  • 長期運用や複数環境で、属人化を避けたい場合に強い

✅ 初心者が後悔しにくいのは「テンプレで開始 → Docker/自動化で固める」という段階的な進め方です。

5) 最後に「運用できるか」をチェックしてから契約する

契約前に、ここだけは自分に問い直すのがおすすめです。

• DBと添付のバックアップを分けて取れる（保存先も分離できる）
• 更新の方針がある（本体・OS・ミドルウェアをどう更新するか）
• 復旧手順を説明できる（スナップショットで戻す？DB復元？）
• 公開範囲を絞れる（VPN/IP制限、権限設計）
• 引っ越し時に何を移すか分かっている（DB＋添付＋設定＋プラグイン）

ここが曖昧なまま進めると、あとで「怖くて更新できない」「復旧できない」が起きやすいです。
逆に言えば、ここさえ押さえれば、どのVPSを選んでも大きく外しにくくなります。

---

最後にひとこと。Redmine運用は、最初の「サーバー選び」よりも、運用の型（バックアップ・更新・監視・復旧手順）を作れるかで勝負が決まります。
この記事をベースに、あなたの体制と将来規模に合ったVPSを選び、安心して長く使えるRedmine環境を作っていきましょう。