GitBucketをDockerで構築する手順｜4.48.0の配布先・旧版からの移行・Jenkins連携

GitBucketは、Scalaで書かれたオープンソースのGitホスティングサーバーです。リポジトリ管理・Issue・プルリクエスト・Wiki・GitHub互換のREST APIを1つのwarファイルで提供し、Java 17があれば動きます。依存が少ないぶんDockerで立てやすく、社内向けのGitサーバーを最短で用意したい場面で選ばれています。

ただし、解説記事の多くが使う docker run gitbucket/gitbucket のイメージは、2022年12月25日の4.38.4を最後に更新が止まっています。最新の4.48.0（2026年9月20日リリース）はGitHub Container Registry（ghcr.io）で配布されており、旧イメージで作ったデータをそのまま載せ替えると起動しません。本稿では、配布先の現状、構築手順、旧版からの移行、Jenkins連携までを、公式リポジトリとJenkinsのセキュリティ情報、およびDocker上での実測をもとに整理しました（2026年11月2日時点）。

まとめ

Jenkins側のGitBucket PluginとGitHub Pull Request Builderは脆弱性が修正されないまま止まっているため、新規には使いません。CI連携はWebhookで直接ジョブを起動する構成にします。Multibranch方式と違い、GitBucketをポート80で起動する制約を受けないためです。

Docker HubとGHCRで割れた公式イメージの現状

GitBucketの公式イメージは配布先が2つに割れており、Docker Hub側はバージョン付きタグが3年10か月以上増えていません（最後の更新は2023年3月19日のnightlyタグ）。2026年11月2日に両レジストリを照会した結果は次のとおりです。

Javaの版は、各イメージを起動して java -version を実行した値です。Docker Hub版は古いOpenJDK 8の上で動いており、GitBucket本体がJava 17を必須にした現在の要件とも合いません。ghcr.io側の latest は4.48.0と同じダイジェスト（sha256:4383274e…）を指しています。

配布先が分かれた理由はビルド定義にあります。公式イメージのビルドリポジトリ gitbucket/gitbucket-docker のGitHub Actionsワークフローは、プッシュ先を ghcr.io/gitbucket/gitbucket だけに指定しており、Docker Hubへプッシュする処理を持ちません。4.39.0以降のタグがDocker Hubに増えていないのはそのためです。公式Wikiの Dockerのページもいまだに gitbucket/gitbucket で例示しているので、コピーすると古い版を引きます。amd64とarm64の両方がビルドされているため、Apple Siliconでもエミュレーションなしで動きます。

イメージの中身と公開ポート

4.48.0の Dockerfile は、eclipse-temurin:17 をベースに公式リリースのwarを置くだけの構成です（LABELとコメント行を除く抜粋）。

FROM eclipse-temurin:17
ADD https://github.com/gitbucket/gitbucket/releases/download/4.48.0/gitbucket.war /opt/gitbucket.war
RUN ln -s /gitbucket /root/.gitbucket
VOLUME /gitbucket
EXPOSE 8080 29418
CMD ["sh", "-c", "java -jar /opt/gitbucket.war"]

29418はGit over SSH用のポートです。開けただけでは有効になりません。管理画面の System settings の Integrations タブで SSH access を有効化し、SSH bind host（コンテナ内なので 0.0.0.0）とBase URLを設定します。どちらかが空だと保存できません。HTTPでcloneするだけなら8080の公開で足ります。

docker runでの最短起動とデータの置き場所

単体で挙動を確かめるなら、ボリュームを1つ与えるだけで起動します。

docker run -d --name gitbucket \
  -p 8080:8080 \
  -v gitbucket_home:/gitbucket \
  ghcr.io/gitbucket/gitbucket:4.48.0

http://localhost:8080/ を開き、ID root ／パスワード root でログインし、すぐにパスワードを変更します。

永続化の対象は /gitbucket ひとつです。設定ファイル（gitbucket.conf・database.conf）、H2データベース（data.mv.db）、Gitリポジトリの実体、プラグインがここにまとめて入ります。/root/.gitbucket がこのディレクトリへのシンボリックリンクなので、データディレクトリを指定しなくてもボリュームに書かれます。バインドマウントはSELinuxが有効なホストやrootlessのDockerで書き込みに失敗することがあるため、名前付きボリュームが無難です。Dockerコンテナ起動・実行コマンドの使い分けでは、run・start・execの違いと起動しないときの確認手順を扱っています。

