Dockyard

Portainer アプリテンプレート 600 種類以上（v3 形式）と、テンプレートを探すための閲覧可能な静的ウェブサイト「Dockyard」のセットです。

すべては、apps/ 内のアプリごとに 1 つある YAML ファイルを唯一の信頼できる情報源として、小さな Python CLI で生成されます。この CLI は、次の 2 つを生成します。

1. templates.json — その raw URL を Portainer の Settings → App Templates → URL に貼り付けると、カタログ内のすべてのアプリをワンクリックでデプロイできます。
2. docs/ — Dockyard のウェブサイトです。ロゴ、説明、カテゴリ、リンクを備えたカードを検索・絞り込みできます。

Portainer でフィードを使用する

1. Portainer を開き、Settings → App Templates に移動します。
2. この URL を URL フィールドに貼り付けます。

   https://cdn.jsdelivr.net/gh/bauerpawel/DOCKYARD@main/templates.json
   

3. 保存します。
4. サイドバー（環境の下）の App Templates を開くと、以下のすべてのアプリをワンクリックでデプロイできます。

v3 アプリテンプレートに対応した Portainer バージョンが必要です。

Open WebUI、Ollama、Backrest、Pocket ID、BentoPDF、Pangolin、Appwrite、RustFS を使用した Plane、Hoarder から Karakeep への移行については、ローカルアプリのセットアップをご覧ください。これらのテンプレートではイメージが固定されています。スタックを開始する前に、必要なシークレットとデプロイ設定を指定してください。

フィードは raw.githubusercontent.com から直接ではなく、jsDelivr の CDN を通じて配信されます。これにより、世界中でより高速かつ安定して読み込めます。スケジュールされたワークフロー（以下）は、再構築のたびに jsDelivr のキャッシュを消去するため、main に変更が反映されてから数秒以内に、Portainer には常に最新の templates.json が表示されます。

ウェブサイト

https://dockyard.kim1.ovh で同じカタログを閲覧できます。名前で検索したり、カテゴリで絞り込んだり、アプリ名、ロゴ、説明をクリックして詳細な説明を展開したりできます。各カードからアプリの Docker Hub ページ、および（判明している場合は）そのアプリ独自のソースやホームページに移動できます。

インターフェースは英語、ポーランド語、ドイツ語、フランス語に対応しています。ブラウザーの言語が適用され、ヘッダーの切り替えボタンで言語を変更できます。また、?lang=pl（または de、fr）を指定すると、その言語のページに直接アクセスできます。文字列は site_src/i18n.json にあり、アプリの説明は英語のままです。ビルド時には、site_src/CNAME に記載されたドメイン向けに、robots.txt、sitemap.xml、検索エンジン向けメタデータ（canonical URL、hreflang の代替ページ、Open Graph カード、JSON-LD）も生成されます。

AI エージェント向け MCP サーバー

カタログは、MCP サーバーを通じて AI エージェントからも利用できます。

https://dockyard.kim1.ovh/mcp

これを使うと、Claude、Codex、Grok、Gemini CLI、Cursor、VS Code などの MCP クライアントから、アプリを検索（list_apps）したり、アプリの詳細を確認（get_app）したり、デプロイ計画を作成（prepare_deploy）したりできます。サーバーはアプリの情報を提供して計画を作成するだけです。Docker や Portainer にはアクセスできず、エージェントがデプロイするのは、確認後にお使いのマシン上でのみです。

Claude Code に追加するには、次のようにします。

claude mcp add --scope user --transport http dockyard https://dockyard.kim1.ovh/mcp

その他のクライアントでは、ブラウザーでアドレスを開いてください。英語、ポーランド語、ドイツ語、フランス語のセットアップ手順が表示されます。

クイックスタート

Python 3.14 以降が必要です。

apps/ と stacks/ からすべてを最も手軽に（再）ビルドできます。必要に応じて .venv をセットアップし、templates.json と docs/ をビルドして、結果を検証します。Docker Hub には接続しません（下記のメタデータを最新に保つを参照してください）。

run.bat                 # Windows
./run.sh                # Linux / macOS

追加の引数は gallery build に渡されます。例：run.bat --repo-url https://github.com/bauerpawel/DOCKYARD。

