langgenius

RAG のデスクトップ 1. はじめに 古いPCに、FAISS と Dify を使用したRAG環境を構築します。NVIDIA GeForce などのグラフィックボードを搭載していないため、FAISS は最高性能ではありませんが、個人で使用するには十分です。LLM は、クラウドの OpenAI を使用します。 以前に書いた Docker Desktop、Dify のインストールの記事はこちら。 qiita.com 以前に書いた FAISS のインストールの記事はこちら。今回は NVIDIA ドライバをインストールしません。 qiita.com qiita.com RAG を実行するためのアプリケーションは他にもありますが、問い合わせ（テキスト）と登録した文書（テキスト)の、より正確なマッチングを行うために、単にコサイン類似度を計算したいので、FAISS を使用します。 文書の埋め込み（embedding）には、クラウドの OpenAI text-embedding-3-large を使用します。NVIDIA GeForce グラフィックボードを搭載した別のPCで、Alibaba qwen3-embedding-8b のようなローカルの embedding を使用することも可能です。 2. Xubuntu インストール PC電源投入時、 起動メニュー F12キー BIOS F2キー デスクトップの使い易さのために Xubuntu を使用しています。日本語入力をセットアップしますが、画面は英語のままにしています。 xubuntu-26.04.1-desktop-amd64.iso Rufus を使って起動 USB メモリを作成（DVD からだとアクセスが頻発して正常に動作しなかった） PCの電源を入れて F12キーを押して USB から立ち上げる デスクトップに表示される Install Xubuntu 26.04.1 LTS アイコンをダブルクリックして、PCへのインストールを開始 Language: English Keyboard: Japanese Connect to the internet: Connect to a Wi-Fi network ※ 先にメニューバーから接続しておく An update is available for the installer: Update now ※ インストーラーを再開 Interactive installation Xubuntu Desktop Erase disk and install Xubuntu Select drive: sda - 500GB SSD-PSTA/D BUFFALO No encryption Your name: webmaster Your computer's name: noble34 Your username: webmaster Password: ** Confirm password: ** Select your timezone: Asia/Tokyo インストールが終わったら、USB メモリを外して起動 OS アップデート sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade 再起動 SSH インストール sudo apt update sudo apt install openssh-server 外部から SSH で接続 ssh -l webmaster 192.168.1.41 password: ** Xfce メニュー メニューから Panel Profiles、Xfce 4.16、Apply Configuration ボタン押下 Application -> Settings -> Xfce Screensaver 60 minutes Application -> Settings -> Language Support 追加のインストールのためにパスワードを入力 Install / Japanese、Password 但し、画面表示は英語のままで使用する 再起動 ログイン後、バー右上、右クリック、Preference -> Input Method -> Add Japanese -> Mozc Preference -> General -> Keyboard Shortcuts ＜Super＞space から ＜Control＞space に変更、Apply ボタン バー右上、左クリックで Input Mode を Direct input から Hiragana に変更 固定IP Wifi 接続の場合は、メニューバー右上でマウス右クリック、Edit Connections から設定する Address: 192.168.1.34 Netmask: 255.255.255.0 Gateway: 192.168.1.1 DNS: 999.999.99.99, 888.888.888.88 ※プロバイダから入手 再起動 よく使うコマンド pwd ls -alF ip addr show nano .env（矢印キーでカーソル移動、保存Ctrl+S、終了Ctrl+X） sudo reboot sudo shutdown -h now 画面キャプチャ PrtSc、範囲指定 Shift+PrtSc、アクティブウィンドウのみ Ctrl+PrtSc ※ Alt が機能しないため Settings - Keyboard - Application Shortcuts で Ctrl に変更 3. Docker Desktop 下記リンクの手順に従って、Ubuntu に Docker Desktop をインストールします。 docs.docker.com １．Docker の APT レポジトリの設定 ＃ Add Docker's official GPG key ＃ Add the repository to Apt sources ２．Docker パッケージのインストール sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin ３．hello-world イメージの実行 sudo docker run hello-world docs.docker.com sudo apt install gnome-terminal docker-desktop-amd64.deb をダウンロード sudo apt-get update sudo apt install ./docker-desktop-amd64.deb 再起動 メニューから Development > Docker Desktop で起動。または systemctl --user start docker-desktop で起動 ユーザー登録は行わず、skip、skip で Docker Containers の画面が表示される 　 Docker Desktop のコンテナーのメモリ制限を、2GB（デフォルト）から4GBに変更する <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="600"> 　 Docker Desktop の自動起動 Docker Engine は、Xubuntu 標準のものと、Dify のためにインストールした Docker Desktop のものがあります。次のコマンドでどちらを使用しているか確認できます。 docker context ls webmaster@noble01:~$ docker context ls NAME DESCRIPTION DOCKER ENDPOINT ERROR default Current DOCKER_HOST based configuration unix:///var/run/docker.sock desktop-linux * Docker Desktop unix:///home/webmaster/.docker/desktop/docker.sock Docker Desktop は、ユーザーがログインした後でないと起動できません。GUI で以下を設定します。 Settings、Session and Startup、Application Autostart Add Name: Docker Desktop Comment: Docker Desktop 起動 Command: /opt/docker-desktop/bin/docker-desktop Docker Desktop を起動すると、Dify のコンテナが自動的に起動します。 4. Dify docs.dify.ai mkdir Repos cd Repos git clone --branch 1.18.0 https:\/\/github.com/langgenius/dify.git cd dify/docker cp .env.example .env openssl rand -base64 32 表示されたキーを .env の DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN に記入する nano .env docker compose up -d インストールが完了すると、Docker Desktop で実行中になる <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> ブラウザで 192.168.1.34 または localhost を表示 管理者アカウントの設定 Email address Username Password ブラウザで 192.168.1.34 または localhost を表示 Email と Password でログイン LLMモデルの設定 連携 － モデルプロバイダーをインストール OpenAI API Key：**** デフォルトのモデルは gpt-5.4-mini 従来との互換性のために gpt-4.1 を選択 HTTPS 化（手順はこちら） ドメインを取得し、ホスト名を登録する ルーターの80と443のポートフォワードを、このPCにする 自分のドメインでこのPCの http:\/\/localhost/ が表示されることを確認する docker/.env の編集。.env に、説明にある赤字の項目を設定する コマンドの実行（Docker Desktop が立ち上がっていること） cd dify/docker docker compose --profile certbot up --force-recreate -d コンテナが作成された後に、 docker compose exec -it certbot /bin/sh /update-cert.sh docker/.env の（再）編集。.env に以下を設定する NGINX_HTTPS_ENABLED=true コマンドの実行 docker compose --profile certbot up -d --no-deps --force-recreate nginx 外部から your_domain.com で見れることを確認する SSL 証明書の更新 docker compose exec -it certbot /bin/sh /update-cert.sh docker compose exec nginx nginx -s reload 　 <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> 5. FAISS Anaconda anaconda.com ホームページでメールを登録すると、ダウンロードリンクが届きます Linux、現在 Python 3.14.4 Anaconda3-2026.07-1-Linux-x86_64.sh をダウンロード。home ディレクトリにファイルを移動 bash ~/Anaconda3-2026.07-1-Linux-x86_64.sh ./anaconda3/bin/conda init 次のターミナルの起動から、conda 環境（base）になります <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="600"> FAISS 用に、Python のバージョンを 3.12 にします conda create -n faiss python=3.12 -y conda activate faiss echo 'conda activate faiss' >> ~/.bashrc <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="600"> 解除は conda deactivate 　 ベクトルデータベース（faiss）のインストール facebookresearch/faiss 事前準備 sudo apt install unzip faiss-cpu インストール conda install -c pytorch -c conda-forge faiss-cpu=1.15.1 ※ バージョンは FAISS のウェブページに表示されているもの 動作確認のために、faiss のページにある DOWNLOAD ZIP からプログラムコード一式をダウンロードします <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="700"> unzip faiss-main.zip cd faiss-main/tutorial/python (faiss) webmaster@noble34:~/faiss-main/tutorial/python$ ls -1 1-Flat.py 10-FaissCuvsExample.ipynb 11-SVS.py 2-IVFFlat.py 3-IVFPQ.py 4-GPU.py 5-Multiple-GPUs.py 6-HNSW.py 7-PQFastScan.py 8-PQFastScanRefine.py 9-RefineComparison.py python 1-Flat.py True 100000 [[ 0 393 363 78] [ 1 555 277 364] [ 2 304 101 13] [ 3 173 18 182] [ 4 288 370 531]] [[7.6293945e-06 7.1751785e+00 7.2076302e+00 7.2511673e+00] [0.0000000e+00 6.3235664e+00 6.6845779e+00 6.7999382e+00] [3.8146973e-06 5.7964020e+00 6.3917236e+00 7.2815170e+00] [3.8146973e-06 7.2779007e+00 7.5279808e+00 7.6628418e+00] [0.0000000e+00 6.7638016e+00 7.2951088e+00 7.3688126e+00]] [[ 381 207 210 477] [ 526 911 142 72] [ 838 527 1290 425] [ 196 184 164 359] [ 526 377 120 425]] [[ 9900 10500 9309 9831] [11055 10895 10812 11321] [11353 11103 10164 9787] [10571 10664 10632 9638] [ 9628 9554 10036 9582]] python 2-IVFFlat.py [[ 9900 9309 9810 10048] [11055 10895 10812 11321] [11353 10164 9787 10719] [10571 10664 10632 10203] [ 9628 9554 9582 10304]] [[ 9900 10500 9309 9831] [11055 10895 10812 11321] [11353 11103 10164 9787] [10571 10664 10632 9638] [ 9628 9554 10036 9582]] python 3-IVFPQ.py [[ 0 78 424 608] [ 1 555 1063 380] [ 2 179 304 33] [ 3 265 527 139] [ 4 288 531 827]] [[1.5948839 6.2905183 6.3059173 6.5697308] [1.282814 5.9320083 5.9512424 6.5773916] [1.698801 6.1244454 6.2004113 6.401427 ] [1.82021 6.721145 6.8056335 6.995647 ] [1.4857421 5.8346977 6.303232 6.400938 ]] [[ 8746 9380 10914 9842] [10913 11373 9014 10507] [10719 11291 10600 11353] [11578 9671 10709 10664] [ 9229 9878 9905 9459]] 　 PostgreSQL インストール sudo apt update sudo apt install postgresql postgresql-contrib psql --version sudo -i -u postgres psql postgres=# CREATE USER admin WITH PASSWORD '<font color="green">mypassword</font>' SUPERUSER; CREATE USER webmaster WITH PASSWORD '<font color="green">mypassword</font>'; CREATE DATABASE webmaster OWNER webmaster; \q で抜ける exit で postgres ユーザーを抜ける psql -U webmaster -d webmaster -h localhost CREATE TABLE knowledge_documents ( id UUID PRIMARY KEY, knowledge_id TEXT NOT NULL, content TEXT NOT NULL, title TEXT NOT NULL, metadata JSONB, created_at TIMESTAMP DEFAULT now() ); \q で抜ける \d knowledge_documents　　（テーブル一覧） \l　　（データベース一覧） \c　　（現在接続しているデータベース） SELECT * FROM knowledge_documents; TRUNCATE TABLE knowledge_documents; 　 faiss_service の作成 次のように作成します。 |項目|ツール| |---|---| |文書データベース|PostgreSQL| |ベクトルデータベース・検索|faiss-cpu| |埋め込み（Embeddings）|OpenAI API（text-embedding-3-small）<br>ナレッジIDを指定して切り替え可能| |ウェブサーバー|Python Flask| # 一旦、通常の Ubuntu 環境に戻す conda deactivate sudo apt update sudo apt install -y build-essential libpq-dev python3-dev # conda 環境で実行 conda activate faiss pip install flask psycopg2 openai flasgger ollama mkdir faiss_service cd faiss_service nano faiss_service.py ［faiss_service.py を他のPCからコピーして入手］ LangChain を使用したチャンク分割（upload_files_chunk）は行わないこととし、upload_files_chunk の部分を削除します。また、LangChain の API_KEY も設定しません。 faiss_gpu から faiss_cpu への変更 # 変更前 res = faiss.StandardGpuResources() # use a single GPU gpu_index = faiss.index_cpu_to_gpu(res, 0, index) index = faiss.index_gpu_to_cpu(gpu_indexes[knowledge_id]) # 変更後 #res = faiss.StandardGpuResources() # コメントアウトまたは削除 gpu_index = index # 3か所 index = gpu_indexes[knowledge_id] # 1か所 export PSQL_DB_PASSWORD="..." export OPENAI_API_KEY="..." python faiss_service.py <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> ウェブページを表示 http:\/\/192.168.1.34:8000/apidocs/ <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="650"> コンテンツエディター 登録済みのコンテンツ（テキスト）を確認・編集するためのウェブページを作成します。［保存して更新］ボタンを押下すると、faiss_service の delete と add を呼び出します（Faiss を使用しているため、登録済みの内容は変更ではなく、再登録します）。 pip install requests mkdir content_editor cd content_editor nano app.py ［app.py を他のPCからコピーして入手］ mkdir templates nano templates/index.html nano templates/edit.html ［index.html と edit.html を他のPCからコピーして入手］ 　 ［ 実行 ］ export PSQL_DB_PASSWORD="**" python app.py 　 ［ 表示 ］ localhost または、 192.168.1.34 （他のPCからIPアドレスを指定） 　 <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> 　 <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="650"> 　　　 <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="650"> 　 Ubuntu 起動時に Python プログラムを実行する 参考ページ１： udemy.benesse.co.jp cd ~ nano py_app_service.sh export PSQL_DB_PASSWORD="..." export OPENAI_API_KEY="..." /home/webmaster/anaconda3/envs/faiss/bin/python /home/webmaster/faiss_service/faiss_service.py & /home/webmaster/anaconda3/envs/faiss/bin/python /home/webmaster/content_editor/app.py & wait chmod 744 py_app_service.sh bash py_app_service.sh 　 参考ページ２： note.com cd /etc/systemd/system sudo nano run_python.service [Unit] Description=python run After=network.target [Service] Type=simple User=webmaster WorkingDirectory=/home/webmaster/faiss_service ExecStart=/bin/bash /home/webmaster/py_app_service.sh Restart=on-failure KillMode=control-group [Install] WantedBy=multi-user.target ※ データファイルを読み込むため、ワーキングディレクトリを faiss_service に設定する sudo systemctl daemon-reload sudo systemctl enable run_python.service sudo systemctl start run_python.service sudo systemctl status run_python.service sudo systemctl stop run_python.service 　 多数のファイルを一度に登録する faiss_service の画面では、最大20個のファイルを手動で指定し、登録できるようにしています。実際は、別に Python プログラムを作成し、テキストファイル（input.txt）に記述したファイル一覧をもとに、一括登録できるようにしています。input.txt の1行目には、すべてのファイルに共通するナレッジIDを記入し、2行目以降には登録するファイル名を記述します。プログラムは faiss_service.py の upload_files をもとに作成しいますが、ここでは内容を割愛します。 ファイル一覧の作成： ls *.txt > input.txt nano input.txt 1行目にナレッジIDを記入 2行目以降はファイル名 python upload_files.py 　 Dify と FAISS を接続 Dify で外部ナレッジベースの設定を行って、faiss_service に接続します。 ナレッジ 「外部ナレッジベースと連携　→」 <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> 外部ナレッジベース連携APIを追加 API Key は未使用なので ABCdef など <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"><br> <img src="qiita-image-store.s3.ap-northeast-1.amazonaws.com" width="450"> 外部ナレッジベース名: ローカルRAG 外部ナレッジベースID: AAA-BBB-CCC 「連携　→」ボタン押下 　 事前準備（以前からの修正） 従来は Dify 1.13.0 を使用していましたが、1.18.0 に変更したところ、以下の対応が必要でした。 SSRF プロキシ対応 cd dify/docker nano .env 変更前： SSRF_PROXY_ALLOW_PRIVATE_IPS= 変更後： SSRF_PROXY_ALLOW_PRIVATE_IPS=192.168.1.34 設定の反映 docker compose up -d --force-recreate ssrf_proxy 確認 docker exec docker-ssrf_proxy-1 \ &nbsp;&nbsp;cat /etc/squid/dify_allow_private.conf 　 faiss_service.py、retrieval のレスポンスにおける score の型変換 変更前： records.append({ &nbsp;&nbsp;"score": score 変更後： records.append({ &nbsp;&nbsp;"score": float(score) 　 6. その他 □ ファイアウォール sudo ufw enable sudo ufw allow 'Nginx Full' sudo ufw allow OpenSSH sudo ufw reload sudo ufw status sudo ufw status numbered sudo ufw delete 3 　 □ ブルートフォース攻撃対策 sudo apt update sudo apt install fail2ban sudo nano /etc/fail2ban/jail.d/sshd.local [sshd] enabled = true backend = systemd port = ssh filter = sshd maxretry = 5 findtime = 600 bantime = 86400 10分間に5回以上SSH認証に失敗したIPアドレスを、24時間遮断する設定になる sudo systemctl enable --now fail2ban sudo systemctl restart fail2ban sudo systemctl status fail2ban 　　 以上、

