自宅 Lifebook で動かすチーム用 Wiki を Cloudflare Tunnel + Access で公開した話

家に眠っていた Lifebook（Ubuntu Server 化済み）の上に、Docker で Wiki.js を立て、Cloudflare Tunnel + Cloudflare Access 経由でチームに公開する仕組みを組みました。ポート開放・固定 IP・有償サービスのいずれも使わず、月コスト $0 + ドメイン年 $10 だけで完結しています。

タスクは GitHub Issues で管理しながら 1 週間ほどかけて構築しました（実作業時間はトータルで 6〜8 時間程度）。この記事ではその全工程を、設計判断の背景込みで書き残します。

想定読者: 「自宅サーバーに何か立てて外部公開したい」「Cloudflare Tunnel と Access を実運用で組み合わせた事例が欲しい」「Wiki.js を Docker Compose で運用したい」といった方を想定しています。

---

ゴール

• チーム内（開発者と非開発者が混在）で ドキュメントを共有できる場所 が欲しい
• 無料運用 したい（継続コストはドメインの年 $10 まで）
• 認証あり。誰でも閲覧可能ではないこと
• ページ単位で権限 を切れること
• メンバーに余計なクライアント（Tailscale 等）を入れさせたくない
• ガチガチのセキュリティは不要だが、それなりに堅いこと

結論先取り: 採用構成

flowchart TB
    Browser["メンバーのブラウザ"]

    subgraph CFEdge["Cloudflare Edge"]
        direction TB
        Access["Cloudflare Access<br/>Email OTP / Session 1 week"]
        Tunnel["Cloudflare Tunnel"]
        Access --> Tunnel
    end

    subgraph LF["Lifebook (Ubuntu Server, Wi-Fi)"]
        subgraph Compose["docker compose"]
            direction TB
            cloudflared["cloudflared"]
            wiki["wiki<br/>(Wiki.js v2)"]
            db[("db<br/>(PostgreSQL 16)")]
            backup["backup<br/>cron で pg_dump → rclone sync"]
            cloudflared --> wiki
            wiki --> db
            backup --> db
        end
    end

    R2[("Cloudflare R2<br/>wiki-backup bucket<br/>off-site / AES-256 at-rest")]

    Browser -- "HTTPS (wiki.example.com)" --> Access
    Tunnel -- "outbound 持続接続" --> cloudflared
    backup -- "rclone sync" --> R2

ポイントを整理すると以下になります。

• Cloudflare Tunnel で外向き接続のみで公開します。ポート開放・固定 IP 不要・HTTPS 自動・家庭 Wi-Fi で動きます
• Cloudflare Access（Zero Trust Free）で wiki に到達する前に Email OTP の認証ゲートを挟みます。50 ユーザーまで無料・無期限です
• Wiki.js v2 はページ単位 ACL が標準機能、Markdown ネイティブ、UI もモダンです
• Cloudflare R2 で off-site バックアップ。Free tier 10GB（wiki dump 規模では数十年余裕の容量）
• Lifebook 管理用の SSH / Cockpit は Tailscale 経由 のまま残し、wiki だけを Cloudflare 経由で公開します

---

1. 動機と要件

なぜチーム用 Wiki なのか

友人たちとドキュメントやナレッジを共有する動きが出てきそうな雰囲気を感じていて、その器が欲しかったのが出発点です。小規模（10 名未満を想定）で、開発者と非開発者が混じるグループになります。Notion / Confluence / Google Workspace のような SaaS を契約するほどではなく、GitHub Wiki ではメンバー全員に GitHub アカウントを強制したくありません。プライベートな話題も扱うため、無料の公開 Wiki ホスティングは選択肢に入りませんでした。

なぜ自宅サーバーなのか

