ProxmoxVE

スマホの写真は家のサーバーへ：脱 Google フォトに向けた Immich × Cloudflare Tunnel ! この記事は大体Claudeに書いてもらいました。 スマホの写真は Google フォトにバックアップしていたが、無料版の容量が足りなくなったので、Google One の 100GB のプランを契約した。ただ、今後のデータの取り扱いにも不安があった。そこで Google フォトから離れるつもりで、Google One の契約と並行して、自宅の Proxmox VE で写真管理の Immich を動かし、スマホの写真をそちらにもバックアップするようにした。Google フォトへのバックアップはまだやめておらず、Google フォトにある写真も Immich には移していない。 外からは Cloudflare Tunnel と Cloudflare Access を通して Immich を使っている。その構成は前の記事に書いた。この記事では Immich 側の話として、スマホアプリを Access に通す方法、アップロードサイズの上限、写真の置き場とコピーの持ち方を書く。ドメインやトークン、LAN の IP などは、スクリーンショットも含めて例に置き換えてある。 構成 スマホアプリ（Immich） │ ├─ 外出先：photos.example.com │ Cloudflare エッジ（Access：サービストークンで通す） │ → Tunnel → cloudflared → immich.local │ └─ 家の Wi-Fi：http://192.168.1.10:2283（LAN に直接） ▼ Proxmox VE Immich の LXC rootfs NVMe 上の 20GB /mnt/immich-media HDD 上の 40GB の raw イメージ（mp0） Immich は community-scripts/ProxmoxVE のスクリプトで作った LXC で動いている。Docker は使っておらず、systemd のサービスとして動く。 スマホアプリは、外出先では Tunnel 経由の photos.example.com に、家の Wi-Fi につながっているときは LAN の 192.168.1.10 に直接つなぐ。 スマホアプリをサービストークンで Access に通す photos.example.com は Access の後ろにあるので、ログインしていないリクエストは Access のログイン画面にリダイレクトされる。スマホアプリはこの画面を開けないので、サービストークンを使う。前の記事でも触れたとおり、サービストークンの Client ID と Client Secret をヘッダーに付けたリクエストは、ログインなしで Access を通る。 画面は 2026 年 10 月時点の Cloudflare ダッシュボードと Immich のスマホアプリのもの。スマホアプリの画面は Android エミュレータで撮り、ヘッダーの値はダミーにしてある。 サービストークンを発行する Zero Trust > Access controls > Service credentials の Service Tokens タブで、Create Service Token を押す。 Service token name に名前を入れ、Service token duration で有効期限を選んで Generate token を押す。 作ると Client ID と Client Secret が表示される。Client Secret が表示されるのはこのときだけなので、ここで控えておく。ヘッダーの形でも出るので、そのまま使える。 CF-Access-Client-Id: <CLIENT_ID> CF-Access-Client-Secret: <CLIENT_SECRET> 手順は Create a service token にある。 Access のアプリに Service Auth のポリシーを付ける 前の記事で作った Immich の Access アプリに、このサービストークンを通すポリシーを付ける。ポリシーの Action は Service Auth にして、Include の Service Token に作ったトークンを選ぶ。Action を Allow にすると、サービストークンを持っていても IdP のログインを求められる。 うちの Immich のアプリにはこのポリシー（Immich - Service Token）と、自分のメールアドレスを通す Allow のポリシーの 2 つが付いている。手順は Connect your service to Access にある。 スマホアプリにヘッダーを設定する Immich のスマホアプリには、リクエストに任意のヘッダーを付ける機能がある。ログイン前の最初の画面にも Settings があるので、そこから Advanced を開くと Custom proxy headers [EXPERIMENTAL] がある。 右上の + でヘッダーを足し、CF-Access-Client-Id と CF-Access-Client-Secret の 2 つに、サービストークンの値を入れる。 ヘッダーを入れてから、最初の画面の Server Endpoint URL に photos.example.com を入れてログインする。 100MB の上限と LAN からのアップロード Cloudflare を通るリクエストには、プランごとにボディのサイズの上限がある。Free プランでは 100MB で、超えると 413 が返る。Tunnel の公開ホスト名へのリクエストも Cloudflare のエッジを通る。うちでも、Tunnel 経由で 100MB を超えるファイルを上げようとして失敗したことがある。 この上限を避けるため、家の Wi-Fi では LAN に直接つなぎ、大きいファイルも上がるようにしている。スマホアプリの Settings > Networking にある Automatic URL switching をオンにすると、指定した Wi-Fi につながっているときだけ LAN の URL を使い、それ以外では外部の URL を使うように切り替わる。 Local network に家の Wi-Fi の名前と 192.168.1.10 を、External network に photos.example.com を入れている。この設定で、家の Wi-Fi から 215MB の動画がバックアップできた。外出先で撮った 100MB を超える動画は、Cloudflare 経由ではアップロードに失敗し続けるが、家の Wi-Fi につながると LAN の URL に切り替わってバックアップされる。 Android では Wi-Fi の名前を読むために、アプリに正確な位置情報の権限が要る。アプリがバックグラウンドで動いているときにも切り替えるなら、位置情報を「常に許可」にする必要がある。 192.168.1.10 は LAN の IP をそのまま書いている。前の記事のオリジンの名前解決で書いたとおり、各サーバーの IP は DHCP で配っていて固定していないので、アドレスが変わるとこの設定も直す必要がある。 写真の置き場 LXC の rootfs は NVMe 上の 20GB で、写真は別の場所に置いている。HDD 側のストレージに 40GB の raw イメージを作り、mp0 で LXC の /mnt/immich-media にマウントしている。 /etc/pve/lxc/<CTID>.conf（抜粋） mp0: hdd:<CTID>/vm-<CTID>-disk-0.raw,mp=/mnt/immich-media,size=40G rootfs: local-lvm:vm-<CTID>-disk-0,size=20G Immich の写真の保存先は .env の IMMICH_MEDIA_LOCATION で指定する。 /opt/immich/.env（抜粋） IMMICH_MEDIA_LOCATION=/mnt/immich-media 写真のコピーはどこにあるか 新しく撮った写真は、スマホに残したまま、Immich と Google フォトの両方にバックアップしている。 コピー 媒体 場所 スマホ本体 スマホのストレージ 手元 Immich HDD 上の raw イメージ 家 Google フォト クラウド（Google One の 100GB） 家の外 コピーを 3 つ持ち、2 種類以上の媒体に分け、1 つは別の場所に置くという「3-2-1 ルール」に当てはまっている。冒頭に書いた Google One の契約があるので、家の外のコピーは Google フォトが担う形になった。3-2-1 に当てはまっているのは結果としてそうなっただけで、Google フォトをやめたあとのバックアップをどういう形にするかは、まだ決めていない。 Google フォトに前からある写真は、まだ Immich に移していない。一度 immich-go で取り込もうとしたが、エラーで失敗した。このエラーは immich-go 側で修正されたが、修正を含む版はまだリリースされていないので、リリースされたら取り込む予定。