Dify 1.19.0——ネストしたワークフロートレースと3つの変更が企業運用に何をもたらすか Dify でワークフローが呼び出す Workflow Tool の中で何が起きているか、今まで「Tool スパンが通った」「Tool スパンが失敗した」しか見えなかった。内部の LLM コールやステップが追えなかった。v1.19.0 でそれが変わった。 > この記事で分かること： > - Dify 1.19.0（2026-11-04 リリース）の3つの主要変更 > - ネストしたワークフロートレースの仕組みと実務での使い所 > - アップグレード前に確認すべき Docker Compose 2.35.0 以上の要件 Dify 1.19.0 は 2026-11-04 にリリースされた。変更の全容は公式リリースページ（github.com/langgenius/dify/releases/tag/1.19.0%EF… Dify Enterprise を使っている立場から、実務に直結する3か所を整理する。 1. ネストしたワークフロートレース（Nested Workflow Tracing） 変更内容：ワークフロー内で Workflow Tool を呼び出したとき、その内部のステップや LLM コールが外部トレース（Langfuse など）に階層構造で出るようになった。 今まで： - 外側のワークフロー → Workflow Tool のスパン（通った/失敗した）しか見えない - Workflow Tool の中で何が起きたか、どの LLM コールが遅かったか、どのステップで詰まったかは追えない v1.19.0 以降： - Workflow Tool の呼び出しスパンの下に、内部のステップが階層で並ぶ - LLM コールのプロンプト・レスポンス・トークン数も確認できる - ネストした Tool が複数回呼ばれた場合も、各呼び出しが別々のスパンとして残る 注意点： - 新しいトレース階層は「今後の実行」に適用される。既存の履歴はバックフィルされない - Workflow Tool の内部ステップが永続化されている必要がある（1.18.0 以降の Console ドリルダウン機能を前提としている） - ローリングデプロイ中はトレースキューの移行手順（ops_trace → ops_trace_v2）が必要 大企業内で Dify を使っていると、ワークフローが複数の Workflow Tool を呼び出す複雑な構成になることがある。今まで「どの Tool で詰まっているか」を切り分けるのに、ログをひとつひとつ確認する必要があった。ネストトレースが取れると、この調査時間が大きく変わる。 2. Workflow Tools の App パッケージへの同梱（.ifpkg v2） 変更内容：App をエクスポートすると、そのアプリが使っている Workflow Tools も一緒に .ifpkg パッケージに含まれるようになった。 今まで： - App をエクスポートしても、Workflow Tools の定義は含まれなかった - 別環境にインポートするとき、Workflow Tools を別途作成・登録する必要があった v1.19.0 以降： - .ifpkg（format v2）に Workflow Tools の定義が含まれる - インポート先で既存の Tool と重複する場合は再利用し、ない場合は作成・公開・登録まで自動で行う - 推移的な依存（Tool が呼び出す Tool）も含まれる 重要な注意：すべての Dify App エクスポートが format v2 になった。古い v1 のインポーターは受け付けない可能性がある。インポート先も 1.19.0 以上に揃えてからパッケージをインポートすること。 複数の Dify 環境（開発・ステージング・本番）を使っている場合に、この変更の影響が出る。移行の順序は「インポート先を先に 1.19.0 にアップグレードしてから、エクスポート・インポートを行う」という手順になる。 3. difyctl による Skills 管理（6コマンド追加） 変更内容：difyctl に Skills を管理する6つのコマンドが追加された。 | コマンド | 操作 | |---|---| | difyctl get skill | Skills の一覧（キーワード・タグフィルタあり） | | difyctl describe skill | 詳細・ドラフトハッシュ・最新版の確認 | | difyctl get skill version | 公開済みバージョンの一覧 | | difyctl export skill | ドラフトまたは指定バージョンを ZIP でエクスポート | | difyctl import skill --files | ローカルファイルから Skill を作成またはドラフトを置き換え | | difyctl publish skill | ドラフトを新しいバージョンとして公開 | 注意点： - アカウント caller 権限が必要（ワークスペース側の対応する権限も必要） - Skills が有効化されている必要がある - difyctl import は公開しない（import ≠ publish） - 既存 Skill への上書き import は「破壊的」操作として扱われる CI/CD に組み込んで Skill のバージョン管理をしたい場合に使える。今まで Skill の変更は GUI からしか行えなかったが、コマンドラインから操作できるようになったことで、自動化の幅が広がる。 アップグレード前に確認：Docker Compose 2.35.0 以上が必須 変更内容：Docker Compose の最小必須バージョンが 2.35.0 になった。 これは .env ファイルの優先順位の解決方法が変わったことに関係している。root の .env オーバーライドが service のデフォルトより優先されるように動くには 2.35.0 以上が必要。 確認コマンド： docker compose version 2.35.0 未満の場合はアップグレードしてから Dify 1.19.0 に更新する。 ローリングデプロイを行う場合は、トレースキューの移行手順が必要。新しいキュー ops_trace_v2 を、API・worker・Beat のすべてで同時に切り替える必要がある。古いキュー ops_trace のワーカーは、溜まっているタスクが空になってから停止する。 その他のアップグレード注意点： - 環境ファイル（.env）は既存のものをそのまま使う。誤って空にしないよう注意 - plugin daemon を 0.6.14-local に更新する - 1.18.0 より前からアップグレードする場合は 1.18.0 のアップグレードガイドも確認する - バックアップ（DB・ベクトルストア・ファイル）は事前に取っておく 今回確認したこと v1.19.0 の変更のうち、企業 Dify 運用に直結するのは次の3点： 1. ネストトレース：Workflow Tool の内部まで追えるようになった。複雑な構成でのデバッグ・パフォーマンス調査に効く 2. Workflow Tool のパッケージ同梱：環境間移行が楽になるが、インポート先を先に 1.19.0 に揃えることが必要 3. Docker Compose 2.35.0 必須：破壊的変更。アップグレード前にバージョン確認を Dify の活用場面や設計についてはこちらでも書いている： Copilotで議事録を作るとき、事前にやること

