04_Dify 单独启动前端 Docker 容器

04_Dify 单独启动前端 Docker 容器

前言

本文介绍了在前后端分离开发场景下,部署Dify前端服务的两种Docker化方案。一是直接使用官方DockerHub镜像启动前端容器,支持最新版或指定版本,并配置后端API地址;二是通过源码本地构建自定义镜像后再启动。两种方法均通过环境变量配置控制台与应用的API连接,并提供了本地访问验证方式,适合后端开发者专注业务逻辑时快速启用前端界面。

一、直接使用 DockerHub 镜像

当单独开发后端时,可能只需要源码启动后端服务,而不需要本地构建前端代码并启动,因此可以直接通过拉取 docker 镜像并启动容器的方式来启动前端服务。

1.1 启动后端服务

查看教程:👉 Dify开源版使用源代码本地启动(一至五部分)

查看教程:👉 dify-plugin-daemon使用源码启动图文教程

1.2 使用 DockerHub 镜像启动前端 Docker 容器

获取最新版本

docker run -it -p 3000:3000 -e CONSOLE_API_URL=http://127.0.0.1:5001 -e APP_API_URL=http://127.0.0.1:5001 langgenius/dify-web:latest 

获取指定版本,搜索:
langgenius/dify-web Tags | Docker Hub

在这里插入图片描述
docker run -it -p 3000:3000 -e CONSOLE_API_URL=http://127.0.0.1:5001 -e APP_API_URL=http://127.0.0.1:5001 langgenius/dify-web:1.4.3 
在这里插入图片描述

二、使用源码构建 Docker 镜像

开发者首先需进入前端源码目录,使用docker build命令构建自定义镜像(例如命名为dify-web),随后再以类似方式运行容器。该方案同样提供了灵活的环境变量配置,并特别说明当控制台与应用的访问域名不一致时,可通过CONSOLE_URL和APP_URL变量分别进行设置。

2.1 构建前端镜像

cd web &&docker build . -t dify-web 

2.2 启动前端镜像

docker run -it -p 3000:3000 -e CONSOLE_API_URL=http://127.0.0.1:5001 -e APP_API_URL=http://127.0.0.1:5001 dify-web 

2.3 控制台域名设置

当控制台域名和 Web APP 域名不一致时,可单独设置 CONSOLE_URL 和 APP_URL

2.4 本地访问

访问地址:http://127.0.0.1:3000

在这里插入图片描述

登录成功:

在这里插入图片描述

三、总结

两种方案均将容器端口映射到主机的3000端口,启动后可通过访问 http://127.0.0.1:3000 来验证前端服务是否正常运行并登录。总而言之,第一种方案以极致的便捷性取胜,适合追求效率的标准开发流程;第二种方案则以构建的自主性和配置的灵活性见长。这两种互补的方案共同构成了一套实用工具箱,有效提升了Dify在前后端分离模式下的开发与部署效率。

Read more

Lada本地一键启动包:AI视频马赛克去除神器

Lada本地一键启动包:AI视频马赛克去除神器   咱就直说吧,网上那些特殊视频,最让人抓狂的就是关键地方总是打着马赛克。想看又看不清,那种感觉真的太折磨人了。我之前一直在找能去马赛克的工具,试了好多都不太行,直到我发现了这个神器——Lada。   这玩意儿到底能干啥? 简单来说呢,Lada就是一个基于AI的视频马赛克去除工具,专门用来恢复视频里那些被打了马赛克或者像素化的部分。不管是日本那种打码的,还是其他被处理过的视频,它都能帮你处理。 而且最关键的是,它是开源的,完全在你自己电脑上本地运行,没有任何限制。你懂的,这种私密视频肯定不能上传到什么在线平台处理,隐私问题太重要了。   我之前也试过一些在线工具,但这种视频谁敢随便上传啊?万一被保存下来或者泄露了,想想就后怕。用Lada就完全不同了,所有处理都在本地完成,你的小秘密只有你自己知道。处理完之后还能自动把音频合成回去,效果丝滑得很! 怎么用?超级简单 我实测了一下,真的是一键启动的那种简单。你看这个界面:   下载解压之后,双击启动命令就能跑起来了,完全不用折腾什么配置环境。导入你想处理

放弃无效编码!AI+SDD 重构复杂业务研发范式,新手也能落地

放弃无效编码!AI+SDD 重构复杂业务研发范式,新手也能落地

在当前复杂业务系统研发中,我们常陷入诸多困境:需求反复变更导致开发返工,AI辅助编程易出现幻觉生成无效代码,多人协作时重复开发浪费精力,上线后频繁出现回归bug,文档与代码脱节成为“无效资产”。这些问题的核心,是缺乏一套统一可落地的研发范式,让需求、设计、开发、测试全流程形成闭环,而规格驱动开发(SDD,Spec-Driven Development),正是解决这一痛点的关键。 很多开发者对SDD的认知停留在“先写文档再写代码”的表面,甚至觉得它是“额外负担”,尤其在工期紧张的复杂项目中,更倾向于跳过规格设计直接编码。但事实上,SDD并非传统意义上的“文档绑架”,而是结合AI时代研发特点,形成的一套高效可落地的工程化方法。 本文结合OpenSpec这一主流SDD工具,从实操层面拆解SDD在复杂业务系统中的落地全流程,解答工具使用、流程设计、痛点解决等关键问题,帮助每一位开发者真正用好SDD,提升复杂系统研发效率与质量。 核心概念明确 SDD中的Spec(Specification,规格),本质是对业务需求、技术设计、实现细节的标准化描述,是整个研发流程的“唯一真理来源”。与传统

2026年AI数字员工落地指南:企业级OpenClaw集群部署与资源调度优化

2026年AI数字员工落地指南:企业级OpenClaw集群部署与资源调度优化

开篇 2026年,AI数字员工已经彻底从概念验证阶段进入了规模化落地期。不管是金融行业的智能客服、合规审核,制造行业的产线数据巡检、自动化报表,还是互联网行业的内容审核、用户运营,越来越多的企业开始把AI数字员工纳入核心生产流程。根据2026年最新的《中国AI数字员工落地白皮书》,超过60%的中大型企业已经启动AI数字员工部署,但仅有不到20%的企业实现了全公司规模化推广,核心阻碍就是工程化落地能力不足——单节点能跑通demo,一到企业级规模化部署,就出现资源利用率低、高峰期响应超时、多部门权限混乱、运维成本居高不下的问题,最终导致项目停留在试点阶段。 作为连续主导了5家企业(3家离散制造、2家股份制银行)OpenClaw生产环境落地的架构师,我踩过了离线部署、多租户隔离、国产化适配、资源调度等几乎所有环节的坑,最终沉淀出了一套可复用的企业级落地方案。本文不会讲基础的单节点安装教程,只聚焦企业级落地的核心痛点:高可用集群架构设计、全流程离线部署、资源调度深度优化、生产环境避坑指南,所有内容均来自生产环境实测,无任何虚头巴脑的概念堆砌。 本文适用人群:企业IT架构师、DevOps工