ポート開放なしで自宅サーバーを公開する：Cloudflare Tunnel + Access の構成 ! この記事は大体Claudeに書いてもらいました。 自宅サーバーで動かしている写真管理の Immich と位置情報ログの Dawarich を、Cloudflare Tunnel と Cloudflare Access で外から使えるようにしている。その構成と、なぜこの組み合わせにしたか、ダッシュボードでの設定手順を書いておく。 Immich と Dawarich そのものの設定は、それぞれ別の記事に書く予定。ドメインやトークン、メールアドレスなどは、スクリーンショットも含めて例に置き換えてある。 構成 ブラウザ / スマホアプリ │ HTTPS ▼ Cloudflare エッジ ├─ Access：Google でログインした自分のアカウントか、 │ サービストークンを持ったスマホアプリだけ通す │ │ Tunnel（cloudflared から外向きに張った接続） ▼ 自宅ルーター（ポート開放なし） │ LAN ▼ Proxmox VE（サービスごとに LXC を分けている） cloudflared ──HTTP──▶ Immich (immich.local:2283) ──HTTP──▶ Dawarich (dawarich.local:3000) 家の LAN の中で cloudflared を動かしていて、こいつが Cloudflare に向けて外向きの接続を張っている。外からのリクエストはその接続を通って cloudflared に届き、LAN 内のアプリに流れる。Cloudflare 側では Tunnel の手前に Access を置いて、ログインしていないリクエストを止めている。 外から見えるのは Cloudflare だけで、家のルーターは外からの接続を受けていない。 サーバーは Proxmox VE で、cloudflared、Immich、Dawarich はそれぞれ別の LXC として動かしている。どれも community-scripts/ProxmoxVE のスクリプトで作った。 技術選定 Cloudflare Tunnel を選んだ理由 一番は家のグローバル IP とポートを外に見せたくなかったこと。ポートを開けて公開すると家の IP が DNS に載り、開けたポートには世界中からスキャンが来る。Tunnel なら cloudflared が外向きの接続だけを張るので、ルーターで受けるポートがいらない。DNS に載るのも家の IP ではなくトンネルを指す CNAME になる。 証明書と DDNS の面倒を見たくなかった、というのもある。TLS の証明書は Cloudflare のエッジが持つので、Let's Encrypt の更新を自分で回さなくていい。家の IP が変わっても cloudflared がつなぎ直すだけなので、DDNS もいらない。 あとは同じ Cloudflare の中で Tunnel の手前に Access を挟めること。 引き換えにしているのは、Cloudflare から通信の中身が見えること。TLS はブラウザと Cloudflare の間、Cloudflare とオリジンの間で別々の接続になり、通信はエッジで一度復号される。 Access を手前に置く理由 Immich にも Dawarich にもログイン機能はある。でも、アプリの認証だけで公開していると、アプリに脆弱性が見つかったときに、世界中の誰でもログイン画面までは来られてしまう。 Access にセルフホストアプリケーションとして登録すると、Cloudflare のエッジでログインを求めるようになり、通らないリクエストはアプリまで届かない。API のパスも Access の後ろにあるので、ログインせずに API を叩いても、Access のログイン画面にリダイレクトされる。 $ curl -sI photos.example.com HTTP/2 302 location: https://<TEAM_NAME>.cloudflareaccess.com/cdn-cgi/access/login/photos.example.com?... ただ、これだとスマホアプリが API を呼べない。アプリは Access のログイン画面を開けないので、スマホアプリだけはサービストークンで通している。サービストークンの Client ID と Client Secret をヘッダーに付けたリクエストは、ログインなしで Access を通る。 トンネルの管理方式 トンネルの管理にはダッシュボードで設定するリモート管理と、config.yml を書くローカル管理がある。うちはリモート管理だが、比べて選んだわけではない。cloudflared の LXC を作った community-scripts のスクリプトがこの形で入れたので、そのまま使っている。 リモート管理だと、cloudflared はトークンを渡して起動するだけで、どのホスト名をどこに流すかはダッシュボードから送られてくる。 設定手順 画面は 2026 年 10 月時点の Cloudflare ダッシュボードのもの。Cloudflare の画面はよく変わるので、ずれていたら各手順のドキュメントを見てほしい。 手順は、トンネルを作る、Google でログインできるようにする、Access のアプリとポリシーを作る、公開ホスト名を登録する、の順にしている。公開ホスト名を先に登録すると、Access のアプリを作るまでのあいだ、アプリが認証なしで外に出てしまうので、Access を先に用意しておく。 トンネルを作る Cloudflare ダッシュボードの Networking > Tunnels を開く。うちのトンネルは pve という名前で、1 本だけある。 新しく作るときは Create Tunnel を押し、Tunnel name に名前を入れて Create Tunnel を押す。ここから先の画面は記事のために demo という仮のトンネルを作って撮った（撮ったあとで消した）。 作るとトンネル ID が振られ、cloudflared のインストール手順が出る。Operating System で cloudflared を動かすホストの OS を選ぶと、そのまま貼り付けられるコマンドが表示される。Debian なら、Install cloudflared のコマンドで cloudflared を入れ、Install as service の sudo cloudflared service install <TUNNEL_TOKEN> を実行すると、トークン付きの systemd サービスとして登録される。 うちの cloudflared のホストでは、systemd のユニットはこうなっている。 /etc/systemd/system/cloudflared.service（抜粋） [Service] ExecStart=/usr/bin/cloudflared --no-autoupdate tunnel run --token <TUNNEL_TOKEN> Restart=on-failure 画面の Security Notice にもあるとおり、このトークンがあれば誰でもこのトンネルのコネクタを起動できる。パスワードと同じように扱い、漏れたら作り直す。 cloudflared がつながると、Connection Status に接続が出て、Continue で先に進める。手順は Create a tunnel (dashboard) にある。 Google でログインできるようにする 先に Google Cloud Console で OAuth クライアントを作る。種類は Web application で、Authorized JavaScript origins に https://<TEAM_NAME>.cloudflareaccess.com、Authorized redirect URIs に https://<TEAM_NAME>.cloudflareaccess.com/cdn-cgi/access/callback を入れる。<TEAM_NAME> は Zero Trust のチーム名。 次に Cloudflare 側で Zero Trust > Integrations > Identity providers を開き、Add an identity provider から Google を選ぶ。 Client ID と Client secret に、Google Cloud Console で作った OAuth クライアントの値を入れて保存する。Callback URL に出ている URL が、さっきリダイレクト URI に入れたものと同じになっていればいい。 One-time PIN は最初から入っている IdP で、Access のアプリでは使っていない。手順は Google（Cloudflare One のドキュメント） にある。 Access のアプリとポリシーを作る Zero Trust > Access controls > Applications で、公開するホスト名ごとにアプリを作っている。Create new application から Self-hosted を選ぶ。 Destinations の Public hostnames に、これから公開するホスト名を入れる。 Access policies には 2 つのポリシーを付けている。1 つ目がスマホアプリ用のサービストークンを通す Service Auth のポリシー、2 つ目が自分のメールアドレスを通す Allow のポリシー。画面の説明にあるとおり、Service Auth のポリシーは Allow より先に評価される。スマホアプリに入れたサービストークンが漏れると、ログインなしで Access を通れてしまうので、これもトンネルのトークンと同じく鍵として扱う。サービストークンの発行と、スマホアプリ側でヘッダーを設定する方法は、Immich と Dawarich それぞれの記事で書く。 Authentication では Accept all available identity providers をオフにして、Google だけを選んでいる。Apply instant authentication をオンにしておくと、IdP を選ぶ画面を飛ばして、すぐ Google のログインに進む。 Allow のポリシーは Zero Trust > Access controls > Policies で作り、Immich と Dawarich の両方で使い回している。中身は Include の Emails に自分のメールアドレスを 1 つ入れただけ。 手順は Publish a self-hosted application to the Internet と Policy management にある。 公開ホスト名を登録する Access の準備ができたら、トンネルに公開ホスト名を登録する。トンネルを開いて Routes タブを見ると、登録したルートが並んでいる。新しく足すときは Add route > Published application を選ぶ。 Subdomain と Domain で公開するホスト名を決め、Service URL に LAN の中のアプリの URL を書く。Immich なら immich.local にしている。 登録すると、トンネルを指す CNAME が DNS に自動で作られるので、DNS レコードを自分で足す必要はない。 オリジンの名前解決 ! ここは課題が残っていて、直す予定のところ。参考にするときは下の問題点もあわせて見てほしい。 Service URL には IP ではなく immich.local のようなホスト名を書いている。最初はこの名前をルーターの DNS で引こうとして、cloudflared が no such host のエラーを出していた。今は cloudflared が動いているホストの /etc/hosts に手で書いて引けるようにしている。 /etc/hosts（cloudflared のホスト、抜粋） 192.168.1.10 immich.local 192.168.1.11 dawarich.local これで動いてはいるが、問題が 3 つある。 .local は mDNS 用に予約された名前で、ふつうの DNS で使う名前ではない。ルーターの DNS で引けなかったのも、それはそう 各サーバーの IP は DHCP で配っていて、固定していない。アドレスが変わっても hosts は古いままなので、そのアプリは外から開けなくなる 名前とアドレスの対応が、cloudflared のホストの hosts にしかない。LAN の中のほかのマシンからは同じ名前で引けない DHCP の固定割り当てにして、LAN の中の DNS で名前を引けるように直す予定でいる。なお、家庭内ネットワーク向けの名前には home.arpa が用意されている。 次の記事 アプリごとの話はそれぞれ別の記事に書く。 Immich：写真を自宅に持ち、スマホから外出先でもバックアップするまで Dawarich：位置情報を自宅に貯めるまで どちらもサービストークンでスマホアプリを Access に通す方法を含む。