デフォルトの URL は repository.json から取得されます。フォークした場合は、このファイルを更新するか、--repo-url を使用してください。 ビルドが成功すると、指定した値がそこに保存されるため、フィード、ウェブサイト、MCP でリポジトリの識別情報が一致します。 OWNER/REPO のプレースホルダーを含む URL は拒否されます。

手動で手順を制御する場合：

python -m venv .venv
.venv/Scripts/activate        # or: source .venv/bin/activate on Linux/macOS
pip install -e ".[dev]"

python -m gallery fetch-metadata   # refresh Docker Hub descriptions (cache/dockerhub.json)
python -m gallery build            # -> templates.json + docs/
python -m gallery validate         # check templates.json against Portainer's v3 schema
pytest                             # run the test suite

docs/index.html をブラウザーで直接開くと、サイトをローカルでプレビューできます。

ホスティングのメタデータも site_src/ から取得されます。カスタムドメインを設定する場合は site_src/CNAME を編集し、 デフォルトの Pages ドメインを使用する場合は削除してください。オプションの site_src/.nojekyll もコピーされます。 site_src/MCP_URL には、サイトがフィード URL の下に掲載する MCP サーバーのアドレスが格納されています。 独自のサーバーに変更するか、ファイルを削除すると、この注記は表示されません。

公開前に、ビルドではアプリの YAML を schema/app_schema.json に照らして検証し、生成されたフィードを Portainer の スキーマに照らして検証します。レンダリングとアセットのコピーは一時ディレクトリ内で行われます。公開に失敗すると、 以前のフィード、サイト、リポジトリ設定が復元されます。ロールバックに失敗した場合は、バックアップディレクトリが保持され、 そのパスが報告されます。

統合テストスイート全体では、PHP 8.2 以降、Node.js 18 以降、Docker Compose CLI も使用します。Compose のテストでは config のみを実行するため、Docker デーモンや実行中のコンテナーは必要ありません。

セキュリティチェック

pip install -e ".[dev,audit]" で監査ツールをインストールします。仮想環境を有効化した状態で、次を実行します。

python -m pip freeze --exclude-editable > .venv/audit-requirements.txt
python -m pip_audit -r .venv/audit-requirements.txt --no-deps --disable-pip --strict --progress-spinner off

スナップショットには、インストール済みの推移的依存関係と開発用依存関係が含まれています。CI では、ハッシュと新しいリリースに対する7日間のクールダウンを設定した requirements/build.txt と requirements/dev.txt から Python パッケージをインストールします。pyproject.toml の依存関係を変更した後は、各ファイルのヘッダーに記載されている uv pip compile コマンドを再実行してください。このコマンドは既存の固定バージョンを維持するため、監査での指摘を解消する場合など、固定バージョンを引き上げるには --upgrade（または --upgrade-package <name>）を追加します。CI のチェックでは、プッシュ、プルリクエスト、および毎週月曜日に、テスト、ビルド／検証、依存関係の監査を実行します。Dependabot は Python パッケージ、Composer 依存関係、およびバージョンを固定した GitHub Actions を毎週チェックします。監査の対象範囲と指摘事項については、SECURITY_AUDIT.md を参照してください。

MCP YAML パーサーは、ライセンスおよび mcp/composer.lock とともに mcp/vendor/ に同梱されています。PHP の依存関係をチェックするには、composer audit --working-dir=mcp --locked --no-dev を実行します。依存関係を更新するには、composer update --working-dir=mcp --no-dev を実行し、ロックファイルと mcp/vendor/ を一緒にコミットしてください。Dependabot の Composer PR はロックファイルのみを変更するため、マージする前にそのブランチでこのコマンドを実行してください。deploy/refresh.php は mcp/vendor/ がロックファイルと一致しないリリースを拒否し、更新テストも失敗します。

MCP プランはユーザーのマシンで実行されるため、サーバーは検証可能なものだけを提供します。他のリポジトリにある Stackfile は、stacks.lock.json に記録されたコミットと SHA-256 で固定された状態で提供されます。上流の変更がプランに反映されるのは、レビューと python -m gallery pin-stacks --update の実行後のみです。Compose は許可リストに照らしてチェックされます。データディレクトリ外のホストパス、build、external リソース、不明なキー、プランで設定されていない変数を使用するには、allow_privileged が必要です。また、PORTAINER_* を置き換えるスタックは常にブロックされます。