高専時代に使っていた Windows ノート PC（Lifebook）に、ある日「何か遊びたいな〜」と思い立って Ubuntu Server を入れ、その流れで Docker / Tailscale など諸々セットアップしていたものが手元にありました。最初から homelab を立てる明確な目的があったわけではなく、寝かせておくのももったいないので触っていた、というくらいの動機です。そんなときに友人たちとのナレッジ共有の場が欲しくなり、「ちょうどあの Lifebook を使えばいいじゃん」と思い至ったのがきっかけでした。

月数百円のクラウド VPS と比べても、24 時間稼働させていて電気代以外のランニングコストがかからない自宅機の優位性は大きいです。

ノート PC を常時起動のサーバーにするうえでの注意点は、熱対策（蓋を閉じた状態でヘッドレス運用するので底面通気を確保する）と、Wi-Fi 経由で接続している場合の断面ハンドリングくらいでしょうか。今回は cloudflared が自動再接続してくれる前提で、Wi-Fi 構成のまま進めました。

要件の整理

#	要件	備考
1	月コスト ≦ 0 円	ドメイン代（年 $10）は固定費として許容します
2	認証あり	メンバーごとに識別できることが条件です
3	ページ単位の権限	「全員に見せるページ」「役職限定」「個人」の切り分けが必要です
4	クライアント追加なし	メンバー側にアプリ / VPN を入れさせない
5	ポート開放なし	家庭用ルータの設定変更なし、ISP の規約も気にしない
6	自分が普段管理しやすい	Tailscale 経由の SSH + VS Code Remote SSH で運用

検討した公開方式

案	Pros	Cons	採否
Tailscale 招待のみ	最も堅牢、設定が簡単	Personal プラン無料枠 3 ユーザーまで。メンバー全員に Tailscale 導入が必須	×
Tailscale Funnel	tailnet 外から HTTPS 公開可能、TLS 終端は Tailscale 任せ	認証は wiki 側のみ、URL がパブリックに露出する	×
Cloudflare Tunnel + Access	50 ユーザーまで無料・無期限。wiki 前段に SSO/OTP を挟める。独自ドメイン運用が可能	ドメイン代（年 $10）が必要	○
ngrok / Localtunnel	雑にやるなら最速	認証が弱い、URL がランダムで変わる、無料枠の制限が厳しい	×

Cloudflare Tunnel + Access の組み合わせは、要件 1〜5 のすべてを単独で満たせる構成でした。

検討した Wiki エンジン

候補	採否	寸評
Wiki.js v2	◎ 採用	ページ単位 ACL、Markdown ネイティブ、UI モダン、Node.js + PostgreSQL
BookStack	△ 第二候補	Shelf > Book > Chapter > Page 構造、UX 平易、権限粒度はやや粗い
DokuWiki	×	軽量・DB 不要だが UI が古く、Markdown ネイティブではない
Outline	×	リソース要件が高め、OAuth プロバイダ必須
Confluence Cloud	×	有料

第二候補の BookStack も触る予定でしたが、Wiki.js を最初に立ててみてセットアップから初回ホーム到達まで詰まりなく進んだので、そのまま採用に切り替えました。BookStack を試さなかったのは少し心残りですが、Wiki.js v2 の運用に不満は出ていません（v3 は長期ベータのため不採用としました）。

---

2. 役割分担と運用フロー

MacBook を開発機、Lifebook を運用機 として明確に分ける構成にしました。Lifebook はディスプレイ・キーボードを繋がずヘッドレスで動かし、操作はすべて MacBook から Tailscale 経由の SSH で行います。

機材	担当
MacBook（開発機）	docker-compose.yml・cloudflared 設定・バックアップスクリプトの編集、Git 管理
Lifebook（運用機）	コンテナ実行、データ保管（NVMe SSD）、バックアップ実行

更新フローは以下のとおりです（以降のコマンド例では、MacBook の ~/.ssh/config に Host lifebook のエイリアスを書いてある前提で ssh lifebook と表記します）。

MacBook で編集
  ↓ git push