Proxmox VE Helper-Scripts: One-command installations for services, containers and VMs on Proxmox VE (30k stars) What it does All text below is quoted directly from the project README. >Proxmox VE Helper-Scripts (Community Edition) What is this?: - The canonical application scripts. More than 700 of them, covering home automation, media, networking, databases, monitoring, security and developer tooling. - Paste one command into your Proxmox shell and the container or VM is built, configured and running. - The same scripts run unchanged on an Incus host through the Incus repository. - Default picks sensible resources and asks only what it has to. Most installs finish in a few minutes. - Advanced hands you container settings, networking, storage backend and application options before anything is created. - Every container gets an update command. >Copy the one-line install command from the script page Repository community-scripts/ProxmoxVE Repository stats |Metric|Value| |:-|:-| |Stars|29,926| |Forks|2.9k| |Last release|2026-10-25 (2026-10-26)| |Languages|Shell 100%| |Contributors|581| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|@Copilot (44 commits), @claude (36 commits), @cursoragent (14 commits)| |AI co-authored commits|Claude: 39, Cursor: 17, Copilot: 42| Main contributor |Field|Value| |:-|:-| |Name|tteckster| |GitHub|@tteck| |Commits to this repo|6,634 (top contributor)| |Followers|2.1k| ────────────────────────────── 📌 How many great GitHub repos have you discovered and completely forgotten about? Don't let another useful tool disappear into your Reddit feed. Get the community's best repos, organized by category, plus key takeaways from real developer discussions, delivered to your inbox twice a week. 📬 Never lose track of great repos again. Subscribe free.