設定は 公式WikiのBasic configurations にあるとおり、コマンドライン引数でも環境変数でも渡せます。Dockerでは環境変数が扱いやすく、主な対応は次のとおりです。

Docker ComposeでGitBucketとJenkinsを並べる構成

CI連携まで見据えるなら、最初からComposeで2コンテナを定義したほうが手戻りがありません。トップレベルの version はCompose仕様で廃止扱いのため書きません。

services:
  gitbucket:
    image: ghcr.io/gitbucket/gitbucket:4.48.0
    ports:
      - "8080:8080"
      - "29418:29418"
    volumes:
      - gitbucket_home:/gitbucket
    restart: unless-stopped

  jenkins:
    image: jenkins/jenkins:lts
    ports:
      - "8081:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
    restart: unless-stopped

volumes:
  gitbucket_home:
  jenkins_home:

両方ともコンテナ内では8080で待ち受けるため、ホスト側でJenkinsを8081にずらしています。同じComposeプロジェクトのサービスはサービス名で名前解決できるので、GitBucketからJenkinsを呼ぶURLは http://jenkins:8080/ です。ホスト側の8081ではありません。Composeのボリューム名には実際にはプロジェクト名が前に付く点（例：myproj_gitbucket_home）は、後述の移行手順で効いてきます。ymlで複数コンテナを一括管理する仕組みはdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説にまとめています。

Jenkins側の初期セットアップ

docker compose up -d
docker compose exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

jenkins/jenkins:lts は2026年11月2日時点で 2.580.2-lts と同じイメージを指しています。JENKINS_HOMEは /var/jenkins_home、公開ポートは8080（Web UI）と50000（エージェント接続）です。50000番はエージェントを別コンテナやマシンに置くときだけ必要で、単体運用なら外して構いません。Jenkins本体の導入と初期設定はJenkinsとは？できること・無料の範囲とインストールから使い方までを参照してください。

Docker Hub版（4.38.4）から4.48.0へ移す手順

既に gitbucket/gitbucket で運用しているなら、イメージ名を書き換えるだけでは移れません。CHANGELOG によると、2025年6月29日の4.43.0で組み込みデータベースがH2 1.x から2.x に上がり、データファイルの形式が変わりました。GitBucketの自動マイグレーションはデータベース自身に依存するため、この変換は手作業になります。

そのまま載せ替えたときの症状

4.38.4でリポジトリとIssueを作ったボリュームを、移行せずに4.48.0へ渡して起動してみました。コンテナは起動状態のまま、Webは約3分間503を返し続けました。ログに出たのは HikariPool-1 - Starting... とSLF4Jの警告だけで、H2の形式エラーは表示されませんでした。4.48.0はlogback-classic 1.6.3を同梱しており、起動後の例外は通常どおりログに出ます（後述のWebhookの例外がその例です）。表示されないのは、起動時のこのDB接続の失敗です。「新しいイメージにしたら503のまま」という状態になったら、まずH2の版違いを疑ってください。

旧版の database.conf には jdbc:h2:${DatabaseHome};MVCC=true が書かれています。H2 2.x はこの MVCC 指定を受け付けないので、データ変換とあわせて消します。公式Wikiの External database configuration のH2の例にもまだ MVCC=true が残っているため、ここから写すと同じ状態に戻ります。

H2のダンプと再作成

旧コンテナを止めたうえで、同じボリュームを一時的なJavaコンテナにマウントして作業します。ボリューム名はComposeならプロジェクト名付きのものに読み替えてください。