stacks/ 内のローカルスタックでは、Portainer のアプリ環境フィールドまたはローカルの .env ファイルで、空ではないパスワードを指定する必要があります。MCP プランでは local_secrets を使用し、ローカルで CHANGEME を置き換えてください。再デプロイ時は、既存のボリュームで使用しているデータベースパスワードを維持してください。.env の値を変更するだけでは、データベースの認証情報は更新されません。n8n では、削除済みの N8N_BASIC_AUTH_* 設定ではなく、Web UI でオーナーアカウントを設定します。

メタデータを最新の状態に保つ

gallery fetch-metadata は Docker Hub と通信する唯一のコマンドです。通常の再ビルドで Docker Hub の匿名レート制限に達するリスクが生じないよう、意図的に run.bat／run.sh のデフォルトフローから除外されています。gallery build は常に、キャッシュ済みの cache/dockerhub.json を読み込みます。

2つの GitHub Actions ワークフローが、どちらの実行頻度も自動的に処理します（.github/workflows/ を参照）。

• build.yml — main へのプッシュごとに実行されます（新しいアプリテンプレートが追加されるとすぐに反映されます。また、apps/／stacks/ を経由しない変更であっても、templates.json が直接変更された場合は jsDelivr のキャッシュがパージされます）。安全策として、毎週土曜日にも実行されます。templates.json と docs/ を再ビルドし、変更があればコミットして、templates.json と stacks.lock.json の jsDelivr キャッシュをパージします。Actions タブから手動で実行することもできます。
• refresh-dockerhub.yml — 毎月1日（「30日ごと」に最も近いカレンダークロン相当）に実行され、cache/dockerhub.json を更新し、再ビルドしてコミットします。

