AI随心创
先说结论
在新测试目录下载Dify 1.19.0，准备Docker Compose 2.35.0或更新版本，复制.env模板并生成本地沙箱共享令牌；用独立覆盖文件把Nginx发布端口替换为127.0.0.1:18080:80，再用同一项目名和两份Compose文件校验、启动，在http://127.0.0.1:18080/install初始化管理员。本站已在Compose v5.1.0解析官方配置并验证端口覆盖，未拉镜像或启动Dify，登录和模型调用未实测。自托管仍有机器、维护及模型调用成本；调用外部模型时，数据仍可能出站。
读完你会得到
- 固定发布标签，区分docker/.env与服务级配置。
- 用回环端口覆盖文件做本机实验，并保留相同启动参数。
- 分别验证容器状态、管理员页面与模型调用，不把一种成功当成全部成功。
已经用Dify搭过工作流，准备放到自己的测试机上，第一步需要弄清楚下载哪个版本、哪些配置必须填，以及浏览器该打开哪个地址。这篇按1.19.0给出一条从配置到验证的路径，先做本机实验，不直接开放给团队。
这次搭建什么，先准备哪些条件
本文面向能使用Linux Bash终端的读者，目标是在新测试目录搭建单机Dify，并从本机浏览器验证。它不包含生产域名、团队登录、可用性保障或完整升级方案。已有实例请使用官方Upgrade流程，不要覆盖原.env、令牌和数据。
2026年11月12日核对GitHub官方发布API：当前非预发布版本为1.19.0，发布于11月4日。这里固定这个标签；后续读者选择其他版本时，要重新读对应说明，不把本文配置直接套到旧版。
| 项目 | 条件或命令 |
|---|---|
| 系统与工具 | Linux测试机；Git、Python 3、Docker Engine；Docker daemon已运行 |
| CPU与内存 | 官方最低2核CPU、4 GiB内存；这是基础门槛，不是并发、知识库规模或模型性能承诺 |
| Compose | docker compose version；至少2.35.0。不要使用旧的docker-compose命令代替 |
| 网络与空间 | 可访问GitHub、所需镜像仓库与后续模型服务；为镜像、数据和日志留出空间 |
| 数据 | 先用虚构资料；本次没有安装本地大模型，也不需要GPU才能完成平台配置检查 |
看图理解这次实验的四个阶段
本节依据： [1] Dify Docs
第一步：固定版本，创建新的测试目录
git clone --branch 1.19.0 --depth 1 https://github.com/langgenius/dify.git dify-1.19.0-lab
cd dify-1.19.0-lab/docker
git describe --tags --exact-match
docker compose version
cp .env.example .env在没有同名目录的位置执行。若目录已存在，先确认是不是已有部署，不继续覆盖。git describe的预期标签是1.19.0；Compose版本需满足最低要求。下面的命令都在这个docker目录执行。
默认栈自带数据库、向量库等配套组件，不需要先另外安装一套PostgreSQL或Weaviate。首次启动前若改用其他存储，要按官方配置补齐连接条件；运行后改变DB_TYPE或VECTOR_STORE不会自动迁移数据。
第二步：配置本地沙箱共享令牌
1.19.0的docker/.env.example中，本地沙箱认证令牌留空。首次启动前设置DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN，它供Agent后端与本地沙箱之间认证使用，与后面连接模型的供应商API密钥不同。
下面用Python的secrets生成32字节随机值并写入刚创建的.env，不把令牌打印到终端。只在新建测试目录首次执行，不在已有实例中反复更换。官方也提供openssl rand -hex 32后手动填写的方法。
python3 - <<'PY'
from pathlib import Path
import secrets
p = Path('.env')
key = 'DIFY_AGENT_LOCAL_SANDBOX_AUTH_TOKEN='
lines = p.read_text().splitlines()
assert sum(line.startswith(key) for line in lines) == 1
lines = [key + secrets.token_hex(32) if line.startswith(key) else line for line in lines]
p.write_text('\n'.join(lines) + '\n')
PY把.env视为私密配置，不上传到公开仓库或问题截图。根目录.env承担部署级输入及覆盖值；服务默认配置在envs/下，日后定制应按对应.defaults文件的说明创建本地.env，不需要为了这次实验修改所有默认文件。
第三步：把访问入口限制在本机
官方默认Compose会发布HTTP和HTTPS宿主端口。为了这次本机实验，另外创建compose.local.yaml，替换nginx的ports，并取消插件调试端口的宿主发布。!override会替换原列表；如果只是再加一条端口，原先的发布端口可能仍然存在。此语法要求Compose 2.24.4或以上，本文采用的最低2.35.0也满足。
cat > compose.local.yaml <<'YAML'
services:
nginx:
ports: !override
- "127.0.0.1:18080:80"
plugin_daemon:
ports: !override []
YAML这份覆盖文件属于本站教学设置，不是Dify默认配置。固定版本的plugin_daemon默认还会发布宿主5003端口，本例取消这条发布，不开展远程插件开发；容器内部服务连接保留。127.0.0.1只允许部署机器本地访问18080；不要把它改成0.0.0.0后就直接用于生产。后续所有Compose操作都带同一项目名和两份文件，避免启动出另一套服务或丢失端口覆盖。
docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml config --quiet成功时该命令通常不输出正文。它验证配置能解析，不证明镜像已可下载、容器健康或应用可用。config完整输出可能包含解析后的凭据，不要整份粘贴到聊天或日志。
本节依据： [3] Docker Docs [1] Dify Docs
第四步：启动后，先分清运行服务与一次性任务
docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml up -d
docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml ps --all首次启动要拉取多个镜像，等待时间取决于网络和机器。不要因为页面暂时没打开就反复创建新目录或换项目名。长时间运行的服务应显示Up或healthy；init_permissions是一次性的权限初始化任务，Exited (0)属于正常完成，不能把所有Exited一律判成失败。
先检查nginx、web、api以及配套服务的状态；容器Up只说明进程在运行，不能替代下面的页面和业务验证。如果启动失败，保存失败服务名、当前标签与去掉敏感值的错误摘要。
本节依据： [1] Dify Docs
第五步：打开安装页，再接通一条模型请求
部署机器上的浏览器打开http://127.0.0.1:18080/install，创建管理员账号后，再访问http://127.0.0.1:18080登录。若机器是远程Linux服务器，回环端口不会直接对你的电脑开放；可在自己的电脑建立SSH转发，再访问自己电脑的同一地址。
ssh -L 18080:127.0.0.1:18080 your-user@your-server将your-user@your-server换成你有权限访问的服务器账号和地址，转发终端保持打开；若本地18080已占用，可以将-L左侧端口改为另一个空闲端口，并相应修改浏览器地址。这是临时个人测试通道，不是团队公开访问方案。
登录后，由工作区所有者或管理员在Integrations / Model Provider安装供应商，添加相应凭证。模型供应商账户会直接产生调用费用；只在平台界面填写密钥，不把密钥写在提示词里。若使用本地模型，要另外准备模型服务及从容器可达的端点，本文没有替你安装它。
先创建一个最小文本应用，选择已配置的模型，用“只回复：连接检查通过”做无业务资料的连通性测试，确认运行记录中有实际响应。这个提示只是教学输入，不能用它判断知识库答案正确或业务质量。需要完整业务练习时，再按下方Dify工作流教程操作。
本节依据： [1] Dify Docs [4] Dify Docs
三层验证分别留下什么结果
| 层次 | 动作 | 能证明什么 |
|---|---|---|
| 配置层 | docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml config --quiet | Compose配置可解析；没有实际部署结论 |
| 服务层 | docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml ps --all；打开/install与登录页 | 进程和页面可访问；不证明模型连接或任务正确 |
| 应用层 | 运行一条虚构文本请求，记录所选模型、时间和响应 | 只证明该次路径完成；不外推其他模型、文件或并发负载 |
本站验证范围：从官方1.19.0标签下载38个Compose及环境默认文件，在本地Docker Compose v5.1.0执行config --format json，解析得到16个服务；逐一检查所有服务的宿主发布端口，只有nginx的127.0.0.1:18080到容器80这一条，插件调试端口已取消。测试配置用全零教学令牌，没有真实凭证。
这不是完整部署实测。本站未执行pull或up，未启动容器、初始化管理员、调用模型，也没有测量资源、速度或恢复能力。读者需要在自己的隔离测试环境完成上述服务层和应用层验证。
本节依据： [1] Dify Docs [3] Docker Docs
卡在哪一步，就检查哪一层
| 现象 | 检查 | 处理方向 |
|---|---|---|
| !override或env_file解析失败 | Compose版本和两份文件路径 | 确认至少2.35.0；不要删除覆盖规则后直接开放默认端口 |
| 本地沙箱相关服务起不来 | 新目录.env中的令牌是否仍为空 | 按本节首次配置步骤设置；已有实例先确认原令牌与依赖 |
| 18080打不开 | ps状态、端口占用、覆盖文件是否参与启动 | 本机看127.0.0.1；远程机器另建SSH转发，不直接改公网监听 |
| init_permissions显示Exited (0) | 退出码是否为0 | 这是一项正常完成的一次性任务 |
| 修改.env后没有变化 | 是否只运行了restart | 使用同一组参数up -d重建受影响容器；restart不替换旧环境 |
| 无法拉镜像或安装供应商插件 | 目标仓库、网络、代理和DNS | 先保存失败目标与错误，不把来源不明的镜像当成修复 |
| 页面可开，模型请求失败 | 供应商凭证、额度、端点与容器网络 | 把平台可访问与模型可用分开排查 |
| 误以为本地部署就不会出站 | 所选模型、嵌入及重排端点 | 外部服务仍会收到相应输入，先用虚构资料测试 |
本节依据： [1] Dify Docs [4] Dify Docs
保留实验结果，进入团队试点前再补哪些工作
暂时不用时，可以按同样的项目和文件参数停止容器；持久化数据仍需妥善保管。不要为了重来就执行带-v的down或删除volumes目录，那会影响持久数据。本文不提供清库操作。
docker compose -p dify-local-lab -f docker-compose.yaml -f compose.local.yaml stop团队可访问之前，要按官方Secure the Deployment要求设置HTTPS和替换开发凭据，逐项核对数据库、Redis、代码沙箱、向量库、插件及Agent相关共享密钥；已初始化数据库不能只改.env中的密码。不要用一个默认口令代替所有服务的认证设计。
备份不仅是导出应用配置，还包括数据库、上传文件、向量数据、部署配置及本地沙箱命名卷；先按官方方法制作一致备份并演练恢复。升级时保留既有项目名、数据和配置，阅读目标版本升级说明，不重新复制模板覆盖旧.env。
自托管主要改变运行环境与维护责任，模型是否本地处理要单独核对。机器、存储、网络、模型调用、补丁和维护时间都纳入预算，本篇没有给出生产容量或费用承诺。
接下来用什么任务验证这台实例
相关文章：用Dify询问分流教程检查输入、分支、输出与API；需要知识问答时再做知识库导入与检索练习。选云服务还是自托管，可继续读部署数据流与留存边界，或从企业AI与FDE实施导航选择后续阶段。
服务沟通：本站提供企业AI咨询与FDE落地服务。可以带上测试版本、环境条件、脱敏任务和允许出站范围，讨论如何把单机练习转成可维护的业务试点；本文不是客户案例。
常见问题
本机部署Dify之后，还要付模型费吗？
如果连接外部付费模型，调用通常按供应商账户计费。自托管平台不等于免费推理，机器与维护也需要成本。本文不承诺任何免费额度。
为什么不用main分支直接安装？
本文固定1.19.0便于对照同一套配置与发行说明。持续更新文档和main可能变化，换版本要重新核对配置。
为什么服务器IP加18080打不开？
本文明确绑定127.0.0.1，只供部署机器本地访问。远程个人测试可以使用SSH转发；团队访问需要另行配置认证、HTTPS与访问边界。
资料来源与核对说明
文章中的行业定义与技术方法尽量引用官方或标准组织资料；表格、清单和决策框架是基于这些资料形成的编辑性整理，不代表来源机构对本站服务的背书。
- Deploy Dify with Docker ComposeDify Docs
2026-11-12核验持续更新文档；未标明首次发布日期，不推测。核对最低资源、Compose版本、沙箱令牌、初始化、环境覆盖、持久化与升级；本篇本机端口方案为本站教学设置。
- Dify 1.19.0 release and fixed deployment fileslanggenius/dify
官方API显示发布日期2026-11-04T07:36:16Z；2026-11-12核验为非预发布。按1.19.0标签读取docker配置和默认文件，并做本地Compose配置解析；不把发行说明当作产品实测。
- Merge Compose files — Replace valueDocker Docs
2026-11-12核验；原始发布日期未标明。!override替换列表要求Compose2.24.4及以上。本站以Dify要求的2.35.0为最低版本，并在v5.1.0本地验证回环端口覆盖。
- Model ProvidersDify Docs
2026-11-12核验；原始发布日期未标明。核对Integrations/Model Provider、管理员权限、供应商凭证与直接计费；未调用真实模型。
带上流程、样例和目标，添加企业微信沟通。先确定项目范围与验收方式，再安排实施。