docker stop gitbucket
docker run --rm -v gitbucket_home:/gitbucket eclipse-temurin:17 sh -c '
cd /tmp
curl -sO https://repo1.maven.org/maven2/com/h2database/h2/1.4.199/h2-1.4.199.jar
curl -sO https://repo1.maven.org/maven2/com/h2database/h2/2.5.250/h2-2.5.250.jar
cp /gitbucket/data.mv.db /gitbucket/data.mv.db.h2v1.bak
java -cp h2-1.4.199.jar org.h2.tools.Script -url "jdbc:h2:/gitbucket/data" -user sa -password sa -script /gitbucket/dump.sql
rm /gitbucket/data.mv.db
java -cp h2-2.5.250.jar org.h2.tools.RunScript -url "jdbc:h2:/gitbucket/data" -user sa -password sa -script /gitbucket/dump.sql
sed -i "s/;MVCC=true//" /gitbucket/database.conf
'

CHANGELOGの手順は再作成に h2-2.3.232 を使っていますが、4.48.0が同梱しているのはH2 2.5.250です（4.48.0のbuild.sbt）。検証では2.3.232で作ったファイルも2.5.250で開けましたが、移行先と同じ版で作っておけば版差を気にせずに済みます。

移行後の確認

上の手順のあと4.48.0で起動すると、数秒でAPIが200を返し、4.38.4時代に作ったリポジトリ root/demo とIssue #1がAPIから取得できました。4.39.0〜4.47.0のスキーマ変更は、起動時にGitBucketの自動マイグレーションで適用されます。問題が出たら、退避した data.mv.db.h2v1.bak を戻して旧イメージで起動すれば元の状態に戻れます。H2を使わずMySQLやPostgreSQLで運用している場合、この変換は不要です。

GitBucketの脆弱性とDocker構成での対策

NVDで「gitbucket」を検索すると、本体と周辺で次の3件が見つかります（2026年11月2日時点）。Docker Hub版（4.38.4）を使い続けている環境は、CVE-2026-13540の修正前にあたります。CVE-2018-25332の対象は4.23.1、CVE-2024-28157はJenkins側プラグインの脆弱性です。

CVE-2026-13540 は、新規リポジトリ作成画面の「Copy existing git repository」（既存リポジトリをコピーして作成）に任意のURLを渡せることを突くSSRFです。ログインできる利用者なら、社内ネットワークやクラウドのメタデータエンドポイントにGitBucketサーバーからアクセスさせられます。NVD上の状態はDeferred（NIST独自の評価は保留）で、スコアはCNAのVulDBが付けたものです。修正（PR #4056）は2026年8月9日の4.47.0に入りましたが、中身は「対策の設定を追加・拡張した」もので、既定の動作は変わっていません。

CVE-2026-13540対策の設定と既定値（4.48.0）

Block sending to private addresses と IP whitelist は、2019年12月31日の4.33.0からWebhook向けにあった設定です。4.47.0でcloneにも効くよう範囲が広がり、cloneによる作成そのものを止める設定が新設されました。新設の設定は管理画面の System settings タブ、遮断とwhitelistは Integrations タブの Outbound requests にあります。

既定値は SystemSettingsService.scala の初期値で確認しました。4.48.0に上げただけでは、cloneでの作成は許可され、プライベートアドレスへの送信も止まりません。利用者を社外にも開くなら、cloneによる作成を無効にするのが最も確実です。

遮断有効時のJenkins宛Webhookとホスト名URLの制約

「Block sending to private addresses」を有効にすると、Composeで並べたJenkinsもプライベートアドレス（Dockerの既定では172.16.0.0/12の範囲）なので遮断対象になります。IP whitelistにDockerのネットワーク範囲を書けば通りそうに見えますが、受信側にJenkinsの代わりとなるHTTPのスタブ（ネットワーク別名 jenkins）を置いて実測すると、通りませんでした。

2行目のときGitBucketのログには java.lang.IllegalArgumentException: Could not parse [jenkins] が出ます。WebHookService.scala の送信前チェックは、プライベートかどうかの判定ではホスト名を名前解決しますが、whitelistとの照合ではホスト名の文字列をそのままCIDRの判定（commons-netのSubnetUtils）に渡すため、IPアドレスでない名前は解析できず例外になります。遮断を有効にするなら、Webhook URLはIPアドレスで書き、JenkinsのIPが作り直しで変わらないようComposeで固定します。

services:
  jenkins:
    networks:
      ci:
        ipv4_address: 172.30.0.10
  gitbucket:
    networks:
      - ci