GitHub (private repo: <you>/wiki)
  ↓ MacBook から Tailscale 経由で SSH:
  ↓   ssh lifebook
  ↓ Lifebook 上で:
  ↓   git pull
  ↓   docker compose --profile tunnel --profile backup up -d

コードの編集自体は MacBook のローカルで完結させてリポジトリに push する流れですが、Lifebook 上の .env を直接いじりたい場合や、即時バックアップを走らせたい場合などの「サーバー側だけで完結する作業」は、VS Code Remote SSH もしくは素の SSH で接続して済ませます。

当たり前ですが、シークレット類（Cloudflare Tunnel トークン、DB パスワード、R2 API キー）は Git に含めず、Lifebook 上の .env で管理します。リポジトリには .env.example だけを含めています。

---

3. 構築の流れ

GitHub Issues を立てて、依存順に潰していきました。ここからは各フェーズで何をやったか、何にハマったかを順に書きます。

フェーズ 0: ドメインと Cloudflare アカウント

• Cloudflare Registrar で example.com を取得しました（年 $10 ちょっと）
• レジストラ＝DNS プロバイダがどちらも Cloudflare なので NS 委譲・伝搬確認は不要でした
• wiki 用には wiki.example.com をサブドメインとして使います
• ルート example.com は将来の個人サイト用に温存します

これで前提条件はクリア。実コストの発生はここだけです。

フェーズ 1: Wiki エンジンをローカルで動かす

最初に作った docker-compose.yml は wiki + DB + cloudflared の 3 サービス構成でした。ただし「ローカル疎通確認」段階では cloudflared を起動したくありません（Tunnel トークンがまだ無いため）。

最初は素朴にこう書いていました。

cloudflared:
  image: cloudflare/cloudflared:latest
  environment:
    TUNNEL_TOKEN: ${CLOUDFLARE_TUNNEL_TOKEN:?CLOUDFLARE_TUNNEL_TOKEN is required}

:? ガードを置いて「未設定なら起動失敗」にしたつもりだったのですが、これが第一の落とし穴になりました（詳細は後述「学び」セクションで触れます）。結局 Compose profile を使って cloudflared をデフォルト起動から外す構造に変更しています。

cloudflared:
  image: cloudflare/cloudflared:latest
  environment:
    TUNNEL_TOKEN: ${CLOUDFLARE_TUNNEL_TOKEN:-}
  profiles:
    - tunnel

これにより：

• docker compose up -d → db + wiki のみ起動（ローカル疎通用）
• docker compose --profile tunnel up -d → cloudflared も含めて全部起動（本番）

:? を :-（empty 許容）に変えて、profile で起動制御するという二段構えになりました。

ローカルでの初期セットアップ手順は以下のとおりです。

1. MacBook から Lifebook に SSH 接続し、Lifebook 上で git clone
2. SSH セッション内で .env に POSTGRES_PASSWORD だけを設定
3. wiki サービスの ports: ["127.0.0.1:3000:3000"] を一時的に有効化
4. SSH セッション内で docker compose up -d
5. 別の MacBook ターミナルから ssh -L 3000:127.0.0.1:3000 lifebook でポートフォワード
6. MacBook のブラウザで http://localhost:3000 を開いて初期セットアップウィザードを進める

SSH ポートフォワードで localhost を使うと、IPv6 の ::1 側に解決されて Docker の 127.0.0.1 バインドに繋がらないことがあります。127.0.0.1 を明示するのが確実です。

セットアップ完了後、ports: を元に戻します。

フェーズ 2: Cloudflare Tunnel で外部公開

Cloudflare Zero Trust ダッシュボード（one.dash.cloudflare.com）で以下を行います。

