那些「酷,但用不着」的 self-hosted 应用
<p>Self-host 即「自部署」,指的是在自己的服务器上部署软件程序,从而替代 SaaS 应用。</p> <p>前几年我有一种 self-hosted 狂热。没事就刷刷 <a href="http://awesome-selfhosted.net">awesome-selfhosted</a>,总想让服务器承载更多好玩的功能。得益于 Docker 和 Caddy,只需要写一个 compose.yml,一个新的应用就能立即上线并通过 skywt.cn 的子域名访问,部署体验方便快捷。</p> <p>这些软件的开源的精神非常宝贵,也是这个世界所需要的。然而不得不承认,大多数开源产品的软件更注重功能而非设计,不少设计非常缺乏品味,这并不是我想要的。加上由于:1)自从工作以来,属于自己的折腾时间大大减少了,我不希望再花太多精力在这些服务的维护上;2)我已被绑定在 Apple 生态中,结合 iCloud 有很多产品都能找到 Apple 体系的替代品。</p> <p>因此,现在我身上的这种 self-hosted 狂热有些退烧了。</p> <p>最近,正值网站改造之际,我将服务器上不常用的 self-hosted 软件都下线了,只保留我真正会用到的几个。下线的这些所有软件,都是我以前感兴趣过、折腾过、兴奋过的。这篇文章将它们记录下来,以表纪念。</p> <h2>酷,但用不着</h2> <p>这些是我已经下线的应用。以前部署过,或许用过一段时间,但后来因为各种原因已经用不着了。</p> <ul> <li><a href="https://supabase.com/docs/guides/self-hosting">Supabase self-hosted</a>:Supabase 的自部署版,全面的后端解决方案。**不要自部署,会变得不幸(虽然看起来很酷)。**我们使用 Supabase 无非是想要将后端复杂度外包出去,但自己部署则完全且彻底地违背了这一初衷。光是示例的 compose.yml 文件长达五百余行,包含这些组件:studio、kong、gotrue、postgrest、realtime、storage-api、darthsim/imgproxy、postgres-meta、edge-runtime、logflare、postgres、timberio/vector、supavisor、minio。还是用 Supabase 在线服务吧。</li> <li><a href="https://github.com/dbeaver/cloudbeaver">CloudBeaver</a> / <a href="https://www.phpmyadmin.net">phpMyAdmin</a>:管数据库用的 WebUI,不用写 SQL 就能增删改查。有段时间我甚至拿 CloudBeaver 当我的网站后台,直接在这儿发博客。酷,但现在我的数据库都上了 Supabase,这些都不需要了。</li> <li><a href="https://www.authelia.com">Authelia</a> / <a href="https://www.keycloak.org">Keycloak</a>:自建 SSO,给所有 self-hosted 应用一个统一的用户系统。酷,但我不再需要单独自建 SSO 了。Supabase 提供<a href="https://supabase.com/docs/guides/auth/oauth-server/getting-started">作为 OAuth Server 的功能</a>,这样账户体系可以直接共用我的 skywt.net。这更酷了!</li> <li><a href="https://freshrss.org/index.html">FreshRSS</a>:简洁好用的 RSS 阅读器。酷,但我现在使用开源 RSS 客户端 NetNewsWire,足够简洁,通过 iCloud 同步是更方便的选择,不再需要在 Web 里看 RSS 了。</li> <li><a href="https://github.com/dani-garcia/vaultwarden">VaultWarden</a>:BitWarden 的开源服务端。酷,但我已经完全使用 Apple Passwords 代替将近一年,没有发现任何场景下的问题。</li> <li><a href="https://nextcloud.com">NextCloud</a>:历史悠久、功能强大的网盘系统,应用生态异常强大,足够折腾很久。酷,但基于 PHP 的古老技术栈让使用体验一言难尽。大多数功能都属于「看起来很酷,但实际上你不会用」的(真的有人会在 NextCloud 这种东西里管理菜单食谱购物清单吗?)。或许在团队协作的场景中会很有用,但对个人而言,没必要。</li> <li><a href="https://cloudreve.org">Cloudreve</a>:强大的云盘。酷,但我有 iCloud 了。</li> <li><a href="https://usememos.com">Memos</a>:最开始是 flomo 浮墨笔记的开源替代品。酷,但我有什么想法都发推特了,和这个形式也很类似。另外吐槽一下,这个软件的产品设计改来改去的,每过几个版本 UI 就大改一次,真的有点难适应。</li> <li><a href="https://gitea.com">Gitea</a>:类似 GitLab 的平台。酷,但目前想不到将任何一个项目传到自己的平台而非 GitHub 的理由。</li> <li><a href="https://github.com/SnapDrop/snapdrop">Snapdrop</a>:传文件工具。酷,但有太多替代品了。Apple 生态内 AirDrop 体验也比这个好太多了。</li> <li><a href="https://github.com/coder/code-server">Code-server</a>:网页里的 VSCode。酷,但我究竟在什么情况下会放着本地的 IDE 不用而在浏览器里受罪呢?</li> <li><a href="https://github.com/janeczku/calibre-web">Calibre-web</a>:给 Calibre 里的电子书一个 web 页面。酷,但如果我要看我有哪些书,打开自己本地的 Calibre 看起来更方便……</li> <li><a href="https://overleaf.com">Overleaf</a>:强大的 all-in-one 在线 LaTeX 编辑器。酷,但只有写非常正式的论文用得着,且自己部署占用资源太大了,使用体验还不如用官方的在线服务 overleaf.com。</li> <li><a href="https://getoutline.com">Outline</a>:支持团队协同编辑的知识库。酷,UI 好看,协同体验很不错(有点类似飞书文档),但部署非常麻烦,个人使用真的没必要。</li> <li><a href="https://github.com/cooderl/wewe-rss">WeWeRSS</a>:将微信公众号转为 RSS feed。利用的是(逆向得到的)微信阅读的接口。酷,但账号失效太频繁,我不得不隔三差五就去重新扫码认证账号,维护成本太高。万恶的微信,</li> </ul> <h2>酷,且用得着</h2> <p>我的服务器上依然有一些我经常会用的 self-hosted 应用。这些应用一般必须依赖服务器,找不到非自部署的替代品,因此我依然保留。</p> <ul> <li><a href="https://docs.rsshub.app">RSSHub</a>:将任何网站转为 RSS feed。公共实例可能速度慢、不稳定,因此选择自部署。</li> <li><a href="https://github.com/Finb/Bark">Bark</a>:利用 APNs 给 iOS 推送通知。很好用。</li> <li><a href="https://headscale.net">Headscale</a>:开源 Tailscale 服务端,内置 DERP Server,非常好用。由于众所周知的原因,要想使用 Tailscale 必须自己部署节点。</li> <li><a href="https://matomo.org">Matomo</a>:我体验到的最为强大的网站监控工具。试用过 Plausible、Umami,功能都不如 Matomo 强大。(不过 Matomo 使用体验上比较一般)</li> <li><a href="https://archivebox.io">ArchiveBox</a>:将网页存档下来。在这个互联网快速崩塌的时代尤其重要。</li> <li><a href="https://www.min.io">MinIO</a>:兼容 S3 的对象存储。部署这个是为了做国内的图床镜像。虽然我主要使用 Cloudflare R2 作为图床,但由于众所周知的原因,国内访问速度似乎被刻意劣化了(实测下载 3mb 左右的图片需要二十多秒)。因此不得不在境内网络也建镜像。然而各大老牌云厂 S3 都不便宜,不如自己服务器上建一个,性价比最高。</li> <li><a href="https://caddyserver.com">Caddy</a>:能够自动申请 TLS 证书的 WebServer。配置简洁方便,一行配置即可反向代理启动一个网站。对个人而言,比 Nginx 好用太多了。特别是结合 <a href="https://github.com/lucaslorentz/caddy-docker-proxy">caddy-docker-proxy</a>,连配置 caddy 的工作都只需要在对应服务的 compose.yml 中完成。Self-hosted 玩家必备。</li> </ul> <p>自从工作后,属于自己的时间更加宝贵了,不像曾经能够花一下午的时间折腾某个细微的问题,这才更加理解诸如 Serverless 这种「将复杂度外包出去」服务的价值。现在我的数据库放在 Supabase,文件存在 Cloudflare R2,前端(海外)部署在 Vercel。不用花太多精力维护,能够信任它们的稳定性,我们能将精力花在更重要的地方。</p>