networks:
  ci:
    ipam:
      config:
        - subnet: 172.30.0.0/24

このときのPayload URLは http://172.30.0.10:8080/generic-webhook-trigger/invoke?token=…、IP whitelistには 172.30.0.10 を1行書きます。範囲指定（172.30.0.0/24）も使えます。後述のPostgreSQLを足す場合は、db サービスも ci ネットワークに参加させないとGitBucketから届きません。

4.48.0の認証API変更とプラグイン

4.48.0のCHANGELOGには「Authentication-related API changes. Some plugins might not work with this version」と書かれています。認証まわりの内部APIが変わり、プラグインによっては動かなくなるという告知です。/gitbucket/plugins にプラグインを入れている環境では、上げる前に各プラグインの対応版を確かめ、上の移行手順と同じくボリュームを退避してから試してください。

Jenkins連携プラグインの現況と、避けるべき2つ

古い解説記事と現実が最も離れているのがこの部分です。「GitBucket Pluginを入れる」「GitHub Pull Request Builderでプルリクエストをビルドする」という手順は、いま新規に採用すべきではありません。Jenkinsの更新センターが配信するプラグイン情報とセキュリティ警告（update-center.actual.json）を2026年11月2日に照合した結果です。

GitBucket Pluginが要求するJenkinsコアは1.609.3で、2015年当時の版です。2024年3月6日のJenkinsセキュリティアドバイザリで報告されたStored XSS（SECURITY-3249）は修正版が出ていません。GitHub Pull Request Builderは「GitHub Branch Source Pluginに置き換えられた」とされ、既知の脆弱性を抱えたまま保守が終わっています。

GitBucketはGitHub互換APIを持つため、残る選択肢は2つです。

Dockerで立てた環境なら、Generic Webhook Triggerを選んでください。Multibranch側にはDocker構成と正面からぶつかる制約があります。リポジトリ数が多く、パイプラインの標準化やレビュー運用まで含めて設計し直すなら、DevOps・CI/CD導入支援のように構成ごと見直す選択もあります。

Multibranch Pipelineを選ぶと効いてくるポート80の制約

公式Wikiの Setup Jenkins Multibranch Pipeline and Organization は、JenkinsがポートもコンテキストパスもないURLでGitBucketへ到達できることを前提にしています。

• GitBucketをポート80で起動する（ホスト側で別番号へ付け替えるポートマッピングは不可）
• --prefix を付けない
• 管理画面のBase URLに到達可能なURLを明示する

理由は、GitHub系プラグインがGitBucketへ接続するときにURLからカスタムポートを落とすことと、WebhookのURLと検出済みリポジトリのURLを完全一致で照合することです。APIエンドポイントには http://gitbucket.example.com/api/v3 の形を登録します。どうしても使うなら、GITBUCKET_PORTを80にしてホスト側も80で公開し、JenkinsからもブラウザからもDNS名で同じURLに届くよう揃えます。

services:
  gitbucket:
    image: ghcr.io/gitbucket/gitbucket:4.48.0
    environment:
      GITBUCKET_PORT: "80"
    ports:
      - "80:80"

ポート80を他のサービスで使っている、社内DNSが無い、リポジトリが数個しかない、のどれかに当てはまるならMultibranchは選ばないでください。URLの一致条件を満たせないまま入れると、ジョブは作れてもWebhookが素通りし、原因の切り分けに時間を取られます。

Generic Webhook Triggerでpush・プルリクエストを拾う設定

Generic Webhook Trigger は、受け取ったJSONをJSONPathで変数に展開し、その値で発火条件を絞れるプラグインです。GitBucketのWebhookペイロードはGitHub互換なので、そのまま扱えます。

GitBucket側のWebhook登録とContent typeの変更

対象リポジトリの Settings から Service Hooks を開き、Webhookを追加します。Composeで並べた構成のPayload URLは次の形です。

http://jenkins:8080/generic-webhook-trigger/invoke?token=gitbucket-hook