Dify 1.19.0 把被调用的子工作流细节带进了 Langfuse 等追踪工具。 沿调用层级查提示词、回复和 token 用量，方便定位哪一步出错。 仅限新运行，历史追踪不会补齐。自部署升级先备份，Docker Compose 需 ≥2.35.0；其他升级要求见官方说明。 github.com/langgenius/dify/releases/tag/1.19.0

Dify deployments need a boundary between app keys and console authority Dify deployments need a boundary between app keys and console authority Self-hosted Dify installations combine an application-building console, runtime APIs, worker services, and a sandbox used by workflow code. They can be valuable to an organization and easy to place on the internet without a clear ownership record. For a Dify deployment, the useful inventory starts with which parts are reachable, which credential controls each part, and whether an application key has been mistaken for console authority. At about 23:48 UTC on 29 October 2026, count-only ZoomEye SDK queries with sub_type=all and page size 1 returned 12,952 matches for app="Dify" and 11,189 for title="Dify". These are asset observations, not confirmed vulnerable installations. The difference between the fingerprints also means the two numbers should not be merged into one population. The app query is the primary observation for this article, but it does not prove authentication state or version. Separate the planes The console is used to create and administer applications, datasets, and workspace settings. An application API key is intended for calls to a published app and is scoped to that app. The two should not share a browser session, reverse-proxy rule, or credential distribution path. An internet-facing console needs strong administrator authentication and network policy; an application API may need a different route, rate limit, and key rotation process. Review every reachable hostname and path, including the API, console, web front end, worker health endpoint, and sandbox service. A public web UI does not mean the internal services must be public. Put the management plane behind an identity-aware proxy or private network and require a separate approval for changes to workspace-wide configuration. Inventory application keys as identities Each application key should have an owner, environment, upstream app, permitted data sources, issue date, and replacement plan. Store the secret in a secrets manager, not in a repository or a static front-end bundle. Confirm the key cannot be used against a different application or the console. Test the negative case: use a valid key with the wrong app identifier and verify the service rejects the request. Look at the data path after authentication. A workflow can call external tools, read datasets, execute code in a sandbox, or invoke a model provider with a separate credential. The application key's scope is only one part of that chain. An unprivileged caller should not be able to choose arbitrary sandbox code, call an internal metadata service, or reach a credential that belongs to a different workflow. Inspect the deployment evidence Use ZoomEye and internal asset data to find Dify fingerprints, then verify ownership through DNS, cloud inventory, and an authenticated owner. Record the public endpoint, response headers, TLS certificate, and authentication challenge. Do not attempt to bypass a login or test credentials you do not own. For an authorized assessment, confirm whether the console has MFA, whether default accounts remain, whether SSO is enforced, and whether administrative changes are logged. The public count is useful for prioritization. It tells a security team that Dify is a recognizable part of the internet's application layer and that the organization should be able to find its own deployments. It does not tell them that every matching asset is exploitable or that a self-hosted instance has the same configuration as the next one. Make the boundary observable Alert on new internet-facing console hostnames, changes to the public API allow list, and application keys that are used from a new network or with a sudden increase in volume. Keep an audit trail of app creation, key replacement, member invitations, and dataset connections. A console login and an application API call should produce distinguishable events. The practical test is to ask who owns the console, which applications are published, which keys are active, and which sandbox or tool credentials each workflow can reach. If those answers live in different teams with no shared inventory, a public Dify page is a symptom of missing governance as much as a possible configuration issue. References [1] Dify environment variable example [2] Dify repository [3] Dify README [4] ZoomEye count observation for app="Dify"

