toitech

🆓

【ほぼ無料】WordpressをCloud Run+GCS+Supabaseで動かす

GCS

PHP

Supabase

Cloud Run

WordPress

Tech

1. はじめに

1.1. 背景 / なぜ Cloud Run + GCS + Supabase なのか

WordPress を運用する場合、一般的にEC2やGoogle Compute Engineなどに構築していました。（僕は昔、さくらVPSにホスティングしていました。）

しかし、近年はサーバーレスやマネージドサービスを活用することで、インフラ管理コストを大幅に削減できるようになっています。本記事で取り上げる構成では、以下のようなメリットがあります。

Cloud Run

コンテナをサーバーレスで稼働させ、アクセスに応じてスケール可能
一定の無料枠があるので、少ないコストで始められる

GCS (Google Cloud Storage)

WordPress の画像やメディアファイルを安全に保管
Cloud Run はローカルストレージが揮発性のため、GCS を使うことでメディア消失のリスクを回避

Supabase (PostgreSQL)

従来の MySQL の代わりに、PostgreSQL データベースを手軽に運用
Supabase Freeプランでも、小〜中規模サイトならほぼ無料で使える
REST API や Auth 機能なども備えているので、将来的な拡張性も高い

こうした理由から、「Cloud Run + GCS + Supabase」という構成で WordPress を動かすと、安価かつ拡張性の高いサーバレス運用を実現できます。

1.2. この記事で実現すること

本記事では、以下のような構成の WordPress 環境を Dockerfile を用いて構築し、最終的に Cloud Run 上にデプロイします。

WordPress を PostgreSQL で動かす

もともと MySQL 用に作られた WordPress を PostgreSQL で動かすため、PG4WP というプラグインを導入

WP-Stateless を使い GCS にメディアファイルを保存

Cloud Run はコンテナ再起動時にストレージ内容が失われる可能性があるため、メディアファイルの永続化 が不可欠
WP-Stateless を導入すると、WordPress のアップロード画像を自動的に GCS へ転送し、ストレージ消失のリスクを回避

Dockerfile の解説 & デプロイ手順

Dockerfile で必要な PHP 拡張 (pgsql, pdo_pgsql) やプラグインを追加
Cloud Run で使用されるポート番号 8080 に Apache を合わせる設定
最終的に gcloud コマンド などを使って Cloud Run にデプロイするまでの流れを示す

これにより、ローカルマシン上の Dockerfile 作成 → Artifact Registry へのプッシュ → Cloud Run デプロイ という一連の手順がわかります。

1.3. 前提

この構成を進めるには、以下の前提条件を満たしていることを想定しています。

GCP アカウント

GCP (Google Cloud Platform) のアカウントがあり、Cloud Run を有効化 できる状態
Cloud Storage (GCS) を使うために 課金設定 が完了していることが望ましい

Supabase アカウント

Supabase の無料プランでOK
プロジェクトを作成し、PostgreSQL の接続情報 (Host, Port, DB名, ユーザ, パスワード) を取得済み

Docker, gcloud CLI

ローカル環境で Docker イメージをビルドし、gcloud コマンドで Cloud Run にデプロイするため
Docker と gcloud CLI (または Cloud Shell) を利用する

最終的にほぼ無料 / 最小限のコストで稼働

Cloud Run の無料枠、Supabase の無料プラン、GCS の低コスト利用を組み合わせてできる限りコストを抑える
アクセス量が増大した場合はプランのアップグレードなどで対応を検討

以上の前提をもとに、本記事では 「Cloud Run + GCS + Supabase」という構成で WordPress を動かす までの流れを詳しく解説していきます。

2. 全体アーキテクチャの概要

2.1. Cloud Run で WordPress の Dockerコンテナをサーバーレス実行

まず、本記事の中心となるのが Google Cloud Run です。

サーバーレス: アプリケーションをコンテナ化しデプロイすると、Google が自動でスケーリングやロードバランシングを行い、使用した分だけ課金されます。
Docker コンテナ: WordPress の実行環境をすべてパッケージングしておけば、環境差異やライブラリの不整合を気にせずデプロイ可能。
無料枠あり: 軽量なサイトならコストをほぼゼロに抑えられるのも大きな魅力です。

