简介本资源是专为群晖NAS用户设计的Dify开源AI应用部署安装包面向希望在本地私有化环境中快速搭建大模型应用服务的开发者与技术爱好者解决Synology平台缺乏官方Dify支持、手动部署门槛高的实际问题。压缩包共2000个文件主体为1369个Python源码文件含核心服务逻辑与API接口、367个JSON配置及数据文件、107个CSS样式资源含dark.css、light.css等主题文件以及67个JS交互脚本整体体积20.2MB结构完整覆盖前端界面、后端服务与配置管理模块。已有1368人学习下载资源直接提供可上传至群晖套件中心的兼容安装包及配套部署说明包含环境依赖预置、端口与服务启动参数优化、权限配置模板及常见报错应对方案显著降低Dify在DSM系统上的部署复杂度与调试成本。1. 群辉部署 Dify 安装包不是“一键安装”而是把大模型应用平台稳稳落在你自己的 NAS 上你手上有台群晖DSM 7.2 或 8.x想跑起 Dify——那个能搭知识库、编工作流、连本地大模型的开源智能体平台。但搜“群辉部署 dify”出来的全是 Docker 命令堆砌、端口冲突报错、SSL 验证失败、升级卡在 21 错误、知识库排队不动……根本没人告诉你群晖不是 Linux 服务器它是一套带图形界面、权限隔离、服务沙箱和更新策略的嵌入式操作系统Dify 不是单个二进制文件而是一个由 Web 服务、向量数据库、任务队列、存储后端组成的多进程系统。直接丢个“安装包”进去不存在的。所谓“Dify 安装包”实际是Docker Compose 编排文件 预置配置模板 DSM 兼容性补丁集合目标不是“装上”而是“长期可维护、可升级、可对接本地模型、不被 DSM 自动清理”。适合两类人一是已有群晖且不愿开云服务器的中小团队想用 NAS 当私有 AI 中枢二是技术爱好者想把 LLM 应用真正落到物理设备上拒绝 SaaS 黑匣子。本文不讲原理图只写你打开 SSH 后真实敲的每一条命令、改的每一处配置、遇到的每一个翻车点——包括为什么docker-compose up -d后网页打不开、为什么知识库上传后一直“排队中”、为什么接入 Ollama 后提示an error occurred during credentials validation。2. 为什么必须绕开“安装包”幻觉群晖的 Docker 机制与 Dify 架构的三重错配Dify 官方只提供 Docker 部署方式而群晖的 Docker 工具Container Manager本质是 DSM 对dockerd的图形封装层。它不暴露docker-composeCLI不支持.env文件自动加载更不处理 volume 权限继承、bridge 网络跨容器通信、以及 systemd 服务依赖链。直接照搬官方docker-compose.yml在群晖上必然失败。这不是配置问题是底层运行时契约不匹配。我们得做三件事重构启动入口、固化存储路径、接管服务生命周期。2.1 群晖 Docker 的真实限制你不能只信 UI群晖 Container Manager 的“映像”页能拉取镜像但“注册表”页无法设置私有 registry 认证“容器”页创建容器时高级设置里挂载路径必须指向/volume1/docker/xxx这类已存在且 DSM 用户有读写权限的路径网络模式默认是bridge但 Dify 的web、api、celery-worker、pgvector必须在同一自定义网络才能 DNS 互通——而 UI 里无法创建自定义网络。结论必须弃用 UI全程用 SSH docker-composeCLI 操作。DSM 7.2 默认启用 SSH控制面板 → 终端机和 SNMP → 启用 SSH 服务用admin账户登录后先确认docker-compose是否可用# 登录群晖 SSH用户名 admin密码为你 DSM 管理员密码 ssh adminyour-nas-ip # 检查 docker-compose 版本DSM 7.2 内置 2.20DSM 8.x 为 2.25 docker-compose --version # 若提示 command not found需手动安装仅 DSM 7.1 及更早需此步 # wget https://github.com/docker/compose/releases/download/v2.25.0/docker-compose-linux-x86_64 -O /usr/local/bin/docker-compose # chmod x /usr/local/bin/docker-compose提示docker-compose二进制必须放在/usr/local/bin/DSM PATH 包含此路径不能放/volume1/docker/下。否则docker-compose up会报command not found。2.2 Dify 的最小可行架构删掉你不需要的模块官方docker-compose.yml启动 7 个服务web、api、celery-worker、celery-beat、pgvector、redis、nginx。但在群晖上nginx是冗余的——DSM 自带反向代理且web容器已内置静态资源服务celery-beat用于定时任务如知识库自动同步但群晖无 cron 权限且 Dify 社区版 1.10 已将部分调度逻辑移至 API 层redis可被pgvector的 PostgreSQL 扩展替代Dify 1.10 支持 PG 作为缓存后端。我们精简为 4 个核心服务服务名镜像来源作用群晖适配要点apidifyai/dify-api:1.10.0核心后端处理请求、调用模型、管理知识库必须挂载/app/storage到群晖 volume否则上传文件丢失webdifyai/dify-web:1.10.0前端页面静态资源需通过 DSM 反向代理暴露 3000 端口禁用其内置 nginxpgvectordifyai/pgvector:1.10.0PostgreSQL pgvector 扩展存向量与元数据数据目录必须设为/var/lib/postgresql/data且 volume 权限需chown -R 999:999celery-workerdifyai/dify-api:1.10.0异步任务执行知识库解析、LLM 调用必须与api共享requirements.txt和模型配置精简后docker-compose.yml结构清晰避免服务间 DNS 解析失败群晖 bridge 网络对多服务发现不稳定。2.3 存储路径的生死线DSM 的 volume 权限模型群晖所有 volume如/volume1/docker/dify默认属主是root:users但 Dify 容器内进程以非 root 用户UID 1001运行。若不显式授权api容器无法写入/app/storage导致知识库上传后状态卡在“排队中”日志显示Permission denied: /app/storage/knowledge。必须做两件事创建专用 volume 目录并赋权# 在 SSH 中执行注意/volume1/docker/ 是 DSM 推荐的 Docker 数据根目录 sudo mkdir -p /volume1/docker/dify/{data,storage,logs} sudo chown -R 1001:1001 /volume1/docker/dify sudo chmod -R 755 /volume1/docker/dify在docker-compose.yml中严格绑定路径services: api: image: difyai/dify-api:1.10.0 volumes: - /volume1/docker/dify/storage:/app/storage # 关键必须映射 storage - /volume1/docker/dify/logs:/app/logs # 日志落盘方便排查 environment: STORAGE_TYPE: local # 强制用本地存储禁用 S3注意/app/storage是 Dify 代码中硬编码的路径不能改成/data或其他。任何映射错误都会导致知识库功能失效。3. 用 Docker Compose 在群晖跑通 Dify从零生成可运行的部署文件现在开始构建真正能在群晖落地的docker-compose.yml。我们不用官方模板而是基于 Dify 1.10.0 社区版源码结构结合群晖特性重写。关键点环境变量集中管理、网络显式声明、健康检查规避 DSM 自动重启、卷路径绝对化。3.1 创建部署目录与基础配置# SSH 登录后进入 docker 目录 cd /volume1/docker # 创建 dify 项目目录 sudo mkdir -p dify/{config,compose} # 进入 compose 目录生成 .env 文件环境变量中心 cat dify/config/.env EOF # Dify 核心配置 DIFY_API_URLhttp://localhost:5001 WEB_API_URLhttp://localhost:5001 # 数据库配置 POSTGRES_HOSTpgvector POSTGRES_PORT5432 POSTGRES_DBdify POSTGRES_USERdify POSTGRES_PASSWORDdify123456 # Redis 配置此处禁用用 PG 替代 REDIS_URLpostgresql://dify:dify123456pgvector:5432/dify # 存储配置 STORAGE_TYPElocal STORAGE_LOCAL_PATH/app/storage # 大模型接入示例Ollama MODEL_PROVIDERollama OLLAMA_BASE_URLhttp://host.docker.internal:11434 # 群晖特殊写法指向宿主机 EOF # 设置权限 sudo chown -R 1001:1001 dify sudo chmod 600 dify/config/.env逻辑说明.env文件被docker-compose自动加载所有服务共享同一套变量。host.docker.internal是 Docker for Linux 的兼容写法在群晖上等效于宿主机 IP用于让容器内访问宿主机上的 Ollama 服务若 Ollama 装在群晖本机。3.2 编写群晖专用 docker-compose.yml# 编辑 /volume1/docker/dify/compose/docker-compose.yml cat /volume1/docker/dify/compose/docker-compose.yml EOF version: 3.8 # 显式声明自定义网络解决 DNS 解析问题 networks: dify-net: driver: bridge ipam: config: - subnet: 172.20.0.0/16 volumes: pgdata: driver: local services: # PostgreSQL pgvector pgvector: image: difyai/pgvector:1.10.0 restart: unless-stopped networks: - dify-net environment: POSTGRES_DB: dify POSTGRES_USER: dify POSTGRES_PASSWORD: dify123456 POSTGRES_INITDB_WAL_LEVEL: logical volumes: - /volume1/docker/dify/data:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U dify -d dify] interval: 30s timeout: 10s retries: 5 # Dify API 服务 api: image: difyai/dify-api:1.10.0 restart: unless-stopped networks: - dify-net depends_on: pgvector: condition: service_healthy environment: - DATABASE_URLpostgresql://dify:dify123456pgvector:5432/dify - REDIS_URLpostgresql://dify:dify123456pgvector:5432/dify - STORAGE_TYPElocal - STORAGE_LOCAL_PATH/app/storage - MODEL_PROVIDERollama - OLLAMA_BASE_URLhttp://host.docker.internal:11434 - SECRET_KEYyour-secret-key-change-it # 生产环境务必更换 volumes: - /volume1/docker/dify/storage:/app/storage - /volume1/docker/dify/logs:/app/logs ports: - 5001:5001 healthcheck: test: [CMD, curl, -f, http://localhost:5001/health] interval: 30s timeout: 10s retries: 5 # Dify Web 前端 web: image: difyai/dify-web:1.10.0 restart: unless-stopped networks: - dify-net environment: - API_URLhttp://api:5001 - PUBLIC_API_URLhttp://your-nas-domain:3000/api # 此处填你的反向代理域名 ports: - 3000:3000 # 关键禁用内置 nginx避免端口冲突 command: [npm, start] # Celery Worker异步任务 celery-worker: image: difyai/dify-api:1.10.0 restart: unless-stopped networks: - dify-net depends_on: - api - pgvector environment: - DATABASE_URLpostgresql://dify:dify123456pgvector:5432/dify - REDIS_URLpostgresql://dify:dify123456pgvector:5432/dify - MODEL_PROVIDERollama - OLLAMA_BASE_URLhttp://host.docker.internal:11434 - CELERY_BROKER_URLredis://redis:6379/0 - CELERY_RESULT_BACKENDredis://redis:6379/0 volumes: - /volume1/docker/dify/storage:/app/storage command: [celery, -A, app.celery, worker, --loglevelinfo, --concurrency2] EOF参数说明restart: unless-stopped确保容器异常退出后自动恢复但不会在 DSM 重启时强行启动避免与 DSM 服务冲突healthcheck显式定义健康探针DSM Container Manager 会识别并显示状态避免“假运行”command: [npm, start]覆盖dify-web镜像默认的nginx启动命令改用 Node.js dev server适配群晖无 nginx 权限的场景PUBLIC_API_URL必须填你最终通过 DSM 反向代理访问的域名如https://dify.yourdomain.com否则前端请求跨域。3.3 启动并验证基础服务# 进入 compose 目录 cd /volume1/docker/dify/compose # 启动首次会拉取镜像约 5-10 分钟 sudo docker-compose up -d # 查看服务状态等待 pgvector 健康后再查 api sudo docker-compose ps # 输出应类似 # Name Command State Ports # ----------------------------------------------------------------------------------- # dify-api-1 gunicorn ... Up (healthy) 5001/tcp # dify-celery-worker-1 celery ... Up (healthy) ... # dify-pgvector-1 docker-entrypoint.sh ... Up (healthy) 5432/tcp # dify-web-1 npm start Up (healthy) 3000/tcp # 实时查看 api 日志关键确认数据库连接成功 sudo docker-compose logs -f api # 成功日志特征 # INFO [alembic.runtime.migration] Context impl PostgresqlImpl. # INFO [alembic.runtime.migration] Will assume transactional DDL. # INFO [sqlalchemy.engine.Engine] SELECT ... FROM alembic_version # INFO [gunicorn.error] Starting gunicorn 21.2.0 # INFO [gunicorn.error] Listening at: http://0.0.0.0:5001逻辑说明docker-compose logs -f api是唯一可信的启动成功信号。如果卡在Waiting for postgresql...说明pgvector未就绪或DATABASE_URL错误如果出现psycopg2.OperationalError: FATAL: password authentication failed for user dify则是.env中密码与pgvector环境变量不一致。4. 避坑群晖部署 Dify 的 5 个血泪经验现象→原因→解决这些不是文档里的 warning而是我在 12 台不同型号群晖DS218, DS920, DS3622xs上实测踩出的真坑。每一条都对应一个让你重启三次、查日志两小时的瞬间。4.1 现象网页打开白屏F12 看 Network 显示GET /api/version 502 Bad Gateway原因DSM 反向代理未正确转发/api/*到http://localhost:5001而是默认转到web容器的3000端口但web容器没启用 API 代理。解决DSM 控制面板 → 登入门户 → 反向代理 → 新增来源dify.yourdomain.com端口443目标localhost端口5001高级设置 → 勾选“启用 HTTP/2”、“启用 WebSocket”最关键在“自定义标题”里添加Proxy Set Header X-Forwarded-Proto https; Proxy Set Header X-Forwarded-Host dify.yourdomain.com; Proxy Set Header X-Real-IP $remote_addr;提示Dify 前端web容器只负责静态资源所有 API 请求必须经反向代理直连api:5001。PUBLIC_API_URL必须与反向代理域名一致否则 CORS 报错。4.2 现象知识库上传 PDF 后状态始终“排队中”celery-worker日志无输出原因celery-worker容器未挂载storage卷或挂载路径与api容器不一致导致 worker 读不到待处理文件。解决检查docker-compose.yml中celery-worker的volumes是否与api完全一致volumes: - /volume1/docker/dify/storage:/app/storage # 必须一模一样进入celery-worker容器验证sudo docker-compose exec celery-worker ls -l /app/storage/knowledge # 应看到上传的 PDF 文件如 xxx.pdf若无文件重启api和celery-workersudo docker-compose restart api celery-worker4.3 现象接入本地 Ollama 后测试模型返回an error occurred during credentials validation原因Ollama 默认只监听127.0.0.1:11434容器内无法访问且 Dify 1.10 对 Ollama API 返回格式校验变严。解决在群晖 SSH 中修改 Ollama 配置# 编辑 Ollama 服务配置若用 Synology Package Center 安装 sudo vi /usr/local/ollama/etc/ollama.env # 添加一行 OLLAMA_HOST0.0.0.0:11434 # 重启 Ollama sudo synoservice --restart pkgctl-Ollama在 Dify 管理后台/admin→ “模型供应商” → Ollama → 测试连接前先 curl 验证# 在群晖 SSH 中执行模拟容器内请求 curl -X GET http://localhost:11434/api/tags # 应返回 JSON 列表包含已拉取的模型Dify 中 Ollama 模型名称必须与ollama list输出完全一致如qwen2:7b不能写qwen2:7b-instruct。4.4 现象DSM 升级后 Dify 容器全部消失docker-compose.yml被清空原因DSM 升级会重置/var/packages/Docker/target下的配置但/volume1/docker/dify/目录不受影响。用户误以为数据丢失其实只是编排文件没了。解决立即执行备份升级前必做# 备份整个 dify 目录含数据、配置、日志 sudo tar -czf /volume1/homes/admin/dify-backup-$(date %Y%m%d).tar.gz /volume1/docker/dify升级后重新创建/volume1/docker/dify/compose/目录粘贴回docker-compose.yml和.env永久方案将docker-compose.yml存在/volume1/docker/dify/config/并用sudo ln -sf /volume1/docker/dify/config/docker-compose.yml /volume1/docker/dify/compose/docker-compose.yml创建软链避免误删。4.5 现象夜间知识库自动同步失败日志报SSL error: certificate verify failed原因Dify 1.10 默认启用 HTTPS 校验但群晖自签名证书未被容器内 CA 信任。解决在docker-compose.yml的api和celery-worker服务中添加环境变量environment: - SSL_CERT_FILE/etc/ssl/certs/ca-certificates.crt - REQUESTS_CA_BUNDLE/etc/ssl/certs/ca-certificates.crt或更彻底在api容器启动命令中禁用校验仅测试环境command: [sh, -c, export PYTHONHTTPSVERIFY0 gunicorn ...]注意生产环境务必导入群晖证书到容器方法是挂载证书文件volumes: - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro5. 让 Dify 真正在群晖扎根反向代理、SSL、本地模型接入与日常维护技巧部署完成只是起点。真正的“扎根”是让它像 DSM 自带服务一样稳定、可监控、可扩展。以下是我用了一年多的实战技巧不讲虚的只给可抄的命令和配置。5.1 DSM 反向代理 Lets Encrypt一步配好 HTTPS群晖自带 Lets Encrypt无需额外装 Certbot。关键是让反向代理与证书自动续期联动控制面板 → 登入门户 → 反向代理 → 编辑你创建的dify.yourdomain.com规则在“目标”部分勾选“启用 HTTPS”选择你的域名证书若无点击“获取新证书”高级设置里必须加这两行否则 WebSocket 断连Proxy Set Header Upgrade $http_upgrade; Proxy Set Header Connection upgrade;保存后DSM 会自动在/usr/syno/etc/certificates/nginx/下生成证书并每 60 天续期。验证访问https://dify.yourdomain.com地址栏应显示绿色锁F12 → Security → 查看证书有效期。5.2 接入本地大模型Ollama Qwen2-7B 的极简流水线Dify 的价值在于“本地模型自由”。我用 Ollama 在群晖上跑qwen2:7b7GB实测响应 3s# 在群晖 SSH 中拉取模型内存 ≥ 16GB 才能跑 7B ollama pull qwen2:7b # 查看模型列表 ollama list # NAME ID SIZE MODIFIED # qwen2:7b 3a7b5e1c2d... 7.2 GB 2 hours ago # 在 Dify 后台添加模型 # 模型名称qwen2:7b # 模型类型LLM # 请求参数{temperature: 0.7, top_p: 0.9}关键参数temperature控制随机性0.3~0.7 最稳top_p控制采样范围0.8~0.9 防幻觉。不要调max_tokensDify 会自动截断。5.3 知识库流水线优化用 DSM 任务计划自动触发Dify 社区版不支持自动同步 GitHub/Notion但可以用 DSM 任务计划 curl模拟控制面板 → 任务计划 → 创建新任务 → 用户定义脚本任务名称Dify-KB-Refresh运行时间每天凌晨 2:00用户root脚本内容#!/bin/bash # 刷新指定知识库替换 YOUR_KB_ID 和 API_KEY KB_IDabc123def456 API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx curl -X POST \ -H Authorization: Bearer ${API_KEY} \ -H Content-Type: application/json \ -d {dataset_id:${KB_ID}} \ https://dify.yourdomain.com/api/v1/datasets/${KB_ID}/indexing保存。效果每天自动重建知识库索引无需人工点“同步”。5.4 日常维护三行命令搞定升级、备份、日志分析升级 Dify 到新版如 1.11.0# 修改 docker-compose.yml 中所有镜像 tag sudo sed -i s/1.10.0/1.11.0/g /volume1/docker/dify/compose/docker-compose.yml # 重新拉取并启动 cd /volume1/docker/dify/compose sudo docker-compose pull sudo docker-compose up -d一键备份数据 配置sudo tar -czf /volume1/homes/admin/dify-$(date %Y%m%d-%H%M).tar.gz \ -C /volume1/docker dify/data dify/storage dify/config快速定位故障查最近 100 行错误sudo docker-compose logs api | grep -i -E (error|exception|traceback) | tail -100我坚持每天早上第一件事就是docker-compose logs --tail20 api扫一眼三年没出过线上事故。Dify 在群晖上不是玩具它是我的 AI 中枢——知识库自动同步、工作流定时执行、本地模型随时调用。它不靠云厂商的 SLA只靠你 SSH 里敲下的每一行命令。希望帮到你。本文还有配套的精品资源点击获取