30 projetos GRÁTIS do GitHub para trabalhar melhor com IA Descubra 30 projetos gratuitos do GitHub para usar IA, criar conteúdo e organizar seu trabalho. Veja ferramentas de vídeo, produtividade, segurança, marketing e servidores, com os links organizados por assunto abaixo. Conheça o Bora Criar com IA: boracriarcomia.com.br CAPÍTULOS 00:00 Apresentação e inteligência artificial 00:35 Segurança 00:47 Vídeo e conteúdo 01:10 Negócios e marketing 01:30 Produtividade 01:46 Servidores e infraestrutura 02:23 Projetos para explorar 02:38 Antes de instalar INTELIGÊNCIA ARTIFICIAL 1. Dify — langgenius/dify 2. Taskosaur — Taskosaur/Taskosaur 3. OpenWork — different-ai/openwork 4. Agent Browser — vercel-labs/agent-browser 5. Emdash — generalaction/emdash SEGURANÇA 6. PasteGuard — sgasser/pasteguard 7. Claude Code Safety Net — kenryu42/claude-code-safety-net VÍDEO E CONTEÚDO 8. OpenReel — Augani/openreel-video 9. BridgeClip — bridge-mind/bridgeclip 10. Recordly — webadderall/Recordly 11. Textream — f/textream 12. FFmpeg Skill — kajisho5/ffmpeg-skill 13. Presenton — presenton/presenton NEGÓCIOS E MARKETING 14. Deskcomm CRM — melgarafael/DeskcommCRM 15. Open SEO — every-app/open-seo 16. Cogsend — deepakness/cogsend PRODUTIVIDADE 17. Handy — cjpais/Handy 18. Kept — ericerkz/kept 19. Excalidraw MCP — excalidraw/excalidraw-mcp 20. ezBookkeeping — mayswind/ezbookkeeping SERVIDORES E INFRAESTRUTURA 21. Dockge — louislam/dockge 22. OpenObserve — openobserve/openobserve 23. LogDeck — AmoabaKelvin/logdeck 24. WebSSH — bifrost0x/webssh 25. Breakscale — xevrion/breakscale 26. SQLit — Maxteabag/sqlit 27. Mailflare — hieunc229/mailflare 28. Open Archiver — LogicLabs-OU/OpenArchiver PROJETOS PARA EXPLORAR 29. Vibecraft — Nearcyan/vibecraft 30. God's Eye View — bilawalsidhu/gods-eye-view Confira licença, requisitos, custos de hospedagem e manutenção de cada projeto antes de instalar. “Gratuito” pode depender de serviços externos. Referência de pauta: Hallen Tech — youtube.com Qual ferramenta você vai testar primeiro? Deixe nos comentários e inscreva-se para conhecer mais recursos de IA. #InteligenciaArtificial #GitHub #OpenSource

