Difyを入れて最初の設定をする：Dify Cloudの始め方、セルフホスト（Docker Compose）の手順、.envの初期設定、モデルの追加、difyctlの入れ方を、公式の手順どおりに順に並べる

3行でいうと

始め方は2つです。公式がホストする Dify Cloud（cloud.dify.ai）と、自分の環境で動かす Docker Compose。公式のクイックスタートは Cloud を使って説明しています。どちらを選ぶかの比較は01を参照してください。
セルフホストの必要条件は、公式ページの表示で、CPU 2コア以上・RAM 4 GiB以上・Docker Compose 2.24.0以上です。手順は「リポジトリを取得 → docker ディレクトリで .env.example を .env にコピー → トークンを設定 → docker compose up -d → http://localhost/install で管理者を作る」の順です。
.env の DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN が空だと、公式によればエージェント用の2つのサービスが起動しません。環境変数のページは、SECRET_KEY、DIFY_AGENT_SERVER_SECRET_KEY、DIFY_AGENT_API_TOKEN を本番では置き換える値として書いています。データベースと Redis の既定パスワードは表に載っていますが、変更を促す文は、読んだ範囲では見つかりませんでした。
インターネットから届く環境にするときの制限は、環境変数のページに書かれた設定（INIT_PASSWORD、ALLOW_REGISTER、CORS など）の範囲で確かめられます。このページでは、何が外に出るかと、どの設定で絞るかを、公式の記載のとおりに並べます。
モデルは別に用意します。「Integrations」の「Model Provider」でプロバイダーを入れ、「Setup」でAPIキーを入れる（または Cloud のクレジットを使う）と、「Default Models」で既定のモデルを決められます。

この記事は、公式の資料を2026年10月25日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。

先に結論

手順は「公式の手順を順に並べたもの」です。 コマンドは、公式ページに載っていたものを写しています。公式ページは要約の形で取得したため、コマンドが崩れて読めた箇所はありませんでしたが、システムに影響する操作（スクリプトの実行、.env の編集）は、手元で公式の原文を見ながら進めてください。
Cloud は「サインアップしてモデルを入れる」だけで、最初の画面までたどり着きます。 クイックスタートの手順は、サインアップ → 「Integrations」の「Model Provider」でプロバイダーを入れる → 「Default Models」で既定を決める、の順です。
セルフホストは、コンテナが15個動く構成です。 公式は、7つの中核サービス、8つの依存サービス、1回だけ動いて終わる初期化タスクを挙げています。マシンの余裕は、この数を見て決めます。
.env は「必須の置き換え」と「必要になったら変える」に分けて読めます。 前者は公式の警告に出てくる秘密の値、後者はURL、サインイン方法、保存先などです。
外に出るものは、設定で変わります。 公式の環境変数のページは、CORS の既定を *（どの送信元でも許可）と載せています。本番で絞るよう求める文は、読んだ範囲では見つかりませんでした。公開前に、このページの「外に出るもの」の表で確かめてください。

前提：用語をそろえる

ターミナル：文字でコマンドを打つ画面です。macOS は「ターミナル」、Windows は PowerShell や WSL 2 のシェルなどが該当します。
Docker / Docker Compose：アプリを「コンテナ」という箱に入れて動かす仕組みと、複数の箱をまとめて起動する仕組みです。Dify のセルフホスト手順は、Docker Compose を使います。
.env（環境変数のファイル）：設定値を書くテキストファイルです。Dify では docker/.env が主な設定ファイルで、docker/.env.example がひな形です。
ワークスペース（Workspace）：Dify でアプリやナレッジを作る作業場です（01を参照）。
モデルプロバイダー（Model Provider）：Dify がつなぐ、AIモデルの接続先です。OpenAI などを「入れて」、APIキーを設定します。
APIキー：外のサービス（モデル提供会社など）を呼ぶための鍵の文字列です。人に見せたり、公開のリポジトリに貼ったりしないものとして扱います。
CLI / difyctl：コマンドで Dify のアプリを動かす公式のツールです。使い方は07で扱います。このページでは入れ方だけ書きます。