この部分では WordPress + Apache + PHP + プラグイン を含んだ Docker イメージをビルドし、Cloud Run にアップロードして稼働させます。

2.2. Supabase (PostgreSQL) で WordPress のDBを管理

Supabase は、ホスティングされた PostgreSQL を主軸としたフルスタックプラットフォームです。

無料プラン から始められて、ちょっとした個人サイトやブログ規模なら十分動作します。
本来 WordPress は MySQL を前提としていますが、PG4WP というプラグインを使うことで PostgreSQL に対応させられます。
Supabase プロジェクト を作り、そこで提供されるホスト名、ポート番号、DB名、ユーザ名、パスワードを利用して接続。
将来的にアクセスが増えた場合は有料プランへのアップグレードや他の PostgreSQL 運用方法への移行も検討可能。

2.3. GCS (Google Cloud Storage) にメディアファイルを保管

WordPress は記事内でアップロードする画像やファイルを wp-content/uploads に保存する設計です。しかし Cloud Run のファイルストレージは揮発性 なので、再起動やスケールアウト時にアップロードファイルが消えてしまう問題があります。これを解決するために GCS (Google Cloud Storage) を採用します。

WordPress のメディアファイルを WP-Stateless プラグインで GCS に保存することで、永続的にファイルを保管
過去の画像が消えたり、コンテナ再起動でファイルが失われる心配がなくなる
GCS は世界規模の高い耐久性と可用性を備えたストレージサービスで、数GB程度なら非常に安価

2.4. リクエストフロー: Cloud Run (WordPress) → PG4WP → Supabase DB, メディアは GCS から配信

最終的な動きは以下のようになります:

ユーザがサイトURLにアクセス → Cloud Run 上の WordPress コンテナがリクエストを受ける
WordPress が DB に問い合わせ → PG4WP プラグインを通じて Supabase (PostgreSQL) に接続
記事データやオプション情報 を取得し、動的にページを生成
メディアファイル (画像や添付ファイル) は、Cloud Run 内のローカルディスクではなく、WP-Stateless を介して GCS 上に保存・取得
ブラウザ は表示されたページの中にある画像リンクをたどると、GCS から直接ファイルが配信される

このように、アプリロジック と 静的ファイルストレージ、DB を切り分けた構成により、サーバーレスかつ低コストで安定した WordPress 運用が可能になります。

3. Supabase の設定

3.1. Supabase プロジェクトの作成

まずは Supabase のサイトにアクセスし、新規アカウントを作成します。

Sign up して、メールアドレスとパスワードでログイン。
New project ボタンをクリックし、必要事項を入力してプロジェクトを作成します。

無料プランでも PostgreSQL のインスタンスが利用できる
リージョンを選択しておくと、Cloud Run と同じリージョンに合わせることでレイテンシが低くなります

プロジェクトの作成が完了すると、Supabase のダッシュボードにアクセスできます。そこには PostgreSQL の接続情報（ホスト名、ポート、ユーザ、データベース名）が記載されています。

メモ: 以下のような形式の接続情報を控えておきましょう。

3.2. PostgreSQL の初期状態

新規プロジェクトでは、postgres というスーパーユーザーが設定されており、データベース名も postgres になっている場合が多いです。

WordPress 用に新しいユーザとDBを作る 方法もありますが、初期状態のままでも構いません。
WordPress の wp-config.php (または本記事で使う環境変数 WORDPRESS_DB_***) で、このユーザ名・パスワード・DB名を指定すれば接続可能です。

なお、別ユーザ を作成したい場合は、Supabase ダッシュボード上の SQL エディタなどを使って以下のようなコマンドを実行して作成します。

CREATE USER wpuser WITH PASSWORD 'password';
CREATE DATABASE wpdb;
GRANT ALL PRIVILEGES ON DATABASE wpdb TO wpuser;