159.894 sao — Xưởng tự làm app AI: Dify, kéo thả workflow thành chatbot! 159.894 ⭐ — Xưởng tự làm app AI: kéo thả workflow, nối tài liệu thành chatbot, đưa lên sản phẩm thật! Đây là AI Repository Show #8: Dify — nền tảng mã nguồn mở để tự làm app dùng mô hình ngôn ngữ lớn, không cần viết code từ đầu cho mỗi app. 📊 Số liệu kiểm chứng live từ GitHub ngày 29/10/2026: • Repo: langgenius/dify — langgenius/dify • 159.894 star · 25.254 fork · ngôn ngữ chính Python • Cập nhật mới nhất 29/10/2026 · 1.193 issue đang mở • Giấy phép: Dify Open Source License (dựa trên Apache 2.0, có điều kiện thêm) 🛠️ Dify có gì? • Workflow kéo thả trên canvas, không viết lại từ đầu • RAG pipeline: nạp PDF, slide… để AI trả lời theo tài liệu của bạn • Agent tự chạy trong sandbox, dùng skill, công cụ, MCP server, API riêng • Hỗ trợ hàng trăm mô hình: GPT, DeepSeek, mô hình chạy tại chỗ… • Mọi tính năng đều có API riêng để gắn vào sản phẩm ✅ Checklist 4 bước (lưu video này lại để copy): 1. Thử bản Cloud tại cloud.dify.ai, hoặc tự host bằng Docker: docker compose up -d 2. Chọn 1 việc nhỏ: chatbot hỏi đáp tài liệu 3. Kéo workflow, nối mô hình + tài liệu 4. Xuất API gắn vào sản phẩm của bạn ⚠️ Nói thẳng: đây là nền tảng, không phải app bấm 1 nút là xong — cần hiểu workflow và mô hình. Bản tự host cần máy chủ tối thiểu 2 nhân CPU / 4 GB RAM và tự lo cập nhật, bảo mật. Đọc kỹ giấy phép riêng của Dify trước khi dùng thương mại. 💬 Bạn muốn làm app AI nào đầu tiên với Dify — chatbot tài liệu, workflow tự động, hay agent đa công cụ? Comment từ khóa DIFY để nhận checklist nhé! Follow @aidailyvietnam — tối mai 21:45 lại có video mới! #AI #GitHub #AIRepositoryShow #Dify #AIApp #Workflow #RAG #Agent #AIDailyVietNam