たとえ話：店を借りるか、自分で建てるか

Cloud は「できあがった店舗を借りる」、セルフホストは「自分の土地に店を建てる」ようなものです。後者は、鍵の管理や更新も自分の仕事になります（僕らの整理で、公式の説明ではありません）。

入口の選び方

Cloud とセルフホストの比較、プランの違い、料金、データの置き場所は01と04にあります。ここでは繰り返しません。下の「A」が Cloud、「B」「C」がセルフホスト、「G」がコマンドラインツール（difyctl）です。

A. Dify Cloud で始める

公式のクイックスタートの「Before You Start」を、順に並べます。

A-1 サインアップする

ブラウザで cloud.dify.ai を開き、無料でサインアップします（公式の表現は「sign up for free」）。
新しいアカウントは Sandbox プランで始まり、公式のクイックスタートは「200 AI credits」が付くと書いています。これは一度きりの割り当てで、毎月は戻りません。
サインインの方法や画面言語は、このページで読んだ公式ページには書かれていませんでした。01を参照してください。

A-2 モデルプロバイダーを入れる

「Integrations」→「Model Provider」を開きます。
クイックスタートは、OpenAI のプロバイダーを入れる手順を挙げています（チュートリアルのモデルは gpt-5.2）。
クレジットの対象のモデルは、自分のAPIキーなしで使える、と公式のモデルプロバイダーのページは書いています。自分のキーも使えます。どのプロバイダーがクレジットの対象かは、そのページには書かれておらず、料金ページを見るよう案内されています。

A-3 既定のモデルを決める

「Model Provider」のページの右上の「Default Models」を押します。
「System Reasoning Model」を、使うモデル（チュートリアルでは gpt-5.2）にします。
公式のモデルプロバイダーのページは、この画面で決められるものを5つ挙げています。

項目	公式の説明
System Reasoning Model	一般的なLLMの処理に使う
Embedding Model	ナレッジの索引づくりと検索に使う
Rerank Model	検索結果の並べ替えに使う
Speech-to-Text Model	音声を文字にする
Text-to-Speech Model	文字を音声にする

モデルを選ばないアプリやノードは、ここの既定を使います（公式のモデルプロバイダーのページ）。

A-4 動作を確かめる

「Studio」で「Create from Blank」から最初のアプリを作り、テスト実行まで進めます。手順は06にあります。

B. セルフホスト：始める前に確かめること

公式の「Deploy Dify with Docker Compose」のページの表示です。

OS	必要なもの	公式の注記
macOS 10.14以上	Docker Desktop（Docker Compose 2.24.0以上）	Docker の仮想マシンに、2 vCPU以上、8 GiB以上のメモリを割り当てる
Linux	Docker 19.03以上、Docker Compose 2.24.0以上	Docker の公式ドキュメントから Docker Engine と Docker Compose を入れる
Windows（WSL 2）	Docker Desktop（Docker Compose 2.24.0以上）	ソースコードとデータは、Windows側でなく Linux のファイルシステムに置く

ハードウェアの最低条件は、CPU 2コア以上、RAM 4 GiB以上です（公式ページとREADMEで一致）。
Docker Compose のバージョンは、次のコマンドで確かめます（公式ページの記載）。公式は「2.24.0 or later」が必要と書いています。

docker compose version

次の手順1のコマンドは、git、curl、jq を使います（公式ページの記載）。

C. セルフホスト：入れて起動する（Docker Compose）

公式ページの手順を、順に並べます。コマンドは公式ページの写しです。手元の環境（OS、ネットワーク）に合わせて読み替える所は、そのつど書きます。

C-1 リポジトリを取得する

ターミナルを開き、Dify を置きたいディレクトリに移動します。
次のコマンドで、最新のリリースのタグを指定して取得します（公式ページの写し）。

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git