ただし最初はシンプルにデフォルト (postgres ユーザ / DB) を利用する方がトラブルが少なくおすすめです。

3.3. 接続情報確認

最終的に、Cloud Run にデプロイした WordPress がこの PostgreSQL に接続するため、以下の情報を必ずメモしておきます。

HOST: db.xxxxx.supabase.co
PORT: 5432 (PostgreSQLの標準ポート)
DB_NAME: 通常 postgres (または作成した独自のDB名)
USER: postgres など
PASSWORD: Supabase ダッシュボードで表示されたキー

Cloud Run にデプロイする際、環境変数 (WORDPRESS_DB_HOST, WORDPRESS_DB_USER, WORDPRESS_DB_PASSWORD, WORDPRESS_DB_NAME) へそれぞれ割り当てることで、本番環境でも WordPress が正常に動作します。

4. GCS と WP-Stateless の設定

4.1. GCS バケット作成

まずは Google Cloud Storage (GCS) でメディア保存用のバケットを作ります。

GCP コンソール を開き、左メニューから 「Storage」 → 「ブラウザ (Browser)」 を選択
「バケットを作成 (Create bucket)」 ボタンをクリック
バケット名 (例: my-wordpress-bucket) とリージョンを指定

リージョンは、Cloud Run と同じリージョンを選ぶとレイテンシが低くなります

保存クラス（Standard など）はお好みで。アクセス頻度が高いなら Standard が無難
バケットのパブリック設定は後から変更可能なので、とりあえずデフォルトでもOK
バケットを作成

続いて、GCSのBucketをパブリックアクセス可能な設定を入れます。

このデフォルトの状態では、アップロードしたファイルは認証されたユーザーのみがアクセス可能です。任意のユーザーが閲覧できるようにするには、バケットの IAM & ポリシー設定 を変更します。

GCS の 「ブラウザ (Browser)」 画面から作成したバケットを選択
「権限 (Permissions)」 タブを開く
「+ 権限を追加 (Add permissions)」 ボタンをクリック
「プリンシパル (Principal)」 に allUsers を入力
「ロール (Role)」 で 「ストレージオブジェクト閲覧者 (Storage Object Viewer)」 を選択
「保存 (Save)」 をクリック

これにより、GCS にアップロードされたすべてのオブジェクトが パブリックに閲覧可能 になります。

これで WordPress のメディアがアップロードされる先 となる GCS バケットが用意できました。

4.2. サービスアカウント作成 (JSONキーの取得)

WP-Stateless で GCS にファイルをアップロードするには、書き込み権限を持ったサービスアカウントを用意する必要があります。

GCP コンソール > IAM と管理 > サービスアカウント
「サービスアカウントを作成」 ボタンをクリック

「表示名 (Service Account name)」に wp-stateless-uploader などの分かりやすい名前
サービスアカウントIDが自動生成される

ロール (役割) で Storage Object Admin (または Storage Admin) を選択

これによりバケット内のオブジェクトを作成・削除・更新が可能

作成後、「キーの管理」 から 「新しいキーを作成」 → JSON を選択 → ファイルをダウンロード

このJSONファイルには秘密鍵が含まれるため、安全に保管

WP-Stateless がこの JSON キーを使って GCS バケットに対して読み書き を行います。キーを紛失したり公開リポジトリに入れないよう注意しましょう。

4.3. WP-Stateless プラグインの概要

WP-Stateless は、WordPress のメディアライブラリを Google Cloud Storage に同期/移動するためのプラグインです。

Stateless モード: アップロード時にすぐ GCS にファイルを保存し、ローカルには保管しない
Ephemeral / CDN モードなどもありますが、Cloud Run ではローカルストレージが揮発的なため、Stateless が便利
管理画面から「Service Account JSON」欄に先ほどの JSON キーを貼り付け、Project ID / Bucket 名 を指定するだけで OK
これによって、メディアのアップロード先が自動的に GCS になり、コンテナ再起動しても画像が消えない ようになります