Aus deinen Hilfeseiten wird ein KI-Support-Agent — kostenlos Aus deinen Hilfeseiten wird jetzt mit einem kostenlosen GitHub-Repo ein KI-Support-Agent. Es heißt Dify und hat über hundertfünfzigtausend Sterne. Du lädst die Anleitungen deiner Firma hoch, und die KI beantwortet damit die Fragen deiner Kunden. So antwortet sie aus deinen eigenen Texten, aus dem, was du längst geschrieben hast. Und du brauchst keinen Code, du baust das Ganze, indem du Kästchen auf dem Bildschirm verbindest. Du wählst sogar selbst, welches KI-Modell dahinter läuft, und testest alles, bevor ein Kunde es sieht. Die Community-Version läuft kostenlos auf deinem eigenen Server. So wird aus deinem Hilfebereich etwas, mit dem deine Kunden wirklich reden können. Der Link steht im angepinnten Kommentar. Die Links: Dify auf GitHub: langgenius/dify Dify: dify.ai Wissensdatenbank: dify.ai Workflow-Editor: dify.ai Mehr davon: ai2roi.de Abonnieren: youtube.com #dify #kiagent #kundensupport #opensource #kitools [en-US] Turn your help pages into an AI support agent — for free Your help pages can now be transformed into an AI support agent with a free GitHub repository. It's called Dify and has over 150,000 stars. You upload your company's manuals, and the AI ​​uses them to answer your customers' questions. It answers questions based on your own text, on what you've already written. And you don't need any code; you build it all by connecting boxes on the screen. You even choose which AI model runs behind it and test everything before a customer sees it. The community version runs for free on your own server. This turns your help section into something your customers can actually interact with. The link is in the pinned comment. ``` The links: Dify on GitHub: langgenius/dify Dify: dify.ai Knowledge Base: dify.ai Workflow Editor: dify.ai More from us: ai2roi.de Subscribe: youtube.com #dify #kiagent #customersupport #opensource #kitools