ここで必ず Content type を application/json に変えます。新規Webhook画面の既定は application/x-www-form-urlencoded で、このときボディは payload=<URLエンコード済みJSON> という1個のフォームパラメータとして送られます。Generic Webhook Triggerはそれを {"payload":["…"]} の形に組み直してからJSONPathを評価するので、$.ref が解決せずジョブは発火しません。printPostContent の出力に payload でくるまれたJSONが見えたら、Content typeの設定漏れです。

イベントは Push と Pull Request を選びます。Webhook画面で選べるイベントは19種類で名前はGitHubと同じですが、4.48.0のソースで送信処理があるのは push create gollum issues issue_comment pull_request pull_request_review_comment の7種類です。release などは選んでも届きません。

Webhook画面の Security Token 欄は、Generic Webhook Triggerの認証トークンではありません。GitBucketはこの値をHMACの鍵にして署名ヘッダーを付けます。実測では4.48.0は X-Hub-Signature（SHA-1）と X-Hub-Signature-256 の両方を送りました。SHA-256の署名は2026年3月7日の4.46.0で加わったもので、Docker Hub版の4.38.4にはありません。Generic Webhook Triggerは、Jenkinsのグローバル設定のWhitelistでホストごとにHMAC検証を設定でき、Secret textの資格情報・ヘッダー名 X-Hub-Signature-256・アルゴリズム HmacSHA256 を登録すればこの署名を照合できます（sha256= の接頭辞にも対応）。ただし、どのジョブを起動するかを決めるトークンは別に必要です。GitBucketのWebhookフォームにはカスタムヘッダーの欄が無いので、そのトークンはPayload URLのクエリ文字列で渡します。tokenCredentialId はJenkinsfileへの直書きを避ける機能で、URL上の露出は消えません。気になるなら、Jenkinsを内部ネットワークに閉じるか、リバースプロキシのアクセスログでクエリをマスクします。

Jenkinsfileでの受け取りとブランチ絞り込み

宣言的パイプラインでは triggers ブロックに書き、regexpFilterText と regexpFilterExpression で対象ブランチ以外のpushを無視します。照合は部分一致なので、^ と $ で前後を固定しないと refs/heads/maintenance なども発火します。

pipeline {
  agent any
  triggers {
    GenericTrigger(
      genericVariables: [
        [key: 'ref', value: '$.ref']
      ],
      causeString: 'Triggered by GitBucket push on $ref',
      token: 'gitbucket-hook',
      tokenCredentialId: '',
      printContributedVariables: true,
      printPostContent: true,
      regexpFilterText: '$ref',
      regexpFilterExpression: '^refs/heads/main$'
    )
  }
  stages {
    stage('build') {
      steps {
        sh 'echo build from $ref'
      }
    }
  }
}

triggers はJenkinsfileを一度読み込んで初めてジョブに登録されます。作成直後に手動で1回ビルドしておかないと、Webhookを送っても反応しません。初回は printPostContent を有効にして、受信したJSONの実物を見ながらJSONPathを直すのが最短です。

プルリクエストのマージを起点にする場合の発火イベント

GitBucketの MergeService.scala を読むと、画面上のマージ操作は push と pull_request（action は closed）の両方を送ります。マージコミット・rebase・squashのどれでも同じです。closed はマージせずに閉じたときも飛ぶので、マージだけを拾うなら $.action が closed かつ $.pull_request.merged が true の2条件で判定します。

両方のイベントを1つのジョブで購読すると、1回のマージで二重に起動します。検証ジョブは synchronize、デプロイジョブは refs/heads/main のpush、と購読を分けておけば事故は起きません。検証段にコンテナイメージの脆弱性スキャンを挟むなら、Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定までが使えます。

GitBucketのアクセストークンとJenkins資格情報

Jenkinsからプライベートリポジトリをcloneしたり、GitHub互換APIを呼んだりするには、パスワードではなくアクセストークンを使います。発行は画面右上のアカウントメニューの Applications、URLでは /<ユーザー名>/_application です。

トークン文字列が表示されるのは発行直後の1回だけです。実装上もリダイレクト時のフラッシュメッセージで一度渡されるだけで、一覧画面にはメモ（note）しか出ません。控え忘れたら削除して再発行します。Jenkins側には Username with password の資格情報として、ユーザー名にGitBucketのアカウント名、パスワード欄にトークンを入れて登録し、ジョブからは資格情報IDで参照します。

