开头我想先聊聊这篇文章的主角一个我最近才跑通的自托管项目代号“11111”。它不是占位符也不代表什么神秘的版本号而是我对这套部署方案的硬性要求——1台低配服务器、11个自己完全掌控数据的容器服务、1套统一编排、1套备份体系、1套失败后能快速恢复的完整流程。说白了这就是一次“一个人干完整条运维链路”的实战。如果你正在纠结“要不要自己折腾服务器”“用别人的云服务感觉数据不踏实”或是对Docker Compose、反向代理、自动备份这套东西只听过没上手过那这篇内容应该能帮你少走不少弯路。整篇文章不会讲得太玄所有东西都是我实际部署、实际使用、实际踩坑后整理出来的。我会从整体设计思路说起再到细节拆解、配置文件示例、常见故障排查最后聊聊我固化下来的操作习惯。不管你是第一次接触服务器还是已经跑了几个服务想进一步规划都能从中找到可以抄作业的部分。1. 项目整体设计与思路拆解1.1 为什么是“11111”这个代号这个代号其实是我在规划项目时定的几条硬约束每条都对应着部署中最容易忽略的问题。先说这个“1台服务器”。很多人一上来就按企业标准买高配机器4核8G起步结果跑一个博客和一个密码库CPU占用常年不到5%。我的建议是先想清楚自己到底要跑什么再决定买多大配置。我实际用的是一台2核4G的云主机磁盘40G跑下面列的11个服务完全够用资源峰值出现在每天凌晨做备份的时候CPU会跳到70%左右其余时间基本维持在10%上下。低配机器不仅省钱还会逼着你克制不会随手堆出一堆长期不用的服务。接着是“11个容器服务”。这个数字不是硬凑的而是我按“个人日常需要”列出来的清单每一项都能解决一个明确问题。后面我会把清单完整列出来有笔记、密码管理、RSS阅读、网盘、看板、监控、导航页、相册、同步、博客和短链工具没有一个是多余的。然后是“1套编排”“1套备份”“1套恢复”。这三条其实是整个项目真正值钱的地方。很多人的自托管是“今天装一个明天装一个全凭记忆”时间一长自己都忘了哪个容器在哪个目录、改了哪些配置、映射了哪些端口。用一套Docker Compose把全部服务管起来把所有配置集中在一处再配上一套定时备份和恢复脚本哪怕整台服务器彻底崩了我也能在半小时内恢复到一个能正常使用的状态。1.2 为什么用Docker Compose而不是Kubernetes先回答一个很多人会问的问题既然要跑11个服务为什么不用Kubernetes答案是完全没有必要。Kubernetes擅长的是“多节点、弹性伸缩、服务发现、自动扩缩容”这些能力解决的是几十上百个微服务分布在多台机器上的调度问题。而我这里所有服务都跑在同一台机器上规模小、变更少、依赖固定用它的学习成本远大于收益。Docker Compose只需要一个YAML文件就能描述所有容器、网络、卷、环境变量一条docker compose up -d就能全部拉起调试、迁移、备份都非常直接。拿我自己举例最开始我也试过用Portainer之类的图形管理面板后来发现大部分操作还是得落到命令行。Compose文件本身就是最好的文档写清楚之后新机器上只要把项目目录拷贝过去docker compose up一下就能恢复整个环境。这种“配置即基础设施”的思路比点鼠标去创建容器要可靠得多也更容易版本化管理。1.3 11个服务的清单与选型这11个服务不是拍脑袋装的每一项都有具体的使用场景。我整理了一张表你可以根据自己的需求增删序号服务用途说明默认访问方式1Vaultwarden密码库兼容Bitwarden客户端子目录 /vault2Outline团队/个人知识库适合长文沉淀子目录 /docs3MinifluxRSS订阅阅读器轻量且速度快子目录 /rss4Nextcloud个人网盘文件同步和分享子目录 /cloud5Vikunja任务看板管理待办和项目子目录 /task6Homepage导航页把常用服务集中到一屏根路径 /7Immich相册备份手机照片自动同步子目录 /photo8Syncthing跨设备文件同步不经过第三方子目录 /sync9Uptime Kuma服务监控异常时发通知子目录 /status10Ghost博客引擎写公开发布的文章子目录 /blog11Shlink短链工具把长URL变成短链子目录 /link选型上我的原则是优先选内存占用低、数据格式开放、更新不那么激进的服务。比如密码库用Vaultwarden而不是自己搭一个复杂的密码系统RSS用Miniflux而不是Tiny Tiny RSS都是为了能在2G内存的机器上流畅跑起来。如果你不想用其中某一个完全可以把序号空着Compose文件里删掉对应段落就行这套架构本身对增删服务非常友好。2. 核心细节解析与实操要点2.1 服务器、域名和防火墙的准备这一步是整个项目的地基别急着装Docker如果服务器和域名的准备出了问题后面所有服务跑起来也访问不了。服务器方面我的建议是选一个你熟悉的云厂商2核4G起步带宽3M到5M就够用了。系统我推荐Debian 11或12相比Ubuntu它更精简跑Docker的体验也更稳。买好机器后第一件事就是更新系统并创建普通用户不要从头到尾都用root操作。虽然root能解决所有权限问题但也意味着任何一个小失误都可能把系统搞坏而普通用户配合sudo能给我们一个缓冲地带。域名方面如果你有多个服务要暴露到公网一定要准备一个域名并且用子目录或子域名的形式来区分不同服务。申请域名后把泛解析*.example.com或者至少A记录解析到服务器IP。这里要注意解析生效可能需要几分钟到几十分钟别刚设置完就急着下一步。防火墙是我觉得最容易被忽略的。很多新手开了端口9999、8080给某个服务结果服务怎么都访问不了排查半天才发现是云控制台的安全组没有放行。正确做法是只放行22SSH和80/443HTTP/HTTPS其他端口一律不放行到公网。所有服务都通过Nginx反向代理从80/443进来这样既能统一管理证书也能最大程度减少暴露面。2.2 Docker Compose文件中的网络与卷设计Compose文件是整个项目的核心初次写的时候建议遵循一个原则所有服务放在同一个自定义网络中服务之间通过服务名互相访问不暴露额外的宿主机端口给公网。为什么不建议把每个容器的端口都映射到宿主机因为一旦映射了意味着这一端口直接从宿主机暴露到网络就算云安全组没放行也增加了意外暴露的风险。我实际的做法是只让Nginx容器把80和443端口映射到宿主机其他服务一律不映射端口。Nginx通过Docker网络直接访问内部的容器地址比如访问Vaultwarden反代配置里写http://vaultwarden:80这种写法在Compose网络里直接就通了不需要知道容器的IP。卷的设计上每个服务的数据目录都集中在项目下的volumes目录里命名规则是服务名加子目录比如volumes/vaultwarden、volumes/nextcloud。这样备份时就只需要打包这一个目录恢复时也只需要解压回来。这里的坑点是一定要给数据卷加上明确的目录名不要用Docker的匿名卷否则你自己都找不到数据到底存到了哪里。2.3 Nginx反向代理与HTTPS证书反向代理这步解决的是“怎么用一个域名入口访问所有服务”以及“怎么让每个访问都带上HTTPS加密”。证书部分我用的是acme.sh脚本配合Let‘s Encrypt免费、自动续期过程基本无感知。首次颁发证书时先让Nginx监听80端口并配置一个临时的ACME验证站点等证书签发后再把80请求301跳转到443。这个过程可能有些人觉得繁琐但只要你把域名解析弄好照着流程走一遍后续续期全部自动化。转发配置文件里几个关键参数必须注意。一是proxy_set_header Host $host这个是把原始域名传给后端服务否则服务方会看到IP地址导致一堆奇怪的跳转问题。二是WebSocket支持像Vikunja看板这类实时更新的服务需要在location块里额外加上proxy_set_header Upgrade和Connection头。三是client_max_body_size如果你要传大文件比如用Nextcloud传几百MB的视频默认的1MB限制会让你直接得到413错误我把它调到了2G。2.4 数据持久化与备份策略自托管服务最怕的不是服务挂了而是数据丢了。容器本身随时可以重建但数据是几个月甚至几年积累下来的不能有任何闪失。我采用的备份策略是“磁盘快照定时文件打包”双保险。定时打包用cron每天凌晨执行把整个项目目录压缩成tar文件并保留最近14天的版本。压缩完把备份文件同步到另一台机器或者对象存储避免“服务器硬盘坏了备份也一起没了”的尴尬。磁盘快照则是在云控制台手动开启每周点一次做最底层的兜底。权限问题是备份恢复时最容易踩的坑。很多服务的数据文件属于容器内的特定用户比如UID是33的www-data备份时用root打包没问题恢复时如果解压到了宿主机目录可能会因为属主不匹配导致服务无法启动。解决办法是恢复时不要直接解压而是先看打包文件里的用户和组信息必要时用chown -R把属主改成对应的UID/GID再重启容器。3. 实操过程与核心环节实现3.1 基础环境安装Docker与Compose插件在所有配置开始之前先把运行环境装干净。我以下面这段命令为例假设你用的是Debian系统且当前用户具备sudo权限sudo apt update sudo apt upgrade -y sudo apt install -y curl git ufw curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable --now docker sudo apt install -y docker-compose-plugin docker compose version执行完以上命令你的机器就有了Docker和Compose插件。这里有几个值得留意的地方第一安装Docker时不要用系统自带的老版本docker.io包用get.docker.com的官方脚本会帮你配置好软件源安装的版本更新也更稳定。第二docker-compose-plugin装的是新版Compose V2日常命令是docker compose中间有个空格不是docker-compose。老教程里很多命令都写的是带横杠的docker-compose如果你装的是插件版记得把命令改成新写法。第三装完Docker后顺手执行sudo docker run hello-world验证一下能正常输出提示就说明核心组件没问题。防火墙这边我建议直接用ufw设置也简单sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status看到Status: active并且22、80、443都是允许状态就可以继续了。3.2 项目目录结构和Compose配置示例我习惯把整个项目放在/opt/selfhost目录下里面的结构是这样/opt/selfhost ├── compose.yaml ├── .env ├── nginx │ └── conf.d │ ├── default.conf │ └── letsencrypt └── volumes ├── vaultwarden ├── outline ├── miniflux ├── nextcloud ├── vikunja ├── homepage ├── immich ├── syncthing ├── uptime-kuma ├── ghost └── shlinkcompose.yaml的第一段是通用配置定义网络、卷和Nginx容器。完整写出来会非常长这里我先展示最核心的骨架说明关键写法name: selfhost networks: app-network: driver: bridge services: nginx: image: nginx:stable-alpine container_name: nginx restart: unless-stopped ports: - 80:80 - 443:443 volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./volumes/letsencrypt:/etc/letsencrypt networks: - app-network vaultwarden: image: vaultwarden/server:latest container_name: vaultwarden restart: unless-stopped volumes: - ./volumes/vaultwarden:/data networks: - app-network这里面有几个通用设置需要解释一下。restart: unless-stopped表示容器意外退出时会被Docker自动拉起来除非你手动停止它这个策略对长期跑的服务非常有用。ports部分只有nginx这个服务映射了宿主机端口其他服务不写ports只接入同一个app-network这样nginx就能通过服务名访问它们。.env文件是用来存一些敏感值和可复用变量的比如域名、时区、数据库密码。一个简单的示例DOMAINexample.com TZAsia/Shanghai写Compose的时候通过${DOMAIN}引用这样以后换域名只需要改一个文件不需要逐个容器去改环境变量。3.3 Nginx站点配置与证书签发示例安装好nginx容器后要让域名和证书正常配合起来。我以Vaultwarden为例给一份完整的子目录反向代理配置方便你对比着改server { listen 80; server_name example.com; location /.well-known/acme-challenge/ { root /var/www/certbot; } location / { return 301 https://$host$request_uri; } } server { listen 443 ssl; http2 on; server_name example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; client_max_body_size 2G; location /vault/ { proxy_pass http://vaultwarden:80/; 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; } }这段配置主要做了三件事把80端口的ACME验证请求放行给证书签发工具其他80访问一律跳转到HTTPS443上把/vault/路径转发给vaultwarden容器。在这里有个很容易忽略的细节proxy_pass后面写的是http://vaultwarden:80/末尾的斜杠很关键。它表示将location /vault/前缀剥离后再转发所以浏览器访问https://example.com/vault/的时候后端Vaultwarden接收到的是/而不是/vault/。如果你不写末尾斜杠后端就会收到带/vault/前缀的路径很多服务会因为路由对不上而报404。签发证书的命令我用的是acme.sh的standalone模式配合临时Nginx。大致流程是先把上面的nginx配置只保留ACME location然后执行curl https://get.acme.sh | sh ~/.acme.sh/acme.sh --issue -d example.com --nginx ~/.acme.sh/acme.sh --install-cert -d example.com \ --key-file /opt/selfhost/volumes/letsencrypt/live/example.com/privkey.pem \ --fullchain-file /opt/selfhost/volumes/letsencrypt/live/example.com/fullchain.pem签发成功后再把443的server块补上reload Nginx。第一次跑这个流程的时候我建议先在本地模拟环境练一遍别直接对着线上机器搞因为证书签发失败或配置错误会导致服务短暂不可用。3.4 一键启停、查看状态与日志追踪部署完成后日常运维基本只需要记住几条命令。启动全部服务用docker compose up -d停止全部服务用docker compose down查看每个容器的运行状态用docker compose ps。第二条命令的时候有个细节docker compose down默认会保留卷所以数据不会丢但如果你手滑加了-v参数就会把卷也删掉这个参数一定要谨慎使用它等于你的数据被清空而没有任何恢复途径。日志追踪是我日常用得最多的。想看某个容器最近的日志用docker compose logs -f --tail50容器名比如docker compose logs -f --tail50 nextcloud。多容器一起看日志可以不加容器名但内容会很杂我一般还是按单个容器排查。整个文件夹作为项目的唯一入口也是我好用的习惯。不管在哪个设备上只要ssh到服务器、进入目录docker compose ps一眼就知道哪些服务活着、哪些挂了。配合Uptime Kuma的外部监控哪怕某天容器异常重启也能第一时间发现。4. 常见问题与排查技巧实录4.1 容器启动失败或一直重启新服务启动就失败最常见的原因是端口被占用、环境变量缺参数、数据卷权限不对。排查思路其实很固定先docker compose logs --tail 20看看日志再对照官方文档检查环境变量最后确认数据目录属主。我在跑Immich的时候模拟过一次“数据目录权限不对”的真实场景。把卷目录挂载进去后服务一直重启日志里提示找不到某个临时目录。用ls -n查看目录UID发现宿主机目录属于root(UID 0)而容器里跑服务的用户是UID 1000。解决起来也简单执行sudo chown -R 1000:1000 ./volumes/immich再docker compose restart immich就好了。这类问题多出现在有独立数据目录的服务上养成“先看日志再查权限”的排查习惯会快很多。4.2 HTTPS证书自动续期失败acme.sh的续期机制正常情况下不需要手动干预但有几个因素会导致续期不成功。最常见的是80端口没有被Nginx正确放行ACME验证请求返回404证书无法更新。第二个常见原因是域名解析变过但acme.sh里缓存的记录还是旧的。排查的时候先手动执行~/.acme.sh/acme.sh --renew -d example.com --force看报错内容。如果提示连接失败先确认服务器防火墙是否放行80端口再确认nginx容器确实在监听80。如果提示解析不到IP去域名控制台确认A记录指向的IP是不是当前服务器的IP。手动续期成功后再用acme.sh --install-cert把新证书重新安装到nginx的数据目录最后docker compose exec nginx nginx -s reload。用好cron定时任务的话理论上每年只需要看一眼证书到期时间其他时间不用管。我的习惯是每个月手动检查一次因为证书有效期三个月一个月检查一次完全能覆盖潜在问题。4.3 磁盘空间告急与日志文件膨胀自托管跑了几个月后最容易遇到的是磁盘满了。最常见的几个罪魁祸首Docker日志没限制、Nextcloud的版本缓存、Immich的缩略图目录、数据库的binlog文件。针对Docker日志我建议创建或修改/etc/docker/daemon.json加上日志轮转的配置{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }改完后重启Docker你会发现单个容器日志最多只保留30MB磁盘压力立刻小很多。需要注意的是这个配置只对重启后的新容器生效对已存在的容器不生效所以改完配置后对现有容器执行docker compose up -d重建一遍日志配置才会应用上。查看磁盘占用分布时我常用的命令是du -h --max-depth2 /opt/selfhost/volumes哪块占用大一眼就能看出来。如果发现数据库目录特别大多半是binlog等中间文件没清理可以按对应服务的官方文档把过期日志清理掉。4.4 备份恢复时遇见的权限问题备份恢复的过程里文件权限问题是重灾区。我第一次模拟“从备份恢复整套服务”的时候就出过状况——备份是在另一台机器上用root打包的恢复到新机器后几乎每个服务都无法正常启动。原因不复杂tar打包时用root运行所有文件的属主都是root但容器内部一般使用普通用户身份读写比如UID 33或UID 1000。容器启动时发现数据文件不可写自然报错退出。解决办法有两个一是在打包备份时不保留属主信息用tar --ownerroot --grouproot来统一二是在恢复后集中修正权限对每个服务目录执行chown -R对应的UID:GID。比较稳妥的做法是项目里准备一个restore-permissions.sh脚本把每个服务对应的UID/GID都写进去恢复完跑一遍脚本再启动容器。还有一个很多人容易忽略的点恢复备份前务必先docker compose down停掉目标机器上已有的同名容器否则旧容器持有的文件句柄可能会和恢复过程冲突导致文件写入一半报错。先把容器停掉再解压是恢复流程里最保险的顺序。4.5 内存和CPU占用异常上涨低配机器跑容器集群最担心的就是内存吃紧。2G内存跑11个容器虽然我有把握没问题但前提是服务没有内存泄漏或者没有哪个服务偷偷递归扫描大目录。内存不够的典型表现是容器反复重启、网页加载极慢、SSH操作卡顿。排查内存占用用docker stats能看到每个容器的实时CPU和内存。如果某个容器一直占着几百MB先去它的数据目录看有没有生成超大文件比如Nextcloud的预览缓存、Ghost的日志、Miniflux的数据库。如果确认是某个服务的bug级内存泄漏最实际的办法是缩短数据保留周期或者升级到4G内存。我用2G内存跑了三个月后最后还是升级到了4G不为别的就为了每次系统更新的时候不用纠结先停哪个服务来腾空间。5. 跑通之后我保留下来的操作习惯这套项目跑通之后我并没有急着往里加更多服务反而开始做减法同时把日常流程固化下来。这里分享几个我现在还在坚持的习惯对想长期维护自托管项目的人来说可能会有参考价值。第一个习惯是“每周看一次docker compose ps”。不需要做什么分析就是确认所有服务都是Up状态。如果哪个服务显示Exited或Restarting先看日志再决定怎么处理而不是盲目重启。别小看这个动作很多潜在问题在变成事故之前都有预兆比如某个容器连续几天反复重启只是你没看。养成看状态的习惯之后很多故障我都能在用户发现之前处理掉。第二个习惯是“改配置之前先备份compose.yaml和.env”。这两个文件是整个项目的大脑一旦改坏可能所有服务都起不来。我的做法是把这两个文件的备份放到另一个目录起名带上日期比如compose.yaml.bak-20250401改完之后确认服务正常再定期清理一周前的备份。借助Git管理配置也是个好选择每次改动都留一次提交记录出问题可以直接回滚。第三个习惯是“数据卷里不放临时文件”。现在所有容器的数据目录只承载应用产生的数据任何下载、测试文件我都放在服务器其他目录避免备份包里混入大量无用文件。这样备份体积稳定恢复也更快。第四个习惯是“对外只开放一个入口”。所有服务都走Nginx的80/443进来云安全组只放行这三个端口SSH改用密钥登录并且监听非标准端口。这样即使某个容器出现漏洞攻击者也无法直接接触到内网服务。自托管要长期用下去安全一定要从第一天就纳入设计而不是等出事了再补窟窿。这些习惯可能看起来都很小但它们联合起来的作用是让一套自己维护的服务变得真正可靠。我到现在依然记得第一次跑通全部11个服务时的心情那种“所有数据都在自己手里”的踏实感是任何现成云服务都给不了的。如果你也正在规划类似的项目我的建议是先从两三个核心服务跑起来熟悉了这套流程之后再慢慢填满你自己的那份“11111”清单。