我最近在帮团队选设计协作工具翻开源社区的时候撞见一个叫Lovart的设计平台。第一眼看到项目名的时候我其实没太当回事以为又是某个套壳的矢量编辑器结果认真扒了一遍仓库里的文档又花了一个周末把它部署到本地服务器上发现这东西确实有点东西。它的定位一句话就能说清一个可以完全部署在自己服务器上的开源设计平台设计文件、团队协作数据、上传的资源全部由你自己掌控。如果你和我一样烦透了SaaS按人头收费、担心设计数据放在别人的云上、或者想给团队搭一个离线也能用的设计工作区那这篇内容值得你耐心读完。我写这篇文章不打算做成那种“入门教程”式的流水账而是想站在一个真正用过、踩过坑、并且还在继续用的人的视角把Lovart 本地部署这件事讲透为什么值得这样做、部署前要想清楚什么、实操的时候有什么坑、日常维护该备份哪些东西。看完之后你不需要再全网搜零碎的部署笔记直接照着做就能跑起来。1. Lovart到底是什么一个可以私有化的设计协作空间1.1 为什么我会盯上自托管设计工具先别急着聊技术聊聊需求。过去几年我用过不少在线设计协作产品界面漂亮、协作流畅这些我都承认。但有两个点一直让我不舒服一是数据不在自己手里公司内部的设计稿、未发布的品牌素材、客户敏感资料全都存在别人的服务器上哪怕合同里写着隐私保护心里还是没底二是价格问题团队稍微大一点按坐席收费的年费数字就很可观了而且免费版往往限制项目数量和协作者人数。后来我开始关注自托管方向。所谓自托管就是把这个软件装到自己的服务器或者内网机器上数据完全由自己管理。开源社区里这类工具不少但很多要么功能太轻、只适合画个流程图要么部署起来极其折腾依赖一堆中间件。直到我看到Lovart的仓库才觉得“哦这才是能正经干活的东西”。1.2 Lovart的定位和核心能力从项目文档和对实际部署版本的体验来看Lovart 不是一个简单的画板工具而是一个完整的设计工作区。它面向的使用场景主要是 UI 设计、平面排版、原型草图这一类工作交互模型也是经典的设计软件思维画板、图层、组件、样式系统用起来对从 Figma、Sketch 转过来的人非常友好。我比较看重的几个点包括多人实时协作同一个设计文件可以让团队成员同时编辑每个人的光标和选中状态是实时可见的这点和主流在线设计工具体验接近。自建组件库按钮、图标、颜色变量这些可以做成团队级别的组件项目之间共享改一个地方所有引用同步更新。资源管理上传的图片、图标、字体包统一管理画板里直接拖拽引用。导出能力支持常见的设计稿导出和代码层面的切图标注前端拿到设计稿能直接对接开发。当然作为一个开源项目它不会像商业产品一样把所有功能都做到极致但核心设计链路是完整闭环的。如果你需要的只是一块“能放设计稿的地方”用它完全足够。1.3 本地部署到底解决了什么问题把 Lovart 装到自己服务器上之后收益非常直接第一是数据主权。所有设计文件、项目管理记录、账号信息都存在你的数据库里没有第三方参与。对需要保密的设计项目来说这一点是刚需。第二是成本可控。开源版本的软件本身不收费你只需要付服务器费用。小团队用一台 4 核 8G 的机器就能撑起日常使用比按人头买订阅划算太多。第三是离线可用。公网断掉、云服务商出问题的时候内网里的 Lovart 依然能正常打开、正常编辑。对一个依赖设计工具出图的团队来说这种稳定性很宝贵。第四是可以二次开发。这是开源最大的优势。你觉得某个交互不合理、某个导出格式不够用可以直接改代码也可以提需求让社区帮忙。商业工具永远不可能为你单独改逻辑。1.4 它适合谁根据我自己的观察这几类人和团队会比较受益独立设计师或小型工作室想省掉订阅费企业内部的设计/品牌部门需要数据私有化高校或培训机构想给学员搭一套实际可用的设计协作环境以及那些对开源有研究兴趣想看看一个现代 Web 设计工具内部结构的人。当然它不适合完全不熟悉服务器的纯新手。你不需要是运维专家但至少要有基本的 Linux 命令行操作能力和一点点 Docker 概念。下面我也会把部署过程写得很浅跟着走问题不大。2. 部署前的准备把需求和环境先盘清楚2.1 硬件配置怎么选很多人部署这类系统时最容易犯的错是一上来就按“生产环境高配”去买服务器。其实设计协作工具的性能瓶颈通常不在 CPU而在内存和磁盘 IO。你打开一个大型设计文件时前端要做大量渲染后端要处理文件数据和协作广播内存小了会频繁 GC体验就很卡。以我个人的实测经验给一个参考场景CPU内存磁盘说明个人体验/1-3人小团队2核4G40G SSD跑起来没问题但大文件同时编辑会有点吃力10人左右团队4核8G100G SSD最推荐起步配置日常使用很宽松20人以上/生产环境8核16G200G SSD 以上还要考虑对象存储和负载均衡磁盘一定要选 SSD设计文件里大量小体积资源读写机械硬盘在这类场景下会明显拖后腿。备份盘可以单独挂一块大容量机械盘后面我会讲。2.2 软件栈选型为什么我推荐 Docker ComposeLovart 这类现代 Web 应用底层基本绕不开应用服务、数据库、文件存储这几块。部署方式主要有两条路一条是直接在服务器上装依赖环境手动配置另一条是用 Docker Compose 把所有服务编排起来。我强烈推荐后者的原因很简单可重复、可回滚、心智负担低。Docker Compose 把应用容器、数据库容器、网络、存储卷都写在一个配置文件里迁移到新服务器时复制配置文件重新 docker compose up -d 就能恢复一套一样的运行环境。手动安装的话一次系统更新把某个依赖版本顶掉整个服务可能就挂得莫名其妙。Lovart 的官方文档里提供了 Docker 部署的编排示例这也是我建议新手选择的方式。2.3 网络与访问方式先想好再动手部署之前先问自己一个问题这套服务是“只在内网访问”还是“需要公网访问”纯内网访问适合办公室局域网里用。配置最简单不用买域名不用管 HTTPS只要保证服务器 IP 固定就行。缺点是离开办公室基本用不了。内网 公网访问适合需要在家、出差地访问的情况。这时候一定要配域名和 HTTPS否则浏览器会有安全提示。防火墙策略无论哪种方式记得在系统防火墙里只放行必要端口。内网访问就限制来源 IP 段公网访问则要开启防火墙的端口映射和必要防护。很多人在这一步偷懒把所有端口全部对外开放结果跑了两周发现数据库端口被扫描爆破。这不是危言耸听公网上的扫描器每时每刻都在跑。2.4 版本管理用稳定版别急着追新开源项目迭代快Lovart 的 main 分支上可能每天都在合并新功能。部署生产环境时我建议直接使用官方发布的 release 版本对应的 Docker 镜像而不是拉 latest 或 main 分支的构建产物。原因很简单release 版本通常经过了更完整的测试文档和配置示例也是以它为准。追新代码一旦遇到破坏性变更你可能要被迫花一个晚上解决兼容问题没必要。3. 从拉取镜像到首次访问完整的本地部署实操3.1 目录规划与配置文件假设你已经有一台干净的 Linux 服务器并且装好了 Docker 和 Docker Compose 插件。我习惯把这类服务统一放在 /opt 下面每个应用一个独立目录方便管理备份。mkdir -p /opt/lovart/data /opt/lovart/backup cd /opt/lovart接下来创建一个 docker-compose.yml。如果你不想手动敲也可以直接参考官方仓库里的示例文件但核心结构就是这个思路version: 3.8 services: lovart-server: image: lovart/lovart:release # 请以官方仓库发布页的实际镜像名为准 container_name: lovart-server restart: unless-stopped ports: - 8080:8080 environment: LOVART_DB_HOST: lovart-db LOVART_DB_PORT: 5432 LOVART_DB_NAME: lovart LOVART_DB_USER: lovart LOVART_DB_PASSWORD: 请改成强密码 LOVART_STORAGE_DIR: /data/files LOVART_JWT_SECRET: 请生成一个随机长字符串 volumes: - ./data:/data depends_on: - lovart-db lovart-db: image: postgres:16-alpine container_name: lovart-db restart: unless-stopped environment: POSTGRES_DB: lovart POSTGRES_USER: lovart POSTGRES_PASSWORD: 请改成强密码 volumes: - ./db:/var/lib/postgresql/data几个关键地方提醒一下LOVART_JWT_SECRET是用来签发登录令牌的密钥一定不要用默认值可以用openssl rand -hex 32生成一个。./db挂载了数据库实例的数据目录这个目录以后要重点备份。./data挂载了应用上传的文件资源同样要进备份范围。端口映射8080:8080的意思是宿主机 8080 端口映射到容器内的 8080 端口如果 8080 已被占用可以改成别的但后面的反向代理配置要跟着改。3.2 启动服务与观察日志配置文件写好后启动命令只有一行docker compose up -d第一次执行会拉取镜像根据网络情况可能需要几分钟。启动完成后先别急着打开浏览器先看日志确认没有关键报错docker compose logs -f --tail100 lovart-server看到类似服务监听端口的日志说明应用已经起来了。此时可以先用浏览器访问http://服务器IP:8080能看到登录页就说明环境基本通了大半。如果页面无法访问不要急着怀疑 Lovart 本身先检查三件事容器内部是否正常、端口映射是否正确、宿主机防火墙是否放行了对应端口。顺序别反否则容易白折腾。3.3 Web界面的初始化操作第一次访问会进入初始化流程一般会让你创建管理员账号并指定团队名称。这一步会写进数据库所以别乱填尤其管理员邮箱以后找回密码、接收系统通知都靠它。初始化完成后建议按下面的顺序把工作区配置好创建团队或工作区把团队名改成公司或项目组实际名称。在团队设置里添加成员分配角色管理员、编辑者、查看者。建立项目结构比如“官网改版”、“移动端 2.0”、“品牌物料库”。上传团队 Logo 和常用字体。新建一个空画板测试多人协作是否正常。这个时候 Lovart 算是跑起来了但你大概率还不会直接投入日常使用——因为有个更重要的问题要解决怎么让团队成员方便、安全地访问它。3.4 接一个二级域名和HTTPS入口直接用 IP 加端口访问虽然能用但证书提示、密码存储方面的体验都比较差而且现在主流浏览器对非 HTTPS 环境的权限限制越来越严很多高级 API 用不了。所以我的建议是只要有公网访问需求就配一个域名加 HTTPS。假设你有一个域名design.example.com要指向这台服务器并且已经解析好了。用 Nginx 做反向代理是很常规的做法核心配置如下server { listen 443 ssl; server_name design.example.com; ssl_certificate /your/path/fullchain.pem; ssl_certificate_key /your/path/privkey.pem; client_max_body_size 100m; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /ws/ { proxy_pass http://127.0.0.1:8080/ws/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } server { listen 80; server_name design.example.com; return 301 https://$host$request_uri; }证书可以用 Let’s Encrypt 的免费证书用 certbot 签发这里不展开。location /ws/这段是 WebSocket 代理多人实时协作的同步通信就靠它千万别删掉。3.5 开启 HTTPS 后还要做什么配置完 Nginx 后重启一下服务再用浏览器访问https://design.example.com。如果一切正常登录框前面的锁标志会显示安全连接。这个时候我还建议你顺手做两件事一是把数据库端口彻底关掉只保留内网访问。vps 商后台的安全组规则里5432 端口不要对外放开。二是开启二步验证。Lovart 是否自带这个功能要看版本至少管理员账号一定要用强密码并且留意官方文档是否有补充的安全选项。4. 真实使用中的几个高频坑和排查思路4.1 端口通了但页面一直白屏或转圈这个问题是我见豆瓣上有人留言问得最多的。现象很典型浏览器里输入地址后页面标题有了但主内容区域一直白屏控制台还有一堆报错。多数情况下这不是 Lovart 本身坏了而是前端资源没有加载完整。排查的时候别急着去看应用日志先打开浏览器开发者工具看网络请求里有没有返回 4xx、5xx 的静态资源请求。如果发现大量静态资源请求都被反向代理拦截了问题就出在 Nginx 的静态资源路径上。解决办法通常有两个方向要么给静态资源路径单独加一个location段要么确保proxy_pass后面的地址和实际服务端口完全一致并且开启了正确的 header 转发。这类问题没有统一的代码片段能解决因为每个人的路径配置不一样但排查思路是通用的。4.2 上传图片/字体包失败部署完成后最容易遇到的第二个问题就是上传资源失败。我遇到过的情况有两种一种是从浏览器上传大文件时直接被 Nginx 的client_max_body_size拦住了默认值是 1m设计图文件动不动就几十 M所以要在配置里调大前面示例里我写的是100m。另一种是应用容器的存储目录没有写权限。如果你用的是./data挂载宿主机的这个目录默认属主是 root而容器里的应用进程可能是以非 root 用户运行的。这时候要么给目录授权要么在建卷的时候指定好 UID/GID。遇到上传失败时先执行docker compose logs lovart-server | grep -i error看看有没有权限相关的记录能省很多时间。4.3 多人同时编辑时光标不同步、像“幽灵”多人协作功能对网络很敏感。如果你的部署环境里有人反馈能看到别人编辑的内容但光标位置和选中区域更新不及时甚至偶尔断开重连十有八九是 WebSocket 被卡了。刚才 Nginx 配置里专门写了一段location /ws/很多人图省事直接省略掉或者只配置了普通 HTTP 代理。WebSocket 协议需要显式的 Upgrade 头部转发普通代理不会自动处理于是协作同步就废了。排查时可以打开浏览器控制台看有没有 WebSocket 连接报错的日志。如果有回到 Nginx 配置确保proxy_http_version 1.1和proxy_set_header Upgrade $http_upgrade这两行都写上然后重启 Nginx。4.4 升级版本后数据库迁移异常开源项目升级是最容易出问题的环节因为数据库结构可能变了。Lovart 的容器镜像本身不包含数据库所以升级应用版本时新的应用容器会自动跑数据库迁移脚本。正常流程应该是先备份数据库再拉新的应用镜像最后启动容器让它自动迁移。迁移完成后马上看日志确认没有字段冲突或约束报错。如果迁移失败了别硬着头皮继续启动服务否则可能出现半迁移状态。最稳妥的办法是恢复刚才的数据库备份回到旧版本镜像重新启动等服务恢复正常后再研究为什么迁移失败。这条经验适用于几乎所有带数据库的自托管应用。4.5 中文字体显示成方块设计平台里经常要预览中文字体效果而默认容器镜像里往往只带了基础字体中文渲染就是方块占位符。这个问题不算致命但很影响第一印象。解决方式有两个一是把常用的中文字体文件上传到 Lovart 的资源中心里作为团队字体使用二是在宿主机安装系统字体然后通过卷挂载方式把字体目录传入容器。具体路径看官方文档这里不写死。5. 日常维护和备份本地部署不是装完就不管5.1 到底要备份哪些东西我见过太多人把自托管服务跑起来之后就不闻不问直到某天磁盘坏了才发现所有设计稿都没了。本地部署的维护责任完全在自己身上多上点心十分必要。Lovart 的数据分两部分数据库和文件存储。数据库里存的是用户、项目、图层结构、协作记录等元数据文件存储里存的是上传的图片、导出文件、字体包等原始资源。两者缺一不可只备份数据库不备份文件恢复后你会得到一堆链接失效的项目。5.2 写一个定时备份脚本一个简单可靠的思路是写一个 shell 脚本每天凌晨把数据库导出成 SQL 文件并把文件存储目录打成 tar 包然后推到对象存储或其他机器上。下面是一个可以改改就用的例子#!/bin/bash BACKUP_DIR/opt/lovart/backup DATE$(date %Y%m%d_%H%M%S) DB_CONTAINERlovart-db DB_NAMElovart DB_USERlovart mkdir -p $BACKUP_DIR docker exec $DB_CONTAINER pg_dump -U $DB_USER $DB_NAME $BACKUP_DIR/db_$DATE.sql tar czf $BACKUP_DIR/files_$DATE.tar.gz -C /opt/lovart ./data find $BACKUP_DIR -type f -mtime 30 -delete最后一行表示只保留最近 30 天备份避免磁盘被备份文件塞满。你还可以把备份文件同步到另一台机器或云存储别只存本机。5.3 升级流程与验证每次官方发布新版本我建议按这个顺序操作先备份数据库和文件存储。docker compose pull拉取新版本镜像。修改 compose 文件里指定的镜像标签。docker compose up -d重建容器。盯紧日志重点关注迁移脚本执行情况。登录系统随便打开一个包含大量图层的项目确认渲染和保存都正常。让一个同事在另一台电脑上同时编辑验证协作同步。这套流程做完再用能省掉大多数升级后遗症。5.4 进阶优化对象存储和更多可扩展方向团队规模变大以后单机部署会逐渐吃紧。此时可以考虑几个方向用 MinIO 或云对象存储替换本地文件存储把上传资源从应用服务器里剥离开。增加 Redis 缓存减少数据库压力。用 Nginx 对静态资源做缓存改善大团队的访问速度。数据库从单点切到主从复制提高可用性。这些都属于“后期再说”的优化项。前期先把部署跑通、备份做好比什么都强。6. 我的一些个人体会写到最后聊一点真实的感受。第一次把 Lovart 跑起来之后我盯着登录界面发了会儿呆。这种“所有东西都在自己手里”的感觉用过一次就回不去了。它不像商业 SaaS 那样打开即用你付出的是一些服务器运维上的学习和日常维护成本换回来的是数据自主权和长期可控的成本结构。对习惯折腾的人来说这种交换非常值得。如果你准备尝试我建议先从一台低配服务器开始不用一次性上很高配置。把官方文档里的 Docker 部署方式跑通创建两个账号在里面放一个真实的项目画几天感受一下协作流程到底顺不顺手。都满意了再考虑正式迁移团队业务那时候你已经有足够的底气去处理各种突发问题。开源设计平台的生态还在快速发展Lovart 只是其中一个值得关注的项目。希望这篇内容能帮你避开我踩过的那些坑用更短的时间把它变成团队里真正能用起来的工具。