fatal: Remote branch null not found in upstream origin と出たら、公式は、GitHub の Releases ページで最新の版番号を確かめ、版を指定して取得する方法を書いています。

git clone --branch <version> https://github.com/langgenius/dify.git

<version> は、Releases ページで確かめた版のタグに置き換えます。

C-2 `docker` ディレクトリに入り、環境ファイルを作る

次のコマンドで移動します。

cd dify/docker

ひな形をコピーして、.env を作ります。

cp .env.example .env

C-3 エージェント用サンドボックスのトークンを設定する

次のコマンドで、ランダムな文字列を作ります。

openssl rand -base64 32

出力された文字列を、.env の DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN に設定します（.env をテキストエディタで開き、この変数の行に書く）。
公式ページの警告：この変数がないと、エージェント用のバックエンドとサンドボックスは起動しません。環境変数のページも、「両方のエージェント用サービスが、設定するまで終了と再起動をくり返す」と書いています。

C-4 コンテナを起動する

docker compose up -d

公式ページによると、これで次のものが起動します。

区分	名前
中核の7サービス	`api`、`api_websocket`、`worker`、`worker_beat`、`web`、`plugin_daemon`、`agent_backend`
依存の8つ	`weaviate`、`db_postgres`、`redis`、`nginx`、`ssrf_proxy`、`agent_ssrf_proxy`、`sandbox`、`local_sandbox`
1回だけ動くタスク	`init_permissions`（保存先の権限を設定して終了する）

C-5 起動を確かめる

docker compose ps

各サービスが Up か healthy になっていることを確かめます（公式ページの記載）。
init_permissions が Exited になっているのは想定どおり、と公式ページに書かれています。

C-6 管理者アカウントを作ってサインインする

ブラウザで初期設定のページを開きます。公式ページの表示は、手元のPCなら http://localhost/install、サーバーなら http://your_server_ip/install です。
画面に従って、管理者のアカウントを作ります。入力項目の名前と順は、このページで読んだ公式ページには書かれていませんでした（手元の画面で確かめてください）。.env の INIT_PASSWORD を設定してあると、このページに入るときに求められます（環境変数のページ）。
作成後、手元のPCなら http://localhost、サーバーなら http://your_server_ip でサインインします。
公式ページは、ポート番号を書いていません。上のURLは、HTTPの標準のポート（80）で nginx が受けることを示す、と読めます。ポートの変更方法は、このページで読んだ範囲では確認できていません。

C-7 OS別の注意（公式ページの記載のみ）

macOS：Docker Desktop に、2 vCPU以上、8 GiB以上のメモリを割り当てます。
Linux：Docker Engine と Docker Compose を、Docker の公式ドキュメントに従って入れます。
Windows（WSL 2）：ソースとデータは、Linux側のファイルシステムに置きます。
docker-compose.yaml を自分で変えた場合：公式は、新しいリリースのファイルに自分の変更を当て直すよう書いています。リリースが、Dify に必要な新しいサービスを足すことがあるためです。

D. 最初の設定（`.env`）