1. Networks → Tunnels → Add a tunnel → Cloudflared
2. Tunnel 名: wiki-tunnel
3. Save → トークン取得（eyJ... 形式の JWT）
4. Public hostname: wiki.example.com → http://wiki:3000
   • Service URL に localhost:3000 ではなく wiki:3000 を使うことが重要です。cloudflared コンテナから見た localhost は cloudflared 自身を指してしまいます。Docker Compose のサービス名で内部 DNS 解決させましょう
5. Save

Lifebook 側では：

# .env に CLOUDFLARE_TUNNEL_TOKEN を追加
nano .env

# tunnel profile を含めて起動
docker compose --profile tunnel up -d
docker compose logs cloudflared
# → "Registered tunnel connection ..." が複数行（CF Edge の複数 PoP に接続）

Cloudflare ダッシュボード側で Tunnel が HEALTHY に変わり、https://wiki.example.com でアクセスできるようになりました。この時点ではまだ認証なしで世界中からアクセスできる状態なので、Wiki.js のログイン画面が前段に立っているだけが防御になっています。次のフェーズで認証ゲートを乗せます。

フェーズ 3: Cloudflare Access で認証ゲート

Tunnel 公開と同じタイミングで Access を有効化したかったので、設計順としては Access を先に設定してから Tunnel の public hostname を追加するのが安全です。

IdP の選定

候補	採否	寸評
Google 個人 / Workspace	×	全員が Gmail を持っている確証がなく、Workspace 契約もない
GitHub	×	非開発者のメンバーがアカウントを持たない
Email OTP（One-time PIN）	◎	Cloudflare 同梱で IdP 追加設定不要。任意のメールで使える。月数回ペースなら手間も許容範囲

メンバーが「開発者 + 非開発者の混在」だった時点で、特定の OAuth プロバイダに縛れない条件になりました。最終的に Email OTP を採用しています。Cloudflare Access は複数 IdP を併用できるので、必要になったら後から Google を足すこともできます。

Application の設定

Zero Trust → Access controls → Applications → Add an application → Self-hosted（新しい UI では Public DNS タブ）で以下のように設定しました。

項目	値
Application name	Team Wiki
Application domain	wiki.example.com
Session Duration	1 week
Identity providers	One-time PIN のみ
Apply instant authentication	ON（IdP 選択画面をスキップ）

そして Allow policy として Approved members を作成し、Selector に許可するメールアドレスを列挙しています。

認証画面の表示ドメイン問題

最初にブラウザで https://wiki.example.com を開いて確認したとき、Cloudflare Access のログイン画面に表示されるドメインが意図しないものになっていました。

.cloudflareaccess.com（auto-generated）

URL バー側は <your-team>.cloudflareaccess.com/cdn-cgi/access/login/... で正しいのに、カード上のラベルだけが auto-generated のままだったのです。これは Settings → Custom pages → Access login page → “Your organization’s name” で別管理になっていて、Team name 設定とは同期しない仕様でした。手動で <your-team>.cloudflareaccess.com に書き換えて解決しました。

知らないと招待時にメンバーが「何だこの謎ドメインは」となるので、要注意ポイントです。

フェーズ 4: ページ権限の設計

Wiki.js は Groups と Page Rules で柔軟に権限を切れます。とはいえメンバーが 1 人（自分だけ）の段階で複雑な階層設計をしても机上論になります。YAGNI 原則 で最小構成にしました。

グループ	役割
Administrators（デフォルト）	フル権限
Members（新規作成）	読み書き・新規作成・履歴・画像アップロードは可。削除と admin 系は不可
Guests（デフォルト）	何も読めない（Cloudflare Access で前段ゲートしているので実質到達しない）

Members グループの permissions は以下のとおりです。

• ○ read:pages / read:source / read:history
• ○ write:pages / manage:pages
• ○ read:assets / write:assets
• ○ read:comments / write:comments
• × delete:pages — 削除は admin に集約します
• × manage:assets — アセット削除も admin に集約
• × write:styles / write:scripts — CSS/JS 注入は XSS リスクがあるため除外
• × Users / Administration セクション全部