後ほど解説する Dockerfile では、このプラグインを自動でダウンロード＆配置し、コンテナビルド時点で組み込む形を採用します。

5. Dockerfile での構築ポイント

ここでは Dockerfile を作成する際の重要なポイントを解説します。また、最後に全体のDockerfileも掲載します。この Dockerfile をビルドすれば、WordPress + PostgreSQL接続 (PG4WP) + WP-Stateless + オリジナルテーマ をすべて含んだイメージを作成し、Cloud Run 上で動かせるようになります。

Dockerfile の各ステップ解説

ベースイメージ選択
FROM wordpress:6.5.3-php8.2-apache

WordPress のバージョンを指定し、PHP と Apache があらかじめ入ったイメージを利用
latest にすると WordPress バージョンが変わり続ける可能性があるため、安定運用なら固定を推奨

PostgreSQL 拡張インストール
RUN set -eux; \ apt-get update && apt-get install -y libpq-dev \ && docker-php-ext-install pdo_pgsql pgsql \ && rm -rf /var/lib/apt/lists/*

WordPress はデフォルトで MySQL 用
PostgreSQL へ接続するために pdo_pgsql / pgsql を有効化

PG4WP (PostgreSQL for WordPress) の配置
COPY pg4wp /var/www/html/wp-content/plugins/pg4wp RUN cp /var/www/html/wp-content/plugins/pg4wp/db.php \ /var/www/html/wp-content/db.php

MySQL 用のクエリを PostgreSQL 用に翻訳するプラグイン
db.php を wp-content/ 直下に置き、WordPress がこれを優先的に読み込む仕組みにする

unzip & WP-Stateless ダウンロード
RUN apt-get update && apt-get install -y unzip \ && rm -rf /var/lib/apt/lists/* RUN set -eux; \ curl -o /tmp/wp-stateless.zip "https://downloads.wordpress.org/plugin/wp-stateless.zip" \ && unzip /tmp/wp-stateless.zip -d /tmp \ && mv /tmp/wp-stateless /var/www/html/wp-content/plugins/wp-stateless \ && rm -rf /tmp/wp-stateless*

Cloud Run はファイルシステムが揮発するため、WP-Stateless + GCS でメディアを保存
ここでプラグインのzipを取得 & 解凍し wp-content/plugins/wp-stateless に配置

オリジナルテーマをCOPY
COPY my-theme/ wp-content/themes/my-theme/

ローカルで解凍済みのテーマフォルダ my-theme/ を同梱
カスタムテーマもコンテナに含めることで、再起動してもテーマが消えない

ファイル所有者の変更
RUN chown -R www-data:www-data /var/www/html

WordPress (PHP) は www-data ユーザで実行されるため、書き込み権限を確保

Apache の Listen ポートを 8080 に変更
RUN sed -i 's/Listen 80/Listen 8080/' /etc/apache2/ports.conf \ && sed -i 's/<VirtualHost \*:80>/<VirtualHost \*:8080>/' /etc/apache2/sites-available/000-default.conf EXPOSE 8080 EXPOSE 80 CMD ["apache2-foreground"]

Cloud Run はデフォルトで $PORT=8080 にトラフィックを送るため、Apache 側も 8080 で listen
EXPOSE 8080 により、そのポートを公開
EXPOSE 80 はオプション扱いだが残していても問題なし

これで WordPress + PostgreSQL + WP-Stateless + カスタムテーマ を一体化したコンテナイメージがビルド可能になります。

最終的な Dockerfile

## (例) PHP 8.x + Apache 版の公式イメージをベースにする
FROM wordpress:6.5.3-php8.2-apache

## 必要な PHP 拡張をインストール
RUN  -eux; \
    
    apt-get update && apt-get install -y \
        libpq-dev \
    && docker-php-ext-install pdo_pgsql pgsql \
    && rm -rf /var/lib/apt/lists/*

## WordPress を置くディレクトリ
WORKDIR /var/www/html

## PG4WP のプラグインをコピー
## (PG4WP 一式をあらかじめローカルに用意しておく)
COPY pg4wp /var/www/html/wp-content/plugins/pg4wp

## db.php-dist を db.php にリネームして wp-content/ の直下に配置
RUN  /var/www/html/wp-content/plugins/pg4wp/db.php \
       /var/www/html/wp-content/db.php

## unzip をインストール (WP-Stateless zip解凍用)
RUN apt-get update && apt-get install -y unzip \
    &&  -rf /var/lib/apt/lists/*

## WP-Stateless プラグインをダウンロードして配置
RUN  -eux; \
    curl -o /tmp/wp-stateless.zip  \
    && unzip /tmp/wp-stateless.zip -d /tmp \
    &&  /tmp/wp-stateless /var/www/html/wp-content/plugins/wp-stateless \
    &&  -rf /tmp/wp-stateless*

## カスタムテーマをコピー
## (ローカルに解凍済みの "my-theme/" フォルダ)
COPY my-theme/ wp-content/themes/my-theme/

## ファイル所有権を調整
RUN  -R www-data:www-data /var/www/html

## ApacheのListenポートを8080に変更 (Cloud Runは8080を使う)
RUN sed -i  /etc/apache2/ports.conf \
    && sed -i  /etc/apache2/sites-available/000-default.conf

## Cloud Runでよく使う8080をEXPOSE
EXPOSE 8080

## (オプション) ポート80も一応EXPOSEしておく
EXPOSE 80

## コンテナ起動時にApacheを起動
CMD []

ビルドと実行のイメージ

## Dockerfile があるディレクトリへ
docker build -t my-wp-image .

## ローカルでテストするなら:
docker run -d -p 8080:80 my-wp-image
## (Cloud Run では後ほど --port=8080 に合わせる)

ブラウザで http://localhost:8080 にアクセスし、WordPress の初期インストール画面が表示されればOK
Cloud Run デプロイ時には、このイメージを Google Artifact Registry や Container Registry にプッシュしてから gcloud run deploy を実行します。

このように Dockerfile によって、WordPress のコアからプラグイン・テーマ、さらに PostgreSQL 対応や GCS 連携までを一括して構築できるのが大きなメリットです。

6. Cloud Run にデプロイ

Google Artifact Registry / Container Registry にイメージをPush

例:
docker build -t asia-northeast1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/wordpress-supabase:latest . docker push asia-northeast1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/wordpress-supabase:latest

Cloud Run にデプロイ
gcloud run deploy wordpress-supabase \ --image asia-northeast1-docker.pkg.dev/YOUR_PROJECT_ID/my-repo/wordpress-supabase:latest \ --platform managed \ --region asia-northeast1 \ --allow-unauthenticated

ここで --allow-unauthenticated を付けると一般公開され、誰でもアクセスできるURLとなります

環境変数設定 (PostgreSQL接続)

デプロイ時または Cloud Run の管理画面 > [サービス] > 「編集とデプロイ」 > 「変数とシークレット」などで設定
WORDPRESS_DB_HOST = db.xxxxx.supabase.co:5432 WORDPRESS_DB_USER = postgres WORDPRESS_DB_PASSWORD = <Supabaseのパスワード> WORDPRESS_DB_NAME = postgres

WP-Stateless のキー設定

デプロイ完了後、Cloud Run のURLを開き、WordPress 管理画面にログイン
「設定 > WP-Stateless」 を開き、

Bucket 名: my-wordpress-bucket
Project ID: GCPプロジェクトID (例: my-gcp-project)
Service Account JSON: 先ほど作成したサービスアカウントキー全体 ({ ... }) を貼り付け

「Stateless」モードを選んで保存すればOK

7. WordPress のセットアップ

最初のアクセス: Cloud Run デプロイが完了した URL（例: https://wordpress-supabase-abc123.run.app）にアクセスすると、WordPress のインストール画面が表示されます。
DB情報入力: 通常は MySQL 用の項目が出ますが、内部では PG4WP が動作しているため、そのまま「DB名」「ユーザ」「パスワード」を入れて進めば PostgreSQL に接続可能
サイト名・管理ユーザ設定: WordPress 通常の初期設定と同じ手順
管理画面にログイン: プラグイン一覧から WP-Stateless を有効化し、GCS 連携設定を完了させる
画像アップロードテスト: メディア → 新規追加で画像をアップロードし、GCS バケットにファイルが生成されていれば成功

Cloud Run のコンテナを再起動しても画像が失われないことを確認

8. 運用のポイント

テーマ・プラグイン更新

WordPress のプラグイン更新機能を使うと、再起動で変更が消えてしまう可能性があります
安定運用には Dockerfileに含める or Bindマウントなど で管理するフローを確立しましょう
メディアは WP-Stateless 経由で GCS に保存されるため安心

Supabase の負荷管理

Freeプランで負荷が高いとパフォーマンスに限界があります
アクセスが増えたら有料プランへのアップグレードや、Cloud SQL for PostgreSQL 等への移行も視野に

コスト試算

Cloud Run 無料枠、GCS のわずかなストレージコスト、Supabase Freeプラン、これらを組み合わせると小規模サイトならほぼ無料で運用可能
PV が増加してリソース使用量が大きくなると、それに応じてコストも加算される

9. まとめ

今回紹介したように、

Cloud Run でコンテナをサーバレス運用
Supabase (PostgreSQL) で WordPress を動かす (PG4WP を活用)
GCS + WP-Stateless でメディアファイルを恒久的に保存

という構成を組み合わせると、ほぼ無料 かつ サーバレス な WordPress 環境を実現できます。 Dockerfile さえ整えてしまえば、再ビルドや再デプロイも容易で、バックエンドの管理コストを大きく削減可能です。

今後の拡張としては、独自ドメイン / HTTPS 設定 や Cloud CDN、CI/CD パイプライン の導入などがあります。まずはこの構成でサイトを構築し、アクセス数が増えても安心してスケールできる WordPress 運用をぜひお試しください。

追記：独自ドメインは、お名前ドットコムの1年目無料のものを購入したので、これまた無料。HTTPS設定も、Cloud Runの「カスタムドメインを管理」からDNSレコードの値を取得し、お名前ドットコムのDNSレコードを更新すれば、HTTPSも対応できます。

toitech

株式会社ヤードの代表で、Yardの開発者です。データプロダクトの受託開発や技術顧問・アドバイザーもお受けしております。 #データ利活用 #DevOps #個人開発

フォロー

【ほぼ無料】WordpressをCloud Run+GCS+Supabaseで動かす

1. はじめに

1.1. 背景 / なぜ Cloud Run + GCS + Supabase なのか

1.2. この記事で実現すること

1.3. 前提

2. 全体アーキテクチャの概要

2.1. Cloud Run で WordPress の Dockerコンテナをサーバーレス実行

2.2. Supabase (PostgreSQL) で WordPress のDBを管理

2.3. GCS (Google Cloud Storage) にメディアファイルを保管

2.4. リクエストフロー: Cloud Run (WordPress) → PG4WP → Supabase DB, メディアは GCS から配信

3. Supabase の設定

3.1. Supabase プロジェクトの作成

3.2. PostgreSQL の初期状態

3.3. 接続情報確認

4. GCS と WP-Stateless の設定

4.1. GCS バケット作成

4.2. サービスアカウント作成 (JSONキーの取得)

4.3. WP-Stateless プラグインの概要

5. Dockerfile での構築ポイント

Dockerfile の各ステップ解説

最終的な Dockerfile

ビルドと実行のイメージ

6. Cloud Run にデプロイ

7. WordPress のセットアップ

8. 運用のポイント

9. まとめ

toitech

株式会社ヤードの代表で、Yardの開発者です。 データプロダクトの受託開発や技術顧問・アドバイザーもお受けしております。 #データ利活用 #DevOps #個人開発

Read next

株式会社ヤードの代表で、Yardの開発者です。データプロダクトの受託開発や技術顧問・アドバイザーもお受けしております。 #データ利活用 #DevOps #個人開発