外部データベースへの切り替えとバックアップ

H2のままでも動きますが、利用者が増えたらMySQL 5.7以上かPostgreSQL 14以上へ移せます（公式Wikiの記載）。設定ファイルはDockerでは /gitbucket/database.conf です。

db {
  url = "jdbc:postgresql://db/gitbucket"
  user = "gitbucket_user"
  password = "YOUR_PASSWORD"
}

PostgreSQLは前掲のComposeに次の差分を足し、トップレベルの volumes に db_data を追記します。タグをメジャー番号で固定しておくと、GitBucket本体とデータベースのメジャーアップグレードを別々の日に実施できます。

services:
  gitbucket:
    depends_on:
      - db
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: gitbucket
      POSTGRES_USER: gitbucket_user
      POSTGRES_PASSWORD: YOUR_PASSWORD
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

docker compose cp database.conf gitbucket:/gitbucket/database.conf
docker compose restart gitbucket

MariaDBは公式サポート外です。Wikiは10.2.1以上なら動く可能性があるとしつつ、10.4.4以降で不具合の報告があると注意しています。H2の既存データは、database.conf を差し替える前に管理画面からSQLをエクスポートし、切り替え後に同じ画面からインポートして移します。

バックアップで守る対象は、Gitリポジトリの実体とデータベースの2つです。時点がずれるとIssueやプルリクエストの参照が壊れます。公式Wikiの Backup のスクリプトは、リポジトリの更新→DBバックアップ→リポジトリの再更新という順でずれを抑えています。ただしWiki自身が保守されていないと断っているので、順序の考え方だけを取り込むのが現実的です。アップグレード時はイメージタグを 4.48.0 のように固定し、上げる前にボリュームを退避してください。

つながらないときの切り分け

GitBucketには配信履歴の画面が無いため、Webhook編集画面の Test Hook ボタンでテスト送信し、表示されるリクエストとレスポンスを確かめます。接続エラーならネットワーク、200以外のステータスならJenkins側の設定、と切り分けの向きが決まります。

よくある質問

GitBucketとはどんなソフトウェアですか？

Scalaで開発されたオープンソースのGitホスティングサーバーです。リポジトリ管理、Issue、プルリクエスト、Wiki、LDAP連携、プラグイン機構を備え、GitHub互換のAPIを提供します。1つのwarファイルとJava 17で動くため、社内にGitサーバーを置きたい場合に選ばれます。GitHubやGitLabとの位置づけはGitHubとGitLabの違いの比較が参考になります。

docker run gitbucket/gitbucket で入るのはどのバージョンですか？

Docker Hubの latest は4.38.4で、2022年12月25日から更新されていません。Javaも1.8系です。最新版を使うなら ghcr.io/gitbucket/gitbucket:4.48.0 を指定します。

古いイメージから最新版へ上げるとき注意することは？

H2を使っているなら、4.43.0以降へ上げる前にデータの変換が必要です。H2 1.4.199でダンプし、2.x で再作成して、database.conf の ;MVCC=true を消します。変換しないと503が続き、ログにもエラーが出ません。

GitBucketに既知の脆弱性はありますか？

4.46.1以前にはclone経由のSSRF（CVE-2026-13540）があります。4.47.0で対策の設定が入りましたが既定では効いていないので、上げたうえで「Allow creating new repositories by cloning an existing repository」を外すか、プライベートアドレスへの送信を遮断します。

JenkinsのGitBucket Pluginは今も使えますか？

新規導入は避けてください。最新版0.8は2015年から更新がなく、Stored XSS（CVE-2024-28157）が未修正です。Webhook起点でジョブを動かすならGeneric Webhook Triggerで代替できます。

関連記事

• docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説
• Dockerコンテナ起動・実行コマンドの使い分け｜run・start・execと起動しない時の対処
• Jenkinsとは？できること・無料の範囲とインストールから使い方まで【2026年版】
• Trivy（トリヴィ）の使い方｜インストールからイメージ・IaCスキャン、CI設定まで【v0.76対応】
• GitHubとGitLabの違い｜ActionsとGitLab CIの対応表・料金・セルフホスト比較