Page Rules では path Starts with /（全パス対象）に上記権限を ALLOW で設定しました。「特定パスだけ閲覧制限」のような要望が出てきた時点で別グループを追加する戦略にしています。

フェーズ 5: バックアップと災害復旧の自動化

設計メモには「DB dump を cron / systemd timer で定期取得 → 別ディスク or 外部に同期」とありました。homelab とはいえ、ローカル単一コピーだけだとディスク故障に耐えられないので、off-site 同期 までスコープに含めました。

バックアップ先の選定

候補	採否	寸評
Cloudflare R2	◎	既に Cloudflare アカウント所有。Free tier 10GB（wiki 規模で数十年余裕）。S3 互換
Backblaze B2	△	無料枠 10GB。クレジットカード不要だが Cloudflare との 2 ベンダー化になる
別マシンへ rsync	×	物理的に別マシンを持たない
同一マシンの別ディスク	×	ディスク故障耐性なし

R2 一択でした。Wiki.js v2 はアップロードを含む全コンテンツを DB に保存するため、pg_dump 1 本で完全バックアップ になります（filesystem 側の別途同期は不要）。これがメンテナンスの単純さで大きく効いています。

backup サイドカーの実装

services/wiki/backup/ 配下に Alpine ベースの custom image を置きました。

FROM alpine:3.20
RUN apk add --no-cache postgresql16-client rclone dcron tini bash coreutils
COPY backup.sh /usr/local/bin/backup.sh
COPY restore.sh /usr/local/bin/restore.sh
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /usr/local/bin/backup.sh /usr/local/bin/restore.sh /entrypoint.sh

ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/entrypoint.sh"]

ENTRYPOINT と CMD を分けた理由は後ほど触れます。3 つのスクリプトの役割は次のとおりです。

• entrypoint.sh — 環境変数を /etc/backup.env に single-quote escape で書き出し、crontab をセットし、BusyBox crond で常駐させる
• backup.sh — pg_dump -Fc | gzip → ローカル /backups → ローテーション → rclone sync で R2 に同期
• restore.sh — 指定（または最新の）dump を pg_restore で復元する

compose に profiles: [backup] でゲートしました。

backup:
  build: ./backup
  image: wiki-backup:local
  restart: unless-stopped
  depends_on:
    db:
      condition: service_healthy
  environment:
    POSTGRES_HOST: db
    POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?...}
    BACKUP_SCHEDULE: ${BACKUP_SCHEDULE:-0 3 * * *}    # UTC 03:00 = JST 12:00
    BACKUP_RETENTION_DAYS: ${BACKUP_RETENTION_DAYS:-14}
    R2_BUCKET: ${R2_BUCKET:-}
    R2_ENDPOINT: ${R2_ENDPOINT:-}
    R2_ACCESS_KEY_ID: ${R2_ACCESS_KEY_ID:-}
    R2_SECRET_ACCESS_KEY: ${R2_SECRET_ACCESS_KEY:-}
  volumes:
    - backups:/backups
  profiles:
    - backup

rclone の S3 設定

R2 は S3 互換なので rclone でそのまま喋れます。秘密鍵に特殊文字が混ざってもいいように、connection string ではなく 環境変数経由 で設定しています。

RCLONE_CONFIG_R2_TYPE=s3 \
RCLONE_CONFIG_R2_PROVIDER=Cloudflare \
RCLONE_CONFIG_R2_ENDPOINT="${R2_ENDPOINT}" \
RCLONE_CONFIG_R2_ACCESS_KEY_ID="${R2_ACCESS_KEY_ID}" \
RCLONE_CONFIG_R2_SECRET_ACCESS_KEY="${R2_SECRET_ACCESS_KEY}" \
  rclone sync /backups "r2:${R2_BUCKET}/wiki/" --s3-no-check-bucket --quiet

一番大事なのは復元試験