Dify-இல் chatbot, RAG, agent workflow எல்லாம் ஒரே இடத்தில் கிடைக்கிறது. Docker-இல் இயக்குங்கள். முதலில் எந்த app-ஐ உருவாக்குவீர்கள்? langgenius/dify Instagram-லும் பின்தொடருங்கள்: instagram.com

Huge props to @dify_ai for the insane architecture—taking agentic workflows and RAG from prototype to production seamlessly in one workspace is a massive game changer 🚀 🔗 项目地址：langgenius/dify

I Found a CRAZY AI Tool on GitHub That Builds AI Apps! 🤯 | Dify #Dify #AITools #GitHub #AIAgents #AI This GitHub Project Could Change How You Build AI Apps! | Dify Explained** What if you could build AI chatbots, intelligent assistants, and AI workflows without building everything from scratch? 🤯 Today on **What AI Cares**, we're exploring **Dify** — an open-source platform that helps developers build AI applications using visual workflows, language models, knowledge bases, and AI agents. 💡 **WHAT IS DIFY?** Dify is an open-source AI application development platform available on GitHub. It brings together tools for building and managing AI-powered applications, making it an interesting project for developers, students, startups, and AI enthusiasts. 🔥 **WHAT YOU'LL DISCOVER IN THIS VIDEO** ✅ What Dify is and how it works ✅ The Dify GitHub repository ✅ How visual AI workflows work ✅ How RAG helps AI answer questions using documents ✅ How to explore AI agents and AI chatbots ✅ Real-world ideas for AI projects and automation ✅ Why open-source AI projects are worth exploring 🛠️ **EXPLORE THE PROJECT** 🔗 Official Dify GitHub Repository: langgenius/dify 💭 **WHAT WOULD YOU BUILD WITH DIFY?** Would you create a personal AI assistant, a chatbot for a business, or an AI study assistant that answers questions from your notes? Tell us your idea in the comments! Subscribe to **What AI Cares** for more: 🤖 Latest AI tools and model updates 💻 Interesting GitHub repositories ⚡ AI agents and automation projects 🐍 AI coding tools and Python experiments 🚀 Open-source projects worth discovering