さくらのクラウドの「AppRun共用型」で、Docker HubとGitHub Container Registry（GHCR）のコンテナイメージを利用できるようになりました。
これまでAppRun共用型で利用できるコンテナレジストリは、さくらのクラウドが提供するコンテナレジストリのみでした。
2026年5月28日の仕様変更により、Docker HubとGitHub Container Registryが利用可能なコンテナレジストリとして追加されています。
これにより、すでにDocker HubやGHCRで管理しているコンテナイメージについては、さくらのコンテナレジストリへ別途登録せず、AppRun共用型のデプロイソースとして指定できるようになりました。
一方で、GitHubのソースコードを指定するとAppRunが自動でビルドしてくれる機能や、コンテナレジストリへのpushを検知して自動的に新バージョンを作成する機能が追加されたわけではありません。
この記事では、外部コンテナレジストリ対応によって何が変わったのかを整理し、GHCRに登録した簡単なWebアプリをAppRun共用型へ配備する流れを解説します。
この記事で分かること
- AppRun共用型の外部コンテナレジストリ対応で変わったこと
- 従来の配備方法との違い
- GHCRのイメージをAppRunへ配備する方法
- コンテナイメージを更新する方法
- 外部レジストリ対応後も変わらないAppRunの仕様
結論：外部レジストリへの対応で何が変わった？
今回の変更で明確に変わったのは、AppRun共用型がコンテナイメージを取得できるレジストリの選択肢です。
利用できるレジストリは、次の3種類です。
| コンテナレジストリ | 利用可否 |
|---|---|
| さくらのクラウド コンテナレジストリ | 利用可能 |
| Docker Hub | 利用可能 |
| GitHub Container Registry（GHCR） | 利用可能 |
例えば、すでにGHCRでコンテナイメージを管理している場合、次のような構成が可能です。
GitHub
↓
コンテナイメージをビルド
↓
GitHub Container Registry
↓
AppRun共用型従来必要だった「AppRunで利用するために、さくらのコンテナレジストリへイメージを登録する工程」を省けることになります。
任意の外部レジストリに対応したわけではありません
外部レジストリとして公式に案内されているのはDocker HubとGitHub Container Registryです。Amazon ECRやGoogle Artifact Registryなどが利用可能と案内されているわけではありません。
また、外部コンテナレジストリに関する個別設定やトラブルは、さくらインターネットのサポート対象外とされています。
従来の配備方法と何が違うのか
外部レジストリ対応前
外部レジストリ対応前は、AppRun共用型で利用可能なコンテナレジストリは、さくらのクラウドのコンテナレジストリのみでした。
そのため、GHCRなどで管理していたイメージをAppRunで利用したい場合は、さくらのコンテナレジストリへ登録する工程が必要でした。
コンテナイメージを作成
↓
外部レジストリへpush
↓
さくらのコンテナレジストリへ登録
↓
AppRun共用型へデプロイ外部レジストリ対応後
Docker HubまたはGHCRにあるイメージを、AppRun共用型のコンテナイメージとして直接指定できます。
コンテナイメージを作成
↓
Docker HubまたはGHCRへpush
↓
AppRun共用型へデプロイ| 作業 | 従来 | 対応後 |
|---|---|---|
| さくらのコンテナレジストリへの登録 | 必要 | Docker Hub・GHCRを使う場合は不要 |
| Docker Hub／GHCRのイメージを直接指定 | 不可 | 可能 |
| AppRun側でのアプリ作成 | 必要 | 必要 |
| AppRunの新バージョン作成 | 必要 | 必要 |
外部レジストリ対応で省けるようになった工程
公式仕様から明確に言えるメリットは、Docker HubまたはGHCRを使用する場合に、AppRun用としてさくらのコンテナレジストリへイメージを登録する必要がなくなったことです。
特に、すでにGHCRをコンテナイメージの保存先として利用している環境では、同じイメージを別のレジストリへ登録する工程を省けます。
そのため、GitHubとGHCRを中心とした開発環境では、従来より少ない工程でAppRunを配備先として利用できるようになったと考えられます。
外部レジストリ対応後も変わらないこと
GitHubのソースコードから直接デプロイする機能ではない
AppRun共用型で指定するデプロイソースは、コンテナレジストリに登録されたコンテナイメージです。
GitHubリポジトリを指定するとAppRunがソースコードをビルドする、という仕組みではありません。
自作アプリを利用する場合は、引き続きコンテナイメージをビルドし、対応するレジストリへ登録する必要があります。
GHCRへのpushだけでは新バージョンは作成されない
AppRunのマニュアルでは、新しいバージョンは「アプリケーション構成を変更してデプロイ」から作成する仕様となっています。
GitHub Actionsなどから自動デプロイしたい場合は、AppRun APIを利用してCI/CDツールと連携できます。
コンテナイメージの条件も変わらない
AppRun共用型で使用するコンテナイメージには、次の制限があります。
- アーキテクチャ：
linux/amd64 - コンテナイメージサイズ：2GiB以下
外部レジストリに保存されていれば、どのコンテナでも動くという意味ではありません。
GHCRのイメージをAppRunへ配備する
ここからは、Nginxを使った簡単なWebページをコンテナ化し、GHCRへ登録してAppRun共用型から指定する流れを見ていきます。
前提条件
- さくらのクラウドを利用できる
- GitHubアカウントを利用できる
- Dockerを実行できる
- GHCRへコンテナイメージをpushできる
手順1：サンプルページを作成する
index.htmlを作成します。
<!doctype html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>AppRun External Registry Demo</title>
</head>
<body>
<h1>AppRun External Registry Demo</h1>
<p>GitHub Container Registryから配備するサンプルです。</p>
<p>Version: v1</p>
</body>
</html>手順2：Dockerfileを作成する
FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80手順3：GHCRへログインする
GitHub PackagesではPersonal Access Token（classic）を利用して認証できます。
コンテナイメージをアップロードする場合は、write:packagesスコープを持つトークンを利用します。
macOS・Linux
export CR_PAT="YOUR_TOKEN"
echo "$CR_PAT" | docker login ghcr.io \
-u YOUR_GITHUB_USERNAME \
--password-stdinWindows PowerShell
$env:CR_PAT = "YOUR_TOKEN"
$env:CR_PAT | docker login ghcr.io `
-u YOUR_GITHUB_USERNAME `
--password-stdin注意：アクセストークンをDockerfileやソースコードへ直接記載しないようにしてください。
手順4：linux/amd64でビルドしてGHCRへpushする
docker buildx build \
--platform linux/amd64 \
-t ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v1 \
--push \
.Windows PowerShellの場合は次のように実行できます。
docker buildx build `
--platform linux/amd64 `
-t ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v1 `
--push `
.
AppRun共用型はx86_64アーキテクチャで動作します。公式マニュアルでもlinux/amd64を指定してビルドするよう案内されています。
手順5：GHCRの公開設定を確認する
GitHub Container Registryでコマンドラインから初めて公開したPackageは、デフォルトではPrivateです。
認証なしでAppRunから取得させる場合は、GitHub側でPackageのVisibilityをPublicへ変更します。
Privateのまま利用する方法については後述します。
手順6：AppRun共用型でアプリケーションを作成する
さくらのクラウドのコントロールパネルからAppRun共用型を開き、「アプリケーションの作成」を選択します。
今回の例では、次のように設定します。
| 項目 | 設定例 |
|---|---|
| アプリケーション名 | apprun-external-registry-demo |
| 最小スケール数 | 0 |
| 最大スケール数 | 1 |
| コンテナイメージ | ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v1 |
| ポート | 80 |
| リソース構成 | 0.5vCPU / 1GiB |
| ヘルスチェックパス | / |
| ヘルスチェックポート | 80 |
今回のPackageをPublicにしている場合、コンテナレジストリアクセス設定へのユーザー名・パスワード入力は不要です。
アプリケーション作成後は状態が「処理中」となり、正常にデプロイされると「正常」と表示されます。
状態が正常になったら、アプリケーション詳細に表示される公開URLからアクセスできます。
コンテナイメージを更新する
次に、index.htmlの表示をv1からv2へ変更します。
<p>Version: v2</p>v2タグでビルドしてGHCRへpushします。
docker buildx build \
--platform linux/amd64 \
-t ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v2 \
--push \
.AppRunのアプリケーション詳細から「アプリケーション構成を変更してデプロイ」を開き、コンテナイメージを変更します。
変更前
ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v1
変更後
ghcr.io/YOUR_GITHUB_USERNAME/apprun-external-registry-demo:v2AppRunの仕様では、最後にデプロイしたアプリケーション構成と今回の構成が同一の場合、新しいバージョンは作成されません。
そのため、同じlatestという指定を維持したままレジストリ側のイメージ内容だけを変更するより、次のように異なるタグを使用してAppRun側のデプロイソースも変更する方が、バージョンを明確に管理できます。
ghcr.io/example/app:v1
ghcr.io/example/app:v2
ghcr.io/example/app:a1b2c3d旧バージョンへトラフィックを戻すこともできる
AppRun共用型では、アプリケーションごとに最大5バージョンを保持できます。
また、最大4つのバージョンをトラフィック分散の対象として設定でき、それぞれ0～100％の割合を指定できます。割合の合計は100％にする必要があります。
例えば、v2からv1へ戻したい場合は、v1へ100％のトラフィックを割り当てる設定が可能です。
v1を90％、v2を10％といった割合にして、新しいバージョンへ一部のトラフィックだけを割り当てることもできます。
GHCRのPrivateイメージを使う場合
AppRun共用型では、コンテナレジストリが非公開の場合、コンテナレジストリアクセス設定としてユーザー名とパスワードを入力できます。
GHCRではPersonal Access Token（classic）を利用して認証できます。
GitHub公式では、パッケージをダウンロードするための権限としてread:packagesが定義されています。
| AppRun | GHCR |
|---|---|
| ユーザー名 | GitHubのユーザー名 |
| パスワード | read:packagesを持つPersonal Access Token（classic） |
なお、トークンを発行したGitHubユーザー自身が対象Packageを読み取れる権限を持っている必要があります。
うまく配備できないときに確認する場所
コンテナイメージを取得できない
- イメージ名とタグが正しいか
- 対象イメージがGHCRに存在するか
- PackageがPublicかPrivateか
- Privateの場合は認証情報が正しいか
Macで作ったコンテナを配備できない
イメージのアーキテクチャを確認します。
AppRun共用型はx86_64で動作するため、linux/amd64のイメージを利用します。
アプリへアクセスできない
AppRun側で設定したポートと、コンテナ内のアプリケーションが実際に待ち受けているポートが一致しているか確認します。
新しいバージョンが作成されない
最後にデプロイした構成と同じ内容を指定していないか確認します。
AppRunでは、構成情報が同一の場合、新しいバージョンは作成されません。
イメージサイズが大きい
AppRun共用型で利用できるコンテナイメージのサイズ上限は2GiBです。
Docker Hub・GHCR・さくらのコンテナレジストリはどう選ぶ？
外部レジストリへの対応によって選択肢が増えましたが、さくらのコンテナレジストリが利用できなくなったわけではありません。
| レジストリ | 選びやすいケース |
|---|---|
| Docker Hub | すでにDocker Hubでイメージを管理している場合や、対応する公開イメージを利用する場合 |
| GHCR | GitHubとコンテナイメージの管理を組み合わせている場合 |
| さくらのコンテナレジストリ | さくらのクラウドのサービスを利用してコンテナイメージを管理したい場合 |
外部コンテナレジストリの個別設定やトラブルは、さくらインターネットのサポート対象外です。この点も選択時に確認しておきたいポイントです。
外部レジストリ対応とは別に残るAppRun共用型の制約
今回変更されたのは、利用可能なコンテナレジストリです。
AppRun共用型そのものには、次の仕様があります。
永続ストレージは提供されていない
AppRun共用型では永続ストレージは提供されていません。
インスタンスごとに利用できるディスクは256MiBの一時領域です。
閉域ネットワークには接続できない
データベースなどがパブリックネットワーク上に公開されていればAppRun共用型から接続できますが、閉域ネットワークでの接続はできません。
HTTP・HTTPS以外は利用できない
AppRun共用型で現在サポートされているのはHTTPとHTTPSです。WebSocketsなどはサポートされていません。
独自ドメインはAppRun単体の機能としては提供されていない
AppRun共用型単体には独自ドメイン機能はありません。
公式FAQでは、さくらのウェブアクセラレータを経由する構成で独自ドメインを利用できると案内されています。
ログ・メトリクスはモニタリングスイートと連携する
AppRun共用型単体にはログ閲覧機能は提供されていません。
モニタリングスイートのストレージと連携することで、標準出力・標準エラーのログや、リクエスト数、レイテンシ、CPU・メモリ使用率などを確認できます。
CI/CD連携にはAPIを利用する
AppRun共用型はAPIを利用してGitHub ActionsなどのCI/CDツールと連携できます。
GitHubへpush
↓
GitHub Actions
↓
コンテナをビルド
↓
GHCRへpush
↓
AppRun API
↓
AppRunで新バージョンを作成外部レジストリへの対応と、AppRunへの自動デプロイは別の機能として考える必要があります。
まとめ
AppRun共用型は2026年5月28日の仕様変更で、Docker HubとGitHub Container Registryに対応しました。
これまで利用可能だったさくらのコンテナレジストリと合わせて、3種類のコンテナレジストリをデプロイソースとして利用できます。
今回変わったこと
- Docker HubのコンテナイメージをAppRunから利用できる
- GHCRのコンテナイメージをAppRunから利用できる
- Docker Hub・GHCRを使う場合、さくらのコンテナレジストリへの再登録を省ける
- PublicだけでなくPrivateのコンテナイメージも認証情報を設定して利用できる
今回の変更とは別に必要なこと
- 自作アプリではコンテナイメージをビルドする
- 対応レジストリへイメージをpushする
- AppRun側でアプリケーションや新しいバージョンを作成する
- CI/CDを自動化する場合はAppRun APIを利用する
したがって今回のアップデートは、「AppRunがソースコードから自動デプロイするサービスへ変わった」というものではありません。
AppRunがDocker Hub・GHCRからコンテナイメージを直接取得できるようになり、外部レジストリを利用している環境では、AppRunへ配備するまでに必要だったレジストリ間の登録工程を省けるようになった変更と整理するのが正確です。 ぜひ皆さんも使ってみてください。