「バックアップが取れている」のと「実際にそこから復旧できる」は別物です。Issue #10 の完了条件には 「実地で復元できることを確認」 を明示しました。手順は次のとおりです。

1. Wiki.js に “Restore Test Marker” というテストページを作成する
2. 即時バックアップを取って dump にこのマーカーを含めさせる
3. docker compose down
4. docker volume rm wiki_db-data（意図的に DB データを破壊）
5. db だけまっさらな状態で起動
6. restore.sh で最新 dump を流し込む
7. wiki を起動し、ブラウザで Restore Test Marker ページが復元されていることを確認

dump はローカル /backups と R2 の両方にあるため、復元元を失う心配はありません。実際にやってみると、5 分くらいで完全復元できました。この試験を踏まないと、本番障害のときに初めて「あれ動かない」となるので、必ずやる工程です。

---

4. ハマったところ・学び

4.1 Compose profile と :? ガードの相互作用

最初、cloudflared の TUNNEL_TOKEN を ${CLOUDFLARE_TUNNEL_TOKEN:?...} で「未設定なら起動失敗」にしていました。profiles: [tunnel] で cloudflared をデフォルト起動から外したので、フェーズ 1（ローカル疎通）で docker compose up -d をするとプロファイル外の cloudflared は起動しないはず、と思い込んでいたのです。

ところが実機で試すと：

error while interpolating services.cloudflared.environment.TUNNEL_TOKEN:
required variable CLOUDFLARE_TUNNEL_TOKEN is missing a value

Compose は 変数展開を全サービスに対して行います。profile で除外されたサービスでも :? ガードは評価されてしまうのです。compose の評価モデル的には当然なのですが、ぱっと見でハマりました。

解決策は、:? を :-（empty 許容）に変えて、profile で起動制御に一本化することでした。cloudflared は profile を指定しないと「起動しない」、profile ありで TOKEN が空なら「起動するが runtime で失敗してログに出る」という挙動になります。loud さは残しつつ、parse はパスする形に落ち着きました。

4.2 Docker ENTRYPOINT と CMD の使い分け

backup サイドカーの Dockerfile を最初こう書いていました。

ENTRYPOINT ["/sbin/tini", "--", "/entrypoint.sh"]

docker compose run --rm backup /usr/local/bin/backup.sh で on-demand バックアップを走らせたかったのですが、これだと /usr/local/bin/backup.sh が /entrypoint.sh の引数として扱われ、entrypoint はそれを無視して crond を起動して待機してしまいました。「stuck したけど待ちの状態？」となるパターンです。

解決策は、ENTRYPOINT を tini だけにして、デフォルト挙動を CMD に分離することでした。

ENTRYPOINT ["/sbin/tini", "--"]
CMD ["/entrypoint.sh"]

これで docker compose run --rm backup /usr/local/bin/backup.sh は CMD を置き換えて tini -- /usr/local/bin/backup.sh を実行 → 完走して exit するようになりました。Docker のお作法的にも正しいパターンです。

4.3 Cloudflare の auth domain の見た目と URL のズレ

フェーズ 3 で書いたとおり、Team name を <your-team> に設定しても、Access ログイン画面のカードに表示されるラベルは auto-generated の <auto-generated>.cloudflareaccess.com のままでした。これは別管理だったのです。

• Settings → Team name and domain に表示される <your-team>.cloudflareaccess.com は実際の auth URL
• Reusable components → Custom pages → Access login page → “Your organization’s name” が画面に 表示されるラベル

両方を手動で揃える必要があります。Cloudflare のドキュメントには書いてあるのですが、設定変更フローからは気づきにくい部分でした。

4.4 Wiki.js と Cloudflare Access の二段認証

Cloudflare Access で OTP を通過しても、Wiki.js は別途独自にログインを要求してきます。つまりメンバーは以下を踏むことになります。

