

自宅サーバーで CI/CD(継続的インテグレーション・継続的デリバリー)パイプラインを構築することは、現代の開発者にとって非常に有益なスキルであり、コスト削減と技術的な自由度を得るための重要な手段です。CI/CD とは、ソフトウェア開発プロセスにおいて、コードの変更が自動的にテストされ、ビルドされ、環境にデプロイされる自動化されたワークフローを指します。これにより、手動でのミスが減り、リリースサイクルが劇的に短縮されます。通常、大規模な企業では GitHub Actions や GitLab CI などのクラウド型サービスを利用しますが、自宅サーバーで自前の CI/CD を構築することで、データプライバシーの完全な確保や、高額な実行時間料金の回避が可能になります。
特に自宅サーバーでの構築を推奨する理由は多岐にわたります。第一にコスト削減です。GitHub Actions の無料枠は個人の利用には魅力的ですが、公開リポジトリでは無料だがプライベートリポジトリでは制限があります。また、ビルド時間の経過とともに課金が発生するケースもあり、大規模な CI 運用を行う企業や個人開発者にとっては費用対効果が低下することがあります。自宅サーバーであれば、初期ハードウェア投資のみで、ほぼ無限のビルド時間を確保できます。第二にプライバシー保護です。自社のソースコードや機密情報をクラウド上の第三者サーバーにアップロードせずに処理できるため、セキュリティリスクを最小限に抑えられます。
さらに、カスタムハードウェアの有効活用も大きなメリットです。自宅サーバーであれば、NVIDIA の GPU や特殊なアクセラレータボードなどを CI/CD 環境に直接接続し、AI モデルのトレーニングや暗号化計算などのリソース集約的なビルドをローカルで実行できます。検証環境として今回は Ubuntu 24.04 LTS を採用します。これは 2024 年 4 月にリリースされ、2029 年までサポートが保証される長期サポート版です。また、Docker コンテナ技術を活用することで、リソースの隔離と軽量な実行が可能になります。ハードウェアとしては、コンパクトかつ省電力で高い性能を発揮する Raspberry Pi 5 を筆頭に、x86 ベースのデスクトップ PC やサーバーも対象とし、それぞれの状況に合わせた最適な構成を提案していきます。
自宅サーバーでの CI/CD 構築において、どのツールを選ぶかはプロジェクトの規模や技術スタックに大きく依存します。主要な候補として GitHub Actions Self-Hosted Runner、Drone CI、Jenkins、Gitea Actions、Woodpecker CI が挙げられます。各ツールには明確な得意分野とトレードオフが存在するため、開発チームのスキルセットやリソース制約に合わせて慎重に選択する必要があります。ここでは、機能面だけでなく運用コストや学習コストも考慮した包括的な比較を行います。
まず GitHub Actions Self-Hosted Runner は、GitHub とのネイティブな統合が最大の強みです。既存の GitHub リポジトリをそのまま利用でき、ワークフロー記述方法を変更する必要がありません。しかし、GitHub のクラウド側との通信が必要であり、完全なオフライン運用には適していません。Drone CI は Docker ネイティブで設計されており、軽量でスケーラブルなのが特徴です。設定ファイルが YAML で簡潔に記載できるため、初心者でも理解しやすい傾向があります。一方、Jenkins は老舗のツールとしてプラグイン生態系が極めて豊富ですが、初期設定やセキュリティ管理に手間がかかるという弱点があります。
以下に、主要な CI/CD ツールの特性を比較した表を示します。この比較は 2026 年 4 月時点の最新バージョンおよび一般的な運用環境を基準としています。各項目の詳細については後述のセクションで解説しますが、まずは全体像を把握することが重要です。特に「ランナー形式」と「設定形式」の違いは、導入後のメンテナンス負荷に直結する重要な要素です。
| 比較項目 | GitHub Actions Self-Hosted | Drone CI | Jenkins | Gitea Actions | Woodpecker CI |
|---|---|---|---|---|---|
| ランナー形式 | Agent ベース(GitHub 接続) | Runner ベース(WebSocket/HTTP) | Controller-Agent | Runner ベース(Gitea 内蔵) | Runner ベース |
| Docker 対応 | 標準サポート(Docker-in-Docker 可) | ネイティブ・第一級市民 | プラグイン依存 | 標準サポート | 標準サポート |
| 設定形式 | .github/workflows/*.yml | .drone.yml (YAML) | Jenkinsfile (Groovy/YAML) | .gitea/CI.yml (Gitea 内蔵) | .woodpecker.yml |
| プラグイン/アクション | 数万種類(市場最大) | プラグイン少・カスタム作成推奨 | 数千種(豊富だが古め) | GitHub Actions 互換 | ドローンフォーク・軽量 |
| リソース使用量 | 中〜高(ランナー起動時) | 低(軽量コンテナ) | 高(Java ベース) | 低〜中 | 低(Go ベース) |
| セットアップ難易度 | 中(GitHub 設定が必要) | 低〜中(Docker Compose) | 高(初期設定・更新頻繁) | 中(Gitea 連携必要) | 低〜中 |
この表からもわかるように、ツールによってアーキテクチャが大きく異なります。Jenkins は Java ベースであるため、起動に時間がかかる傾向があり、メモリ使用量も多めです。一方、Drone や Woodpecker CI は Go で書かれており、コンテナとして軽量に動く設計となっています。GitHub Actions Self-Hosted Runner の場合、ランナープロセス自体が GitHub 本体と永続的な接続を維持するため、ネットワークの安定性が求められます。また、設定形式も重要で、Groovy スクリプトを使う Jenkins は柔軟性が高い反面、セキュリティリスク(スクリプト実行によるコードインジェクション)に注意が必要です。
CI/CD ツールを自宅サーバー上に構築する際、最も懸念される点の一つがセキュリティリスクです。ビルド環境は外部からの攻撃に対して常に曝露されている可能性があり、また内部プロセスが誤ってシステム全体にアクセスしてしまう「特権昇格」のリスクも無視できません。GitHub Actions Self-Hosted Runner は、ランナープロセスが GitHub によって管理・監視されるため、クラウド側のセキュリティアップデートの影響を受けやすい一方で、サンドボックス機能が強化されています。Drone CI や Jenkins のような完全セルフホスト型では、管理者が自らサーバーのセキュリティを担保する必要があります。
特に Docker-in-Docker(DinD)環境での運用は注意が必要です。ビルドプロセス内で Docker コマンドを実行する場合、コンテナ内でホストの Docker ソケットにアクセスする権限が必要となります。この設定を行うと、ビルドされたコンテナからホストシステムを完全に制御できてしまうため、極めて危険です。2026 年時点では、Kaniko や Buildah といったコンテナイメージ構築ツールを活用し、Docker デーモンへの直接アクセスを避けるセキュリティベストプラクティスが推奨されています。
以下の表は、各ツールのセキュリティモデルと権限分離の仕組みを比較しています。自宅環境での運用において、どの程度の隔離が必要か判断する際の指標となります。特に「秘密情報の扱い」と「ネットワーク分離」に関する記述は、機密情報を含むプロジェクトで必須の確認事項です。
| セキュリティ項目 | GitHub Actions Self-Hosted | Drone CI | Jenkins | Gitea Actions | Woodpecker CI |
|---|---|---|---|---|---|
| 権限分離 | Runner プロセス単体で実行可能 | コンテナベースで隔離 | プラグイン依存・監査困難 | コードベース同様に管理 | 軽量コンテナ隔離 |
| シークレット管理 | GitHub Secrets API 経由 | ドキュメント変数・外部 Vault | Job-specific Variables | Gitea Secrets | Env Variables/Secrets |
| ネットワーク分離 | 実行時の IP マスク可能 | コンテナネットワーク制御 | ジェネリックネットワーク | Gitea ネットワーク依存 | Docker Network |
| 脆弱性対策 | GitHub 側パッチ適用優先 | ユーザーによる更新管理 | プラグイン更新必須 | 同 GitHub Actions | ユーザー更新管理 |
Gitea Actions や Woodpecker CI のような、完全にローカル完結するシステムでは、GitHub のようなクラウド側のセキュリティ監視がありません。したがって、OS レベルのパッチ適用や Docker イメージの定期的なスキャンを運用側が行う必要があります。また、Jenkins の場合、歴史的経緯から古いバージョンのプラグインが依存関係として残存していることが多く、そこからの攻撃ベクトルが存在します。自宅サーバーであれば物理的なアクセス制御が可能ですが、ネットワーク経由での外部接続がある場合はファイアウォール設定も必須です。
GitHub Actions Self-Hosted Runner を自宅サーバーで構築する手順は、比較的標準化されており、ドキュメントが充実しています。まず前提条件として、サーバーに Docker および Docker Compose がインストールされている必要があります。ここでは Ubuntu 24.04 LTS をベースとした具体的なコマンドライン手順を解説します。GitHub のリポジトリ設定画面からアクションページへ移動し、「Set up a self-hosted runner」を選択することで、ランナーの登録トークンが生成されます。
まず、サーバー上に Runner の専用ディレクトリを作成し、GitHub 公式の Runner アーカイブを展開します。バージョンは常に最新安定版を使用するのが基本ですが、2026 年時点では v3.x が標準となっているでしょう。展開後は、GitHub で発行されたトークンを利用して登録スクリプトを実行します。この際、./config.sh コマンドでサーバーのラベルや名前を指定し、ネットワーク設定を行います。特に自宅環境では、ランナーが GitHub のクラウドと通信するための outbound 接続(ポート 443 など)がファイアウォールで許可されていることを確認してください。
登録後、プロセスとして常駐させるための systemd サービスを作成します。これにより、サーバー再起動時に自動的に Runner が起動し、ビルド要求を待ち受ける状態になります。また、Docker ネイティブな実行環境が必要な場合、Runner 設定ファイル内で Docker のラッパーを設定するか、Docker コンテナ上で Runner を動作させる構成が推奨されます。以下に、Ubuntu 24.04 でのインストール手順とサービス登録のコマンド例を示します。
# 1. ユーザー作成とディレクトリ準備
sudo useradd -m runner
mkdir -p /home/runner/actions-runner
cd /home/runner/actions-runner
# 2. Runner アーカイブのダウンロード(最新バージョンを GitHub から取得)
RUNNER_VERSION="latest"
wget https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz
tar xzf actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz
# 3. Runner の設定と登録(トークンは GitHub リポジトリから取得)
./config.sh --url "https://github.com/your-username/your-repo" \
--token "YOUR_RUNNER_TOKEN_HERE" \
--name "home-runner-pi5" \
--labels "linux,pi5,docker"
# 4. systemd サービスの登録
sudo ./svc.sh install
sudo systemctl start runner
sudo systemctl enable runner
この構成により、GitHub がワークフローをトリガーすると、自宅サーバー上の Runner が自動的に起動し、指定されたジョブを実行します。ラベル設定(--labels)は非常に重要で、特定のハードウェア要件を持つジョブ(例:ARM アーキテクチャや GPU 搭載機)にのみこの Runner を割り当てるために使用されます。また、Docker の利用を許可するためには、Runner が Docker デーモンへのアクセス権限を持っているか確認し、必要に応じて docker.sock のマウント設定を安全に行う必要があります。
自宅環境で構築した Self-Hosted Runner を活用するためのワークフロー記述は、GitHub リポジトリ内の .github/workflows/ ディレクトリに YAML 形式で保存されます。このファイルが CI の設計図となり、どのジョブをいつ実行するか、どのような条件でステップを分岐させるかを定義します。ここでは、Node.js または Bun を使用した最新の JavaScript/TypeScript プロジェクト向けのワークフロー例を紹介し、各タグの意味と役割を詳しく解説します。
基本的なワークフローでは、on: セクションでトリガーイベント(プッシュ、プルリクエストなど)を指定し、jobs: セクションでジョブの定義を行います。Self-Hosted Runner を使用するためには、各ジョブ内で runs-on: [self-hosted, linux, pi5] のようにラベルを指定する必要があります。これにより、GitHub 上で自動的にホスト型ランナーではなく、自宅サーバー上の特定のマシンのみが使用されるようになります。また、キャッシュ機能を活用することで、依存関係のインストール時間を大幅に短縮できます。
具体的なワークフロー記述例と、その各セクションの解説を提供します。この例では、ビルド前のキャッシュチェックを行い、依存パッケージが変更された場合のみインストールを実行するロジックを組み込んでいます。これにより、不要なネットワークトラフィックを削減し、ビルド時間を短縮することが可能になります。
name: Node.js CI Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
build-and-test:
name: Build and Test on Home Server
runs-on: [self-hosted, linux, pi5] # ラベルによる指定
steps:
- uses: actions/checkout@v4
# Node.js のセットアップ(指定バージョン)
- name: Setup Node.js 20.x LTS
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
# キャッシュ戦略:依存関係の保存と復元
- name: Restore Dependencies Cache
uses: actions/cache@v3
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
# ビルドとテスト実行
- name: Install Dependencies & Build
run: npm ci && npm run build
- name: Run Tests
env:
CI: true
run: npm test
このワークフローにおいて、actions/setup-node@v4 アクションは Node.js の環境を構築します。バージョン指定を行うことで、プロジェクトの依存関係と整合性を保ちます。また、cache: 属性により、npm パッケージのキャッシュが自動的に管理されます。これは、依存関係のパッケージが変更されていない限り、インストールステップをスキップできるため、自宅サーバーへの負荷を軽減します。さらに、Secrets の扱いについても考慮が必要です。テスト環境における API キーやデータベース接続情報は、GitHub レポジトリの設定画面から「Secrets」として登録し、ワークフロー内で ${{ secrets.API_KEY }} として参照することで安全に利用できます。
Drone CI は、Docker コンテナをネイティブでサポートしており、軽量かつスケーラブルな CI/CD システムです。自宅サーバー上で構築する際、GitHub Actions のような複雑なランナー管理を行わず、単一の Docker Compose ファイルでサーバー全体の構成を管理できるため、運用負荷が低い特徴があります。Drone は Server と Runner が分離した設計をしており、通常は Server 側でビルド要求を受け付け、Worker コンテナ上で実際にコードを実行します。
構築手順は非常にシンプルです。Ubuntu 24.04 サーバーに Docker および Docker Compose をインストールした後、公式が提供する drone-server と drone-runner-docker のイメージをダウンロードして起動します。設定には、Drone Server へのアクセス権限を持つ GitHub トークンや、シークレット管理用の環境変数を設定する必要があります。Drone の構成ファイルは Docker Compose を用いることで、バージョン管理が容易になります。
Drone CI の設定では、.drone.yml ファイルをリポジトリルートに配置することでワークフローを定義します。GitHub Actions と同様に YAML 形式ですが、構文が若干異なります。以下に、Docker Compose を使用した Drone CI のセットアップ例を示します。この設定により、Drone Server が常駐し、ビルド実行時に動的に Worker コンテナを作成・破棄します。
# docker-compose.yml
version: '3'
services:
drone-server:
image: drone/drone:latest
ports:
- "80:80"
- "443:443"
environment:
- DRONE_SERVER_HOST=your-home-server-ip
- DRONE_RPC_SECRET=rpc-secret-key
- DRONE_GITHUB_CLIENT_ID=github-client-id
- DRONE_GITHUB_CLIENT_SECRET=github-client-secret
volumes:
- drone-data:/data
drone-runner:
image: drone/runner:latest
command: runner
environment:
- DRONE_RPC_HOST=http://drone-server:8080
- DRONE_RPC_SECRET=rpc-secret-key
- DRONE_RUNNER_NAME=home-pi5-runner
volumes:
- /var/run/docker.sock:/var/run/docker.sock # 注意:セキュリティリスクあり
この設定では、Docker ソケットへのアクセス権限(/var/run/docker.sock:/var/run/docker.sock)が与えられています。これは Docker-in-Docker の利便性を高めますが、前述の通りセキュリティ上の注意点があります。より安全な運用を目指す場合は、Kaniko を使用してコンテナビルドを行う設定に切り替えることを検討してください。Drone CI は設定ファイルがシンプルであるため、複雑な条件分岐やスクリプト実行が必要ないプロジェクトに向いています。また、Self-Hosted Runner のような GitHub 外部接続の依存度が低いため、ネットワーク断続時の耐障害性が高いというメリットもあります。
Jenkins は CI/CD ツールの歴史において最も古くから存在するツールの一つであり、そのプラグイン生態系は他を圧倒しています。自宅サーバーでの運用においては、学習コストがやや高いものの、複雑なパイプラインやカスタムスクリプトの統合には非常に優れています。2026 年時点でも多くの企業が Jenkins を採用しており、ドキュメントやコミュニティサポートが充実しているため、トラブル発生時の解決策が見つかりやすいという利点があります。
しかし、Jenkins の最大の課題はリソース消費量とセキュリティ管理です。Java ベースであるため、起動に時間がかかり、メモリ使用量が比較的多くなります。また、歴史的経緯から古いバージョンのプラグインが依存関係として残存していることが多く、脆弱性対策には定期的な更新作業が必要です。自宅サーバーで運用する場合、リソースを節約するために、Jenkins を Docker コンテナ内だけで動作させる構成が推奨されます。
Jenkins のモダン化においては、「Pipeline as Code」の徹底と「Docker Agent」の利用が鍵となります。以前は GUI でのジョブ設定が行われがちでしたが、現在はすべて Jenkinsfile で定義するのが標準です。また、ビルド環境を固定のマスターノードで行うのではなく、Docker コンテナを動的に起動する Jenkins Agents を使用することで、リソースの最適化と環境の隔離を実現できます。
// Jenkinsfile
pipeline {
agent any
environment {
DOCKER_IMAGE = 'node:20-bullseye'
}
stages {
stage('Build') {
steps {
sh 'docker run -v $WORKSPACE:/workspace ${DOCKER_IMAGE} npm install'
}
}
stage('Test') {
steps {
sh 'docker run -v $WORKSPACE:/workspace ${DOCKER_IMAGE} npm test'
}
}
}
post {
always {
cleanWs() // ビルド後のワークスペース整理
}
}
}
この Jenkinsfile は、ビルドステップを Docker コンテナ内で実行する例です。これにより、ローカル環境に依存せずに一貫したビルド結果を得られます。セキュリティ対策としては、Jenkins のマスターノードへの SSH 接続制限や、ジョブごとのユーザー権限管理(Role-Based Access Control)の適用が不可欠です。また、Secrets Management プラグインを使用することで、機密情報を平文で保存するリスクを回避できます。
完全なオフライン環境や、GitHub 依存を避ける場合、Gitea や Woodpecker CI が有力な選択肢となります。Gitea は軽量な Git サービスで、その内蔵機能として GitHub Actions と互換性のある「Actions」をサポートしています。これにより、GitHub のワークフロー記述方法をそのまま Gitea で利用でき、移行コストが低く済みます。また、Woodpecker CI は Drone CI のフォークであり、Drone との互換性を保ちつつ、よりモダンなアーキテクチャを採用しています。
Gitea Actions を自宅サーバーで構築する場合、まず Gitea サーバーを立てる必要があります。最近のバージョンでは、Actions Runner が内蔵されており、特別なランナー管理ツールなしで動作します。これは設定が非常にシンプルであり、Docker イメージのスキャン機能やシークレット管理も標準で提供されています。特に、Gitea 自体が軽量であるため、Raspberry Pi 5 のようなリソース制約のある環境でも快適に運用可能です。
Woodpecker CI は、Drone CI から派生したプロジェクトですが、よりモダンな設計思想を持っています。Pipeline ステージの可視化や、Docker イメージのスキャン機能が強化されており、セキュリティ面での配慮が厚くなっています。また、設定ファイルの記述方法も YAML ベースでありながら、Jenkins のような複雑なスクリプトを避けようとする設計になっており、メンテナンスしやすいという特徴があります。
以下の表は、Gitea Actions と Woodpecker CI を比較したものです。どちらを選ぶかは、既存の Git サーバー構成や、チームのスキルセットによって決定されます。
| 項目 | Gitea Actions | Woodpecker CI |
|---|---|---|
| Git サーバー依存 | 必須(Gitea 内蔵) | 独立したサーバー |
| ワークフロー記述 | GitHub Actions 互換 | YAML (Drone フォーク) |
| リソース消費 | 非常に低い | 低 |
| スケーラビリティ | マルチノード対応 | カスケード型実行 |
| コミュニティ規模 | 中(Gitea エコシステム) | 小〜中(Drone ユーザー層) |
Gitea Actions を利用する場合、GitHub のワークフローファイル(.github/workflows)をそのままコピーして使用できるため、GitLab CI や GitHub Actions で開発していたチームが移行する際に最もスムーズです。一方、Woodpecker CI は、完全に独立した CI サーバーを構築したい場合に適しています。両者とも、Jenkins ほどのリソース消費はなく、Drone のような軽量さを維持している点が共通しています。
自宅サーバーで CI/CD を運用する際、ハードウェアの選定はパフォーマンスとコストに直結します。2026 年現在、Raspberry Pi 5 は ARM アーキテクチャにおけるホームラボの定番となっていますが、その性能は用途によって評価が分かれます。一方で、x86 ベースのデスクトップ PC やミニ PC、あるいは旧式のサーバー機を再利用することも検討範囲に入ります。ビルド規模や処理内容に応じて適切なスペックを見極める必要があります。
小規模な個人開発プロジェクトであれば、Raspberry Pi 4 または Raspberry Pi 5 で十分対応可能です。特に Pi 5 は PCIe インターフェースが搭載されているため、高速な SSD を接続することでストレージ性能を大幅に向上させられます。CI のキャッシュディレクトリや Docker イメージの保存先として NVMe SSD を使用することで、ビルド速度のボトルネックを解消できます。しかし、大規模なコンパイル処理や AI モデルのトレーニングを行う場合は、CPU コア数とメモリ容量が不足する可能性があります。
以下の表は、プロジェクト規模別の推奨ハードウェアスペックを示しています。これらを参考にし、予算と性能のバランスを取った構成を選択してください。また、電源管理や冷却対策も忘れずに行う必要があります。
| ビルド規模 | 例 | 推奨 CPU | メモリ容量 | ストレージ種別 | 推定消費電力 |
|---|---|---|---|---|---|
| 小規模 | 個人ブログ、スクリプト | Raspberry Pi 5 (4GB/8GB) | 4GB〜8GB | MicroSD / USB SSD | 5W〜10W |
| 中規模 | Web アプリ、API | Intel NUC / Mini PC | 16GB〜32GB | M.2 NVMe SSD | 30W〜60W |
| 大規模 | ゲームサーバー、AI | x86 デスクトップ/サーバー | 64GB〜128GB | RAID 構成の HDD+SSD | 150W〜300W |
Raspberry Pi 5 の場合、USB-C ポートから給電されるため、安定した電源供給が必須です。また、CPU の発熱に対して十分な冷却対策(ヒートシンクやファン)を行うことが重要です。x86 ベースのサーバーであれば、複数の CPU コアを並列処理に使用できるため、並行ビルド時に有利です。さらに、ネットワーク環境も考慮し、1Gbps 以上の有線 LAN に接続することで、イメージプッシュ時の速度を最適化できます。
自宅サーバーでの CI/CD 運用において、最も時間を浪費する要素の一つが依存関係のインストールと Docker イメージの構築です。これらをキャッシュとして保存し、再利用することで、ネットワークトラフィックを減らし、ビルド時間を短縮できます。特に Raspberry Pi のような低性能な環境では、このキャッシュ戦略が利用体験を劇的に改善します。
まず、パッケージマネージャーごとのキャッシュ設定が重要です。Node.js プロジェクトであれば npm cache や yarn cache を Docker 層として保存し、変更がない場合の再ダウンロードを防ぎます。Python の場合は pip のキャッシュディレクトリや仮想環境(virtualenv)を再利用します。GitHub Actions の標準機能である actions/cache アクションは、これらのキャッシュを自動的に管理してくれますが、自宅サーバーで自前設定を行う場合は、Docker ボリュームマウントなどを用いて永続化させる必要があります。
また、Docker イメージのレイヤーキャッシュも効果的です。コンテナイメージのビルド順序において、頻繁に変更されるファイル(ソースコード)と変更されないファイル(依存関係)を分けて Dockerfile を記述することで、キャッシュヒット率を上げられます。例えば、package.json が更新された場合のみ npm install を実行し、それ以外はキャッシュから復元するロジックを組み込みます。
# 効率的な Dockerfile の例
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci # キャッシュ利用
COPY . .
RUN npm run build
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
この Dockerfile では、まず package.json をコピーしインストールを実行しています。依存関係が変更されない限り、次のビルドではキャッシュされたイメージが使用され、再ダウンロードが不要となります。また、自宅サーバーのストレージには SSD や NVMe を推奨します。HDD でのキャッシュ運用は Seek Time の影響で速度低下を招くためです。
自宅サーバーでの CI/CD 運用では、クラウドサービスのセキュリティプロトコルに依存しない分、自己責任の範囲が広がります。Runner の権限分離、シークレット管理、ネットワーク隔離など、多層的な防御策を講じる必要があります。特に Self-Hosted Runner は外部から GitHub と通信するため、ファイアウォール設定や SSH キーの管理が重要になります。
まず、Runner プロセスは最小権限で動作させるべきです。root 権限での実行は避け、専用のユーザーアカウントを作成してプロセスを起動します。また、Docker-in-Docker の環境では、ビルドコンテナからホストシステムへのアクセスを制限する設定が必要です。これには、docker.sock をマウントしない代わりに Kaniko や Buildbox を使用する方法が推奨されます。
シークレット管理においては、GitHub Secrets のような暗号化された変数管理機能を活用します。自宅サーバーの CI ツールでも同様の機能が提供されていますが、それらを外部の Vault システムに接続することでより高度なセキュリティを実現できます。また、定期的なバックアップとリストアテストも必須です。CI 設定ファイルやデータベース情報が失われた際のリスクを最小限にするためです。
前項の簡易表に加えて、具体的な製品例と性能評価を含めた詳細表を追加します。2026 年時点で入手可能な構成を想定しています。特に Raspberry Pi の周辺機器や、ミニ PC の選定において重要なポイントを示します。
| ハードウェア構成 | CPU コア数 | メモリ | ストレージ | 価格帯 | 推奨用途 |
|---|---|---|---|---|---|
| Raspberry Pi 5 | 4コア (ARM) | 4GB / 8GB | MicroSD / USB SSD | ¥10,000〜20,000 | 小規模ビルド、学習用 |
| Intel NUC 13 Pro | 14 コア (x86) | 16GB / 32GB | M.2 NVMe SSD | ¥50,000〜70,000 | 中規模ビルド、軽量 CI |
| Mini PC (Ryzen) | 8 コア (x86) | 32GB | M.2 / SATA SSD | ¥40,000〜60,000 | 大規模ビルド、並列処理 |
| 旧式サーバー | 16 コア以上 | 64GB+ | HDD/SSD RAID | ¥5,000(中古) | 長期運用、低コスト |
Raspberry Pi 5 の場合、USB-C ポートへの SSD 接続が必須です。MicroSD カードは読み書き速度にバラつきがあり、CI の安定稼働においてボトルネックになることがあります。Intel NUC のような x86 マシンでは、仮想化機能(VT-x/AMD-V)を活用してコンテナをより効率よく実行できます。また、電源管理設定として「アイドル時に消費電力を下げる」機能をオンにすることで、24 時間稼働時のランニングコストを抑えられます。
自宅サーバーで CI/CD を構築することには明確なメリットとデメリットが存在します。メリットとしては、まず第一にコスト削減があります。クラウドサービスの利用料金をゼロに抑えることができ、特に大量の実行時間を必要とするプロジェクトでは経済的な恩恵が大きいです。第二にプライバシー保護です。ソースコードを外部に送信しないため、企業秘密や個人情報を漏洩させるリスクを大幅に減らせます。第三にカスタマイズ性です。ハードウェアレベルでの最適化が可能で、特殊なアクセラレータボードなども利用できます。
一方、デメリットとしては運用負荷の増加が挙げられます。クラウドサービスなら自動修復されるサーバー障害やソフトウェア更新を、自分自身が行う必要があります。また、ネットワーク接続が不安定な自宅環境では、ビルドの信頼性が低下する可能性があります。さらに、セキュリティリスクも自己責任となり、万が一システムが侵害された場合の被害拡大を防ぐための知識と対策が求められます。
これらの点を踏まえ、プロジェクトの規模やチームのリソースに合わせて適切なツールとハードウェアを選ぶことが重要です。小規模な個人開発であれば Raspberry Pi と GitHub Actions Self-Hosted Runner の組み合わせが最適ですが、大企業での運用を目指す場合は、Jenkins や Woodpecker CI を中心にセキュリティを強化した構成を検討すべきです。
自宅サーバーで CI/CD パイプラインを構築する際に頻出する質問と回答をまとめました。各項目において結論ファーストで解説していますので、お困りの際はまず該当セクションをご確認ください。
Q1: 自宅サーバーでの CI/CD はセキュリティ面で危険ではありませんか? A1: 適切に設定すれば安全です。ただし、クラウドサービスのような自動パッチ適用がないため、OS や Docker の定期的な更新を管理者が手動で行う必要があります。また、Runner の権限分離やシークレット管理を徹底し、Docker ソケットへの直接アクセスを避けるなど、セキュリティベストプラクティスを守ることでリスクを最小化できます。
Q2: Raspberry Pi 5 で GitHub Actions Self-Hosted Runner は動作しますか?
A2: はい、動作します。ただし ARM アーキテクチャ向けのビルドが必須です。GitHub のワークフローで runs-on を指定し、ARM ラベルを持つランナーのみを使用する設定を行う必要があります。また、メモリ不足を防ぐため 8GB モデルの使用を推奨します。
Q3: Docker-in-Docker は安全ですか? A3: 基本的にはリスクがあります。ビルドコンテナからホストの Docker デーモンにアクセスできるため、特権昇格の危険性があります。代替として Kaniko や Buildah を使用し、Docker デーモンへの直接接続を行わない構成を強く推奨します。
Q4: GitHub Actions の無料枠と自宅サーバーのどちらがお得ですか? A4: ビルド時間やジョブ数によります。月間 2,000 マインutesを超えると自宅サーバーの方が経済的です。また、プライベートリポジトリでの実行制限がある場合、自宅サーバーは無料かつ制限なしで利用可能です。
Q5: ネットワークが不安定な場合、ビルドは失敗しますか? A5: はい、ランナーと GitHub 間の通信断はビルド中止の原因になります。自宅環境であれば有線 LAN 接続を必須とし、ルーターの設定で固定 IP を確保することで安定性を向上させられます。
Q6: Jenkins と Drone CI のどちらを選ぶべきですか? A6: プラグインの多さと柔軟性が欲しい場合は Jenkins を選びます。軽量な構成と簡潔な設定を重視する場合は Drone CI を推奨します。また、Drone は Docker ネイティブであるため、コンテナ化されたビルド環境に向いています。
Q7: 自宅サーバーでビルドした成果物をどこにデプロイできますか? A7: 通常はクラウドサーバー(AWS, Azureなど)や VPS にデプロイされます。自宅サーバーから外部へアクセスする必要があるため、SSH キーの設定や API トークンの管理が重要です。また、自宅からの公開にはセキュリティ上の注意点が必要です。
Q8: CI/CD ツールを複数導入することは可能ですか? A8: はい、可能です。プロジェクトごとに最適なツールを使い分けることもできます。例えば、テスト用には Drone を使い、本番環境のデプロイには Jenkins を使うようなハイブリッド構成も現実的な選択肢です。
Q9: 古い Raspberry Pi 3 でも動作しますか? A9: 理論上は可能ですが、ビルド時間が非常に長く非効率的です。特に Docker イメージの構築や依存関係のインストールに時間がかかるため、Pi 4 以上または x86 ベースのマシンを推奨します。
Q10: バックアップはどのように取るべきですか? A10: CI/CD の設定ファイル(Jenkinsfile, .drone.yml, GitHub workflows)と Docker イメージのメタデータを定期的なバックアップに含める必要があります。また、Runner 自体の設定も保存し、システム障害時に素早く復旧できるよう準備しておきます。
自宅サーバーでの CI/CD パイプライン構築は、コスト削減と技術的な自由度を得るための優れた戦略です。以下に本記事の要点をまとめます。
自宅サーバーでの構築は完全な自己責任となりますが、適切な設計と運用により、クラウドサービスを超える柔軟性とコスト効率を実現できます。まずは小規模なプロジェクトから始め、徐々に拡張していくアプローチが最もリスクが少なくおすすめです。

PCパーツ・ガジェット専門
自作PCパーツやガジェットの最新情報を発信中。実測データに基づいた公平なランキングをお届けします。
この記事に関連するデスクトップパソコンの人気商品をランキング形式でご紹介。価格・評価・レビュー数を比較して、最適な製品を見つけましょう。
デスクトップパソコンをAmazonでチェック。Prime会員なら送料無料&お急ぎ便対応!
※ 価格・在庫状況は変動する場合があります。最新情報はAmazonでご確認ください。
※ 当サイトはAmazonアソシエイト・プログラムの参加者です。
高性能!SSD&メモリ大容量
HP Prodesk400G6は、第9世代Core i5プロセッサー搭載で快適動作。32GBメモリと512GB SSDによる高速処理を実現し、Win11 ProとOffice 2019も搭載で、すぐに使える状態です。普段使いからクリエイティブな作業まで、快適にこなせます。
ストームゲーミングPCの体験談
初めてのゲーミングPCとして購入したこちらのストームゲーミングPCは、高性能な構成で満足しています。特にGPUがGeForce RTX 5070Tiとなっており、最新のゲームを快適にプレイできることが嬉しいポイントです。しかし、少し不満な点もあります。例えば、初期設定時にソフトウェアの最適化が十分で...
Chromeタブ開くのストレスが減った!整備済みデルOptiPlexで快適ワークフローを実現
色々比較検討して、最終的に整備済み品のアキシャルデル OptiPlex 3070SFF 又5070SFFに飛び移りました。以前は自作PCをコツコツと組み立てていたんですが、正直言って、パーツの調子をこまめにチェックするのが面倒でした。特にChromeのタブ開くの、バグったり、フリーズしたりで、精神的...
及第点だけど、価格に見合うか悩ましい高性能PC
前のPCが寿命を迎えて、買い替えを検討していました。自作も考えたんですが、時間も手間もかかるので、今回は思い切ってBTOのNEWLEAGUEのデスクトップPCを選びました。Core i7-14700、メモリ16GB、SSD 2TBという構成は、動画編集やゲーム用途にも十分かなと思い、T8ブラックとい...
家族みんなで使える!コンパクトで高性能なDell Micro
自作PC歴10年の私にとって、新しいPCを選ぶのはいつも楽しみな時間。今回は、子供たちがオンライン授業で使うPCとして、このDell 3050 Microを検討することにしました。色々比較した結果、コンパクトさと性能、そしてOffice 2019がセットになっている点に惹かれて、最終的にこちらを選ん...
マジでコスパ神!Dell OptiPlex 3060SFF、買い替えで人生変わった件
いやー、マジで最高だった。前使ってたHPのデスクトップPC、もうガラクタみたいなもんで、起動するのも毎回イライラしてたんだよね。特に動画編集とか、カクカクしてて作業効率がマジでゴミ。前から買い替えたいって思ってたんだけど、なかなか良いやつが見つからなくて…。で、思い切ってこの整備済みDell Opt...
これぞ本命!4K制作の相棒、神スペックすぎる感動体験!
前使ってたやつがもうボロボロで、正直「また古いものか…」ってテンション下がってたんですよ。だって、推し作品を最高のクオリティで世に出したいのに、機材が足かせになるなんて、一番悲しいじゃないですか。色々試した中で、このThinkCentre M920Tに買い替えてから、もう毎日これしか使わなくなりまし...
富士通D587/i5-8400、価格以上の選択
大学生の私にとって、3万6800円の価格帯で1TB SSD付きのデスクトップPCとなると、妥当な性能を求めるのは当然。この富士通の整備済み品は、i5-8400と16GBメモリが搭載されている点は評価できる。起動は速く、普段使いのブラウジングやレポート作成などには十分な速度が出た。また、1TB SSD...
コスパ良し!普段使いには十分。
40代主婦の私、田中です。パートで色々動いているので、PCは仕事と趣味で毎日使っています。このProdesk 600 G5、64800円で手に入れたのは本当に良い買い物でした!SSD搭載で起動が早くて、Officeもスムーズに使えます。特に、Core i7-9700のパワーは、動画を見たり、ちょっと...
買い替えで大正解!NEC MB-3、仕事効率が劇的に向上
以前使っていたデスクトップPCは、年数が経過して速度が著しく低下し、特に動画編集作業で頻繁にフリーズしてしまっていました。正直、作業効率が著しく落ち込み、ストレスも溜まっていました。買い替えを検討していた際、この整備済み品【NEC デスクトップPC MB-3/22型液晶セット/第8世代 i3-810...
GitHub Actionsのセルフホストランナーを自宅PCに構築する方法。コスト削減、高速化、GPUテストへの活用を解説。
Drone CI のセルフホスト構築を解説。Docker導入、GitHub / Gitea 連携、Runner設定、パイプライン記述、Woodpecker CI との比較、実運用Tipsを紹介。
Woodpecker CI のセルフホスト構築を解説。Docker導入、Gitea / Forgejo 連携、パイプライン記述、Drone CI との違い、実運用Tipsを詳しく紹介。
Gitpod Self-Hosted の構築を解説。Kubernetes デプロイ、GitHub / GitLab 連携、Workspace 管理、Coder / DevPod との比較、実運用Tipsを詳しく紹介。
自宅でデータベースサーバーを構築する方法を解説。PostgreSQL・MariaDB・MongoDBの選定からDocker構成まで。
Dockerを使って自宅サーバーに各種サービスをセルフホストする方法を解説。おすすめアプリ20選とdocker-compose設定例を紹介。