設定は docker/.env に書きます。公式ページは、必須の設定は docker/.env、必要に応じて足す設定は docker/envs/ のテンプレートを .example を外してコピーして編集する、と書いています。docker/.env の値は docker/envs/*.env の値に優先します。

cd dify/docker
cp envs/vectorstores/milvus.env.example envs/vectorstores/milvus.env

上は、公式ページの例（Milvus のテンプレートのコピー）です。設定を変えたあとは、次のとおりに再起動します（公式ページの記載）。

docker compose down
docker compose up -d

以下は、公式の「Environment Variables」のページから、初期設定に関わるものを選んで表にしました（表示された既定値と説明の要約です。全文は公式ページで確認してください）。

D-1 秘密の値（セキュリティと初期設定）

変数	既定	公式の説明の要約
`SECRET_KEY`	`.env.example` に値が入っている。置き換える	セッションやJWT、ファイルのURLの署名、OAuth の資格情報の暗号化に使う。変えると全員がログアウトし、ファイルのURLが無効になる。`openssl rand -base64 42` で作る
`INIT_PASSWORD`	空	初回設定の `/install` ページへの入場に使う。最大30文字。設定後は効果なし
`PASSWORD_PEPPER`	空	メンバーのパスワードに混ぜる、サーバー側の秘密の値。管理者アカウントを作る前に設定する。あとで変えると既存のサインインが壊れる
`DIFY_AGENT_SERVER_SECRET_KEY`	公開の開発用の鍵。置き換える	エージェント内部のトークンの元になる秘密。32バイトに復号できる必要がある
`DIFY_AGENT_API_TOKEN`	公開の開発用のトークン。置き換える	API がエージェントのバックエンドを呼ぶときのトークン
`DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN`	空。必須	設定するまで、エージェントの2つのサービスが終了と再起動をくり返す
`DB_PASSWORD`	`difyai123456`	データベースのパスワード。変更を促す文は、読んだ範囲では見つからない（接続文字列ではURLエンコードされる、との注記がある）
`REDIS_PASSWORD`	`difyai123456`	Redis の認証パスワード。変更を促す文は、読んだ範囲では見つからない

公式の環境変数のページには、「Security Warnings」という見出しは、読んだ範囲では見つかりませんでした。注意の囲み（WARNING など）と各変数の説明から、次のことが読めます。

SECRET_KEY、DIFY_AGENT_SERVER_SECRET_KEY、DIFY_AGENT_API_TOKEN は、.env.example に入っている値を、本番では置き換える（公式の表現は「must be replaced」の趣旨）。
DB_PASSWORD と REDIS_PASSWORD の既定は difyai123456。表に載っていますが、変更を促す文は見つかりませんでした（既定値が文書に載っている点は、この記事の見立てとして、確かめておく価値があります）。
CORS（WEB_API_CORS_ALLOW_ORIGINS、CONSOLE_CORS_ALLOW_ORIGINS）の既定は *。絞るよう求める文は見つかりませんでした。
INIT_PASSWORD：設定すると、/install のページは、管理者アカウントを作る前にこのパスワードを求める。説明には、サーバーが外に出ているときに、許可されていない初回設定を防ぐ、という趣旨がある。設定するよう求める文までは、見つかりませんでした。
PASSWORD_PEPPER は、管理者アカウントを作る前に設定する。あとで設定・変更・削除すると、既存のパスワードでサインインできなくなる。
ALLOW_REGISTER：説明に「招待制なら false のままにする」とある。
デプロイ後に SECRET_KEY を変えると、全員がログアウトし、ファイルのURLが無効になる（公式の警告）。

D-2 URL

変数	既定	公式の説明の要約
`CONSOLE_API_URL`	空	公開するバックエンドのURL。OAuth、Notion、OAuth を使うプラグインに必要。セキュアなCookieにも影響する
`CONSOLE_WEB_URL`	空	公開するコンソールのURL。メールのリンクとOAuthのリダイレクトに使う
`APP_WEB_URL`	空	公開したアプリのURL。Human Input のフォームのリンクに必要
`SERVICE_API_URL`	空（自動検出）	開発者に見せるAPIのベースURL
`FILES_URL`	空（`CONSOLE_API_URL` にフォールバック）	署名つきのファイルのリンクの元。これと `CONSOLE_API_URL` の両方が空だと、ファイルのプレビューが失敗する
`FILES_ACCESS_TIMEOUT`	`300`	署名つきのファイルのURLが有効な秒数

D-3 サインインと登録

変数	既定	公式の説明の要約
`ENABLE_EMAIL_PASSWORD_LOGIN`	`true`	メールとパスワードでのサインイン。少なくとも1つのサインイン方法をオンにしておく
`ENABLE_EMAIL_CODE_LOGIN`	`false`	メールのワンタイムコード。メール送信が必要
`ENABLE_SOCIAL_OAUTH_LOGIN`	`false`	GitHub と Google のサインインを表示する。APIにOAuthの資格情報が必要
`ALLOW_REGISTER`	`false`	利用者自身による新規登録を許す。招待制なら `false`
`REFRESH_TOKEN_EXPIRE_DAYS`	`30`	認証情報の再入力なしで、サインインしたままでいられる日数

D-4 CLI（difyctl）を使うときの設定

変数	既定	公式の説明の要約
`OPENAPI_ENABLED`	`false`	Dify CLI が使う `/openapi/v1/*` のAPIの全体スイッチ
`ENABLE_OAUTH_BEARER`	`false`	CLI 向けのOAuthベアラー認証。CLI を使うには、この変数と `OPENAPI_ENABLED` の両方が `true` である必要がある

D-5 保存先と大きさ

保存先（STORAGE_TYPE、DB_TYPE、VECTOR_STORE の既定）は01を参照してください。

アップロードの大きさを決める NGINX_CLIENT_MAX_BODY_SIZE の既定は 100M です。EXPOSE_NGINX_PORT、NGINX_PORT、NGINX_HTTPS_ENABLED は、読んだ環境変数のページには載っておらず、このページでは扱えません（公式で確認できていません）。

E. セルフホスト：何が外に出るか、どう制限するか

公式の記載の範囲で、整理します。攻撃の手順は書きません。

項目	公式の記載	制限の手がかり（公式の記載）
入口	`nginx` が、HTTPの標準のポートで受けると読める（URLにポートがない）	ポートの設定は、読んだページでは確認できていない
初回設定のページ `/install`	管理者アカウントを作るページ	`INIT_PASSWORD` を設定すると、管理者アカウントを作る前にパスワードが要る。説明に、サーバーが外に出ているときの、許可されていない初回設定を防ぐ、という趣旨がある
新規登録	`ALLOW_REGISTER` の既定は `false`	招待制なら `false` のまま
CORS	`WEB_API_CORS_ALLOW_ORIGINS` と `CONSOLE_CORS_ALLOW_ORIGINS` の既定は `*`	絞るよう求める文は、読んだ範囲では見つからない。`CONSOLE_CORS_ALLOW_ORIGINS` は、未設定なら `CONSOLE_WEB_URL` が使われる（公式の説明）
署名つきのファイルのURL	`FILES_ACCESS_TIMEOUT` の既定は300秒	有効な秒数を変えられる
外へ出る通信	`ssrf_proxy` は、プライベートIPの範囲への外向きのリクエストを止めるプロキシ、と書かれている	`SSRF_PROXY_HTTP_URL` と `SSRF_PROXY_HTTPS_URL` で指定する
コードの実行	Code ノードなどは `sandbox` サービスで動く（`CODE_EXECUTION_ENDPOINT`）	`CODE_EXECUTION_API_KEY` の既定は `dify-sandbox`。`sandbox` の `SANDBOX_API_KEY` と一致させる
公開したWebアプリ	初期状態では公開で、URLを知っていれば誰でも開ける（Web App Settings のページ）	それ以上のアクセス制限の設定（ログイン必須、メンバー限定など）は、読んだページには書かれていない。共有の前にURLの渡し先を確かめるのは、この記事の注意

アプリのMCPサーバーのURLと公開のAPIキーの扱いは07を参照してください。HTTPS の設定、ファイアウォール、リバースプロキシの置き方は、読んだ公式ページには手順がありませんでした。インターネットに出す場合は、公式のドキュメントの全体の目次から、該当のページを探して確かめてください。

F. モデルプロバイダーを入れる（Cloud とセルフホストで同じ画面）

公式の「Model Providers」のページ（クラウド版のドキュメント）の手順です。セルフホスト版の同じページは、今回読んでいません。手元の画面と照らして読んでください。

「Integrations」→「Model Provider」を開きます。なお、プロバイダーを管理できるのは、ワークスペースのオーナーと管理者だけです。
目的のプロバイダーが入っていなければ、「Install model providers」から探すか、Marketplace で入れます。
プロバイダーのカードの「Setup」を押します。
APIキーなどの必要な情報を入れます。Dify は、プロバイダーを使えるようにする前に、キーを確かめます（公式の記載）。
自分のキーと Cloud のクレジットを両方持っているときは、カードの「Usage Priority」で、どちらを先に使うかを決めます。もう一方は予備になります。
独自のモデルを足すときは、カードの「Add Model」で、名前と資格情報を入れます。固定のモデルだけのプロバイダーには「Add Model」が出ません。同じ名前・同じ種類のモデルがあるときは、重複を作らず、そのモデルにキーがひも付けられます。
キーの管理：カードの「Configure」（プロバイダーのモデルのキー）、モデルごとの「Configure」、カードの「Manage Credentials」（独自のモデルのキーの全部）。独自のモデルの唯一のキーを消すと、モデルも消えます。
複数のキーを順に使う「Load Balancing」は、公式のページで「Professional Team plan」の見出しの下にあります。

ローカルのモデルの接続は、このページには書かれていません。

G. difyctl（コマンドラインツール）を入れる

difyctl は、公式のコマンドラインツールです。Dify 1.15.0 で加わったと、インストールのページにあります。使い方は07で扱います。ここでは、入れ方だけ並べます。

条件（公式のインストールのページ）

対応：macOS と Linux（x64、arm64）、Windows（x64）。
追加のソフトは要らない、単独で動く実行ファイル。
ビルドごとに対応する Dify の版が決まっているので、サーバーの DIFY_VERSION に合う版を入れます。

macOS・Linux

公式のページの写しです（~/.local/bin/difyctl に入ります）。

curl -fsSL https://raw.githubusercontent.com/langgenius/dify/main/cli/scripts/install-cli.sh | DIFY_VERSION=1.17.1 sh

1.17.1 は公式ページの例です。自分のサーバーの版に合わせて置き換えます。この形（ダウンロードしたスクリプトをそのまま実行）は、実行の前に中身を見たい人もいます。手動のダウンロード（下）を選ぶこともできます（これは僕らの見立てで、公式の指示ではありません）。

Windows

公式のページの写しです（%LOCALAPPDATA%\difyctl\bin\difyctl.exe に入ります）。

$env:DIFY_VERSION = "1.17.1"
irm https://raw.githubusercontent.com/langgenius/dify/main/cli/scripts/install.ps1 | iex

手動のダウンロード（全OS）

Dify の GitHub Releases から、実行ファイル（difyctl-v<version>-<os>-<arch>）とチェックサムのファイル（difyctl-v<version>-checksums.txt）をダウンロードします。
SHA-256 を、チェックサムのファイルと比べます（macOS・Linux は shasum -a 256 difyctl-v<version>-<os>-<arch>、Windows は Get-FileHash difyctl-v<version>-windows-x64.exe）。違うときは、公式は、ダウンロードを消してやり直すよう書いています。
PATH の通った場所に移します（コマンドは公式のインストールのページで確認してください）。

任意の環境変数（インストール時）

変数	公式の説明
`DIFY_VERSION`	インストールに使う Dify のリリースタグ。省略すると最新。サーバーに合わせる
`DIFYCTL_VERSION`	`difyctl` のビルドを固定する。`DIFY_VERSION` が未設定のときだけ使われる
`DIFYCTL_PREFIX`	インストール先（既定 `~/.local`）。実行ファイルは `<prefix>/bin` に入る

確かめる・更新・削除

difyctl version

Client: のブロックに、バージョンとプラットフォームが出れば入っています。command not found なら、PATH にインストール先を足します（macOS・Linux は ~/.zshrc か ~/.bashrc に export PATH="$HOME/.local/bin:$PATH"）。Windows のコマンドは公式の原文で確かめてください。
更新：インストールのコマンドを、もう一度実行します（その場で置き換わる）。
削除：macOS・Linux は rm ~/.local/bin/difyctl、Windows は Remove-Item -Recurse "$env:LOCALAPPDATA\difyctl"。先にサインアウトするなら difyctl auth logout。

セルフホストでは、サインインの前に、.env の OPENAPI_ENABLED と ENABLE_OAUTH_BEARER を true にする必要があります（D-4）。

H. 動作の確かめ方

確かめたいこと	手順	期待される結果（公式の記載）
コンテナが動いている	`docker compose ps`	各サービスが `Up` か `healthy`。`init_permissions` は `Exited` で想定どおり
管理者アカウントができた	`http://localhost/install` で作成し、`http://localhost` でサインイン	サインインできる
モデルが使える	「Integrations」→「Model Provider」で、プロバイダーの「Setup」にキーを入れる	キーの確認が通ると、使えるようになる
アプリが動く	「Studio」でアプリを作り、テスト実行	06を参照

I. 停止、再起動、更新

停止と再起動：公式ページは、docker compose down のあと docker compose up -d、と書いています。停止だけの別のコマンドは、そのページには載っていません。
更新：公式のページは、リリースごとに手順が違うとして、Releases ページの、移行先の版のアップグレードの案内に従う、と書いています。更新したあとは、それぞれの .env.example と .env を比べて、新しい変数や変わった変数がないか確かめます。

J. つまずきと直し方

症状	公式の記載から読める原因	直し方（公式の記載）
`git clone` が `Remote branch null not found` で失敗	最新のタグの取得に失敗	Releases ページで版を確かめ、`git clone --branch <version> …` で取得
エージェント用のサービスが終了と再起動をくり返す	`DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN` が空	`.env` に値を入れて、`docker compose up -d`
`init_permissions` が `Exited`	想定どおり	対応不要（初期化タスクで、終了する設計）
`.env` を変えたのに反映されない	再起動していない	`docker compose down` → `docker compose up -d`
全員がログアウトした／ファイルのURLが無効になった	`SECRET_KEY` を変えた	`SECRET_KEY` を変えると、全員がログアウトし、ファイルのURLが無効になると書かれている。元の値に戻せるかは、公式の資料では確認できていない
既存のサインインが壊れた	`PASSWORD_PEPPER` をあとから足した／変えた	管理者を作る前に設定するもの、と書かれている。戻し方は、読んだページには書かれていない
ファイルのプレビューが失敗する	`FILES_URL` と `CONSOLE_API_URL` の両方が空	どちらかに、公開のURLを設定する
`difyctl: command not found`	PATH に入っていない	PATH にインストール先を足す（G）
difyctl のサインインが通らない（セルフホスト）	`OPENAPI_ENABLED` と `ENABLE_OAUTH_BEARER` が `false`	両方を `true` にして、再起動
Windows で動作が遅い・おかしい	ソースとデータを Windows側に置いた	Linux側のファイルシステムに置く（公式の注記）

気をつけること

この記事は、実際に使って確かめた記録ではありません。公式のドキュメントとREADMEを読んだ範囲で、公式ページは要約の形で取得しています。コマンドや設定値は、手元で公式の原文を見ながら進めてください。
画面の表記は変わります。手元の画面と照らして読んでください。
この記事のモデル追加・アプリ作成の画面の説明は、公式のクラウド版のドキュメント（/en/cloud/ の配下）に基づきます。セルフホスト版の同じ画面について、公式が違いを書いているページは、読んだ範囲では見つかりませんでした（読んだクラウド版のページ自体も、セルフホストとの違いには触れていません）。手元の画面と照らして読んでください。
公式ページの要約で、「モデルのクレジットの対象」「サインインの入力項目」「HTTPSの設定」「ポートの変更」は、確認できませんでした。書かれていないことは、足していません。
クイックスタートの gpt-5.2 は、公式のチュートリアルが選んだモデルです。クレジットの対象かどうかは、料金ページで確かめてください。