1. メールアドレスを入力 → OTP コード受信 → 入力（Cloudflare Access）
2. メール + パスワードを入力（Wiki.js）

の二段です。シングルサインオン化するには Cloudflare Access OIDC → Wiki.js OIDC strategy の設定が必要になります。今回は招待人数が少なく、ログイン頻度も低い想定なので、二段ログインを許容して進めました。SSO 化は将来の Issue にしました。

4.5 Wiki.js v2 が PostgreSQL に全部入れる仕様

これは罠というよりも嬉しい設計判断でした。Wiki.js v2 はページ本文だけでなくアップロード画像なども DB に格納します（デフォルト storage target が DB）。これによりバックアップ戦略がシンプルになります。

これは設計を組む前に Wiki.js docs を一読しておくべきポイントでした。事前に知らなかったので、最初は「DB と uploads 両方バックアップしなきゃ」と思い込んでいたのです。

---

5. コストの実態

項目	月コスト	備考
Lifebook 電気代	≈ 100〜200 円	30W 程度、24h 稼働
Cloudflare Tunnel	0 円	Free tier
Cloudflare Access	0 円	Free tier（50 ユーザーまで）
Cloudflare R2	0 円	Free tier（10GB / 1M Class A / 10M Class B）
Cloudflare Registrar	0 円	At-cost、年 $10 程度（月割なら $1/月弱）
Tailscale	0 円	Personal Free tier（管理用、3 ユーザー枠で自分のデバイスを賄う）

継続コスト合計は電気代 + 年 $10 のみ。当初の「無料運用したい」目標は達成できました。

R2 の容量は、wiki dump が現状 32KB なので 14 日分でも 0.5MB 未満、月数 PUT 程度です。Free tier の 0.005% も使っていません。コンテンツが GB 単位になるまで実質無料圏内が続きます。

---

6. これから

試運転中（現在）

1 週間ほど自分のみで触り、以下を観察しています。

• 安定稼働の観察（cloudflared 再接続、cron による日次バックアップ）
• セッション 1 week の実体感（OTP 入力頻度）
• Wiki.js の編集体験で気になる点を Issue で起こしておく

コアメンバー招待〜全員公開

Issue 化済の手順に沿って、Cloudflare Access policy への追加 + Wiki.js ローカルユーザー作成の 2 ステップで招待していきます。

追加で検討中の改善

• SSO 化: 2 段ログインが摩擦になったら、Cloudflare Access SaaS application（OIDC）と Wiki.js OIDC strategy で 1 段に統合できます
• バックアップ失敗監視: 現状 cron 失敗時に気づけません。R2 の最終更新時刻を監視するアラート（Uptime Kuma / Healthchecks.io 連携）を入れたいところです
• multi-host 化: Lifebook が壊れたとき用に、別マシンへの fail-over。R2 dump から数分で別ホストに復元できる前提なので、今は必要性は低いです

---

7. 振り返って

このプロジェクトの良かった点を整理しておきます。

• 設計判断のたびに「この後に来る Issue で実際に困るか？」を考えました。先取りの抽象化はせず、必要になってからリファクタする方針を貫けました（cloudflared の profile 分離は「ローカル疎通で困ったから」発生したリファクタです）
• リストア試験を完了条件に明示しました。バックアップを取るだけで満足せず、復元できることを実機で確認するフェーズを設計段階で組み込んでいます
• 既存のサービスを組み合わせるだけで済みました。新しいことを発明していません（Cloudflare Tunnel、Wiki.js、PostgreSQL、rclone、いずれも枯れた技術）。再現性が高いと思います
• AI コーディングエージェント（Claude Code）と組み合わせて構築しました。設計判断は自分、コマンド・スクリプトの整形・ドキュメント化は AI に任せる、というワークフローが効きました

---

8. 参考資料

• Cloudflare Tunnel docs
• Cloudflare Access docs
• Cloudflare R2 docs
• Wiki.js docs
• rclone S3 backend (Cloudflare R2)