どちらも読み取り専用トークンと、ハッシュで固定された requirements/build.txt 内のパッケージを使ってビルドします。別のジョブ（publish-generated.yml）は Python パッケージを一切実行せず、生成されたファイルのみをコミットします。main では test (3.14) と audit のチェックが必須のため、このジョブはコミットを一時的な publish/* ブランチにプッシュしてそこでテストを実行し、合格したジョブをコミットステータスとして記録した後にのみ、main をそのコミットに移動します。

ローカルで随時更新する場合は、python -m gallery fetch-metadata を実行してください。

新しいアプリの追加

詳しいガイド（フィールドのリファレンス、カテゴリ一覧、信頼できるロゴ／ウェブサイト／画像の入手方法）については、CONTRIBUTING.mdをご覧ください。概要は次のとおりです。

python -m gallery new my-app --type container   # or --type compose

これにより、apps/my-app.yamlが作成されます。フィールドを入力してください。

name: My App
slug: my-app
category: Utilities
type: container                    # container | compose
image: namespace/my-app:latest     # required - must be a real Docker Hub image
compose: null                      # required for type=compose instead, e.g. stacks/my-app/docker-compose.yml
description: null                  # null = auto-fetch from Docker Hub; or write your own text
note: null                         # optional - Portainer deployment instructions; HTML supported
logo: https://.../my-app.png       # required
website: https://github.com/...    # optional - the app's own site or source repo
network: null                      # optional, container only - Docker network to attach to, e.g. host
command: null                      # optional, container only - override the container's command
privileged: null                   # optional, container only - true to run in privileged mode
restart_policy: null               # optional, container only - always | unless-stopped | on-failure | "no"
ports: ["8080/tcp"]
volumes: []
env: []

type: composeの場合は、次のいずれかを選択してください。

• このリポジトリにstacks/my-app/docker-compose.ymlを追加し、compose: stacks/my-app/docker-compose.ymlで参照します（既存のstacks/*フォルダーをご覧ください。WordPress、Nextcloud、Gitea、Grafana+Prometheus、n8n、Ghostは、いずれもメインアプリとそのデータベースを組み合わせています）。または
• compose:の代わりにrepository: {url: https://github.com/..., stackfile: path/to/docker-compose.yml}を指定して、別の場所にすでに存在するスタックファイルを参照します。

Compose アプリでimageが必要なのは、Docker Hub のメタデータ検索も必要な場合（つまり、手動のdescriptionが設定されていない場合）だけです。コンテナーアプリには、常にimageが必要です。

次に、python -m gallery fetch-metadata && python -m gallery build && python -m gallery validateを実行して、生成されたtemplates.jsonとdocs/を含む結果をコミットしてください。あるいは、そのままプッシュしてもかまいません。build.ymlワークフローが再ビルドします。ただし、新しいイメージの Docker Hub メタデータは、次回の月次更新まで取得されません。すぐに表示したい場合は、手動でdescriptionを設定してください。

すべてのアプリには、最低限、logoと解決可能なdescription（手動設定または取得したもの）が必要です。どちらかがない場合、buildはエントリーの生成を拒否します。

バグの報告と修正の提案

テンプレートの破損、誤っている／古いwebsiteまたはlogoのリンク、説明の誤りなど、問題を見つけた場合は、issueを作成してください。見つけやすいように、アプリのスラッグ（apps/内のYAMLファイル名）を記載してください。

自分で修正しますか？

1. リポジトリをフォークし、該当するファイルを編集します。単一のアプリの場合は通常apps/<slug>.yaml、サイトやツールの場合はsite_src/／src/gallery/です。
2. run.bat／./run.shとpytestを実行し、引き続きビルド、検証、テストがすべて成功することを確認します。
3. プルリクエストを作成します。

プロジェクト構成

apps/*.yaml                 # one file per app - the source of truth
stacks/<slug>/*.yml         # docker-compose files for type=compose apps
schema/templates_schema.json # vendored Portainer v3 JSON Schema, used by `validate`
src/gallery/                # the Python package (models, loader, Docker Hub client, builders, CLI)
site_src/                   # Jinja2 template, translations (i18n.json) + CSS/JS for the website
mcp/                        # PHP MCP server; guide/ holds the setup instructions it shows in a browser
docs/                       # generated website, served by GitHub Pages
cache/dockerhub.json        # cached Docker Hub metadata, refreshed by `fetch-metadata`
templates.json              # generated - the file Portainer actually fetches
tests/                      # pytest suite
requirements/               # hash-pinned CI dependencies, generated by `uv pip compile`
.github/workflows/          # scheduled rebuild + Docker Hub refresh (see above)

初回デプロイの設定

サイト（docs/）は、このリポジトリから直接GitHub Pagesで配信されるため、別途ホスティングする必要はありません。このリポジトリをhttps://github.com/bauerpawel/DOCKYARDにプッシュしたら、次の手順を行います。

1. リポジトリのSettings → Pagesで、ソースをブランチmain、フォルダー/docsに設定します。サイトはhttps://dockyard.kim1.ovhで公開され、スケジュールされたワークフローによるコミットも含め、mainのdocs/が変更されるたびに自動更新されます。
2. これで完了です。上記のフィード URL とウェブサイト URL は、すでにこのリポジトリを参照しています。

Apache／MCP ホスティングでは、vendor/とguide/を含むmcp/ディレクトリ全体をコピーしてください。mcp/INSTRUKCJA.mdをご覧ください。サーバーはjsDelivr CDNからフィードを読み込み、15分間キャッシュします。そのため、同じ場所にあるtemplates.jsonはフォールバックとしてのみ使用されます。repository.jsonとstacks/を使用すると、ローカルのComposeファイルを利用できます。サーバーのアドレスをブラウザーで開くと、英語、ポーランド語、ドイツ語、フランス語のいずれかで、Claude、Codex、Grok、Gemini CLI、Cursor、VS Codeへの追加方法が表示されます（mcp/guide/）。オプションのdeploy/refresh.phpアップデーターは、GitHub Actionsでtestジョブが成功した場合にのみコミットをインストールし、その後リリースを検証して、置き換え前にすべての成果物をステージングします。公開エラーが発生した場合は、以前のファイルにロールバックします。Apacheの設定とMCPのキャッシュはそのまま維持されます。ロールバック自体に失敗した場合は、バックアップのパスが報告されます。

ライセンス

MIT — LICENSEをご覧ください。

上流のプロジェクトを基にしたスタック設定には、元のライセンスが適用されます。 AppwriteのBSD-3-Clauseライセンス表示はstacks/appwrite/LICENSE.upstreamに、PlaneのAGPL-3.0ライセンスはstacks/plane/LICENSE.upstreamにあります。