---

付録: 主要なファイルの最終形

services/wiki/docker-compose.yml（抜粋）

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U wikijs -d wiki"]
      interval: 10s
      timeout: 5s
      retries: 5

  wiki:
    image: ghcr.io/requarks/wiki:2
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_USER: wikijs
      DB_PASS: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}
      DB_NAME: wiki
    expose: ["3000"]

  cloudflared:
    image: cloudflare/cloudflared:latest
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      TUNNEL_TOKEN: ${CLOUDFLARE_TUNNEL_TOKEN:-}
    depends_on: [wiki]
    profiles: [tunnel]

  backup:
    build: ./backup
    image: wiki-backup:local
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: wiki
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?...}
      BACKUP_SCHEDULE: ${BACKUP_SCHEDULE:-0 3 * * *}
      BACKUP_RETENTION_DAYS: ${BACKUP_RETENTION_DAYS:-14}
      R2_BUCKET: ${R2_BUCKET:-}
      R2_ENDPOINT: ${R2_ENDPOINT:-}
      R2_ACCESS_KEY_ID: ${R2_ACCESS_KEY_ID:-}
      R2_SECRET_ACCESS_KEY: ${R2_SECRET_ACCESS_KEY:-}
    volumes:
      - backups:/backups
    profiles: [backup]

volumes:
  db-data:
  backups:

services/wiki/backup/backup.sh

#!/bin/sh
set -eu

TS=$(date -u +%Y%m%dT%H%M%SZ)
DUMP_FILE="/backups/wiki-${TS}.sql.gz"
RETAIN="${BACKUP_RETENTION_DAYS:-14}"

mkdir -p /backups

echo "==> [${TS}] backup started"

PGPASSWORD="${POSTGRES_PASSWORD}" pg_dump \
  -h "${POSTGRES_HOST:-db}" \
  -U "${POSTGRES_USER:-wikijs}" \
  -d "${POSTGRES_DB:-wiki}" \
  -Fc \
  | gzip > "${DUMP_FILE}"

echo "==> dump complete ($(du -h "${DUMP_FILE}" | cut -f1)): ${DUMP_FILE}"

# Rotate
ls -1t /backups/wiki-*.sql.gz 2>/dev/null \
  | tail -n +"$((RETAIN+1))" \
  | xargs -r rm -f

# Off-site
if [ -n "${R2_BUCKET:-}" ]; then
  RCLONE_CONFIG_R2_TYPE=s3 \
  RCLONE_CONFIG_R2_PROVIDER=Cloudflare \
  RCLONE_CONFIG_R2_ENDPOINT="${R2_ENDPOINT}" \
  RCLONE_CONFIG_R2_ACCESS_KEY_ID="${R2_ACCESS_KEY_ID}" \
  RCLONE_CONFIG_R2_SECRET_ACCESS_KEY="${R2_SECRET_ACCESS_KEY}" \
    rclone sync /backups "r2:${R2_BUCKET}/wiki/" --s3-no-check-bucket --quiet
  echo "==> R2 sync complete"
fi

echo "==> [${TS}] backup finished"

services/wiki/backup/restore.sh

#!/bin/sh
set -eu

DUMP="${1:-}"
if [ -z "$DUMP" ]; then
  DUMP=$(ls -1t /backups/wiki-*.sql.gz 2>/dev/null | head -1)
fi

gunzip -c "${DUMP}" | PGPASSWORD="${POSTGRES_PASSWORD}" pg_restore \
  --clean --if-exists --no-owner --no-privileges \
  -h "${POSTGRES_HOST:-db}" \
  -U "${POSTGRES_USER:-wikijs}" \
  -d "${POSTGRES_DB:-wiki}"

以上、長い記事になってしまいましたが、誰かが似たような自宅 Wiki 構築をするときの参考になれば幸いです。

---