我是如何把整个数字技术栈迁移到欧洲的

原文来源：monokai.com — 一位独立开发者出于数字主权意识，花两个月将自己的全套技术基础设施从美国迁移到欧洲。

有一个版本的故事是这样开头：一张电子表格，然后是一种安静的满足感。实际上，故事的过程大致如此。但在用 SaaS 工具替换另一个的工具性操作背后，是一种更紧迫的感觉——我越来越不安地意识到，我的数字基础设施太多部分都放在自己无法控制的服务器上、放在一个越来越难以预测的司法管辖区里、由一些利益与我并不总是一致的企业运营。

数字主权（Digital sovereignty） 听起来像是个流行词，直到你认真思考它意味着什么。它意味着你知道自己的数据存在哪里。它意味着你不会因为一次政策变化、一次收购、或者一个高管的糟糕心情就失去对你业务所依赖的工具的访问权。它意味着基于价值观选择基础设施，而不仅仅是图方便。

于是，我开始迁移。

分析工具：从 Google Analytics 到 Matomo

Google Analytics 是第一个目标。它是「免费即你是产品」的典型代表，访问者的行为数据被源源不断地输送回 Google 的广告引擎。

自托管 Matomo 干净利落地解决了这个问题。数据留在我自己的服务器上，而且不需要 Google Analytics 那套烦人的 Cookie 同意弹窗就能完全符合 GDPR。报表全面，界面也足够熟悉，而且我拥有所有数据。

为此我新开了一台小服务器，不贵，但也不免费。主要的缺点是运维成本：更新、备份、保持服务器健康，这些现在是你的责任了。对大部分场景来说这算不上什么麻烦，但也不是零摩擦。

邮件：从 Gmail 到 Proton Mail

Proton Mail 总部在瑞士，不在欧盟境内，但瑞士隐私法律与 GDPR 高度一致，在某些方面甚至更强。Proton 的商业模式建立在隐私而非广告之上，端到端加密是内置在协议层面而非后期添加的。邮件客户端扎实，日历也做得好。对于任何想离开美国服务的人来说，它和本文其余部分的迁移方向是一致的。

有一点需要适应：Proton 的筛选系统比 Gmail 的限制更多。Gmail 几乎可以针对任何内容写过滤规则，包括邮件正文的全部内容。Proton 完全不支持基于邮件内容的过滤。如果你已经围绕捕捉邮件正文中的特定短语或关键词建立了工作流，那你就得重新考虑方案了。对大多数人来说这不算什么大问题，但迁移前值得知道。

还有一个实际的限制值得提：即使在 Duo 套餐上，Proton 也限制自定义域名不超过三个。如果你运行多个域名，比如为不同的项目或业务设置不同的地址，你会很快触顶，需要重新考虑如何路由和发送邮件。我最终做了合并——虽然这本来也是迟早要做的事——但这并不是一个完全自由的选择。

Proton 不是免费的，而且相比其他选项收费不低，不过你会获得整套 Proton 应用套件的访问权。

密码管理：从 1Password 到 Proton Pass

既然已经进入了 Proton 生态系统，把密码管理也搬过去是顺理成章的。Proton Pass 端到端加密、开源，并且受益于 Proton 套件相同的瑞士司法管辖权。

1Password 是一个真正出色的产品，这次迁移更多是横向移动而非升级。Proton Pass 界面简洁，浏览器扩展可靠，而且将密码、邮件和日历置于同一个加密屋顶下，有一种令人满意的连贯感。

计算：从 DigitalOcean 到 Scaleway

DigitalOcean 之所以赢得声誉，是因为它把一件事做得极其出色：不碍你的眼。界面干净，心智模型简单，启动基础设施从来不让人觉得是件苦差事。它证明了开发者体验可以成为一种竞争壁垒。

Scaleway 是一个令人愉快的惊喜。我原本以为会是一个能用但粗糙的欧洲替代品，结果发现这个平台的思考相当周全。服务器在自有配置的私有网络中快速启动，控制面板干净，可用选项完全满足了我的实际需求。Scaleway 在选择服务器位置时会同时显示预计的 CO₂ 排放量——一个不错的细节。

这实际上让我把大部分基础设施托管在了巴黎，因为那里的计算能耗最低。

对象存储：从 AWS S3 到 Scaleway S3

Scaleway 的对象存储与 S3 兼容，这使得迁移变成了机械操作而非痛苦过程——更新端点地址和凭证后，现有代码无需修改即可运行。

我用 rclone 将旧的 AWS S3 存储桶同步到新的 Scaleway S3 存储桶。由于这些存储桶相当大，持续同步花了一周多的时间。

异地备份：从 Backblaze B2 到 OVH

OVH 是欧洲最大的云服务商，其规模带来的可靠性和价格符合你的预期。它的对象存储作为备份目的地表现出色，配置生命周期规则将旧备份迁移到冷存储层后，成本比 Backblaze B2 更低。

然而，配置过程需要一些耐心。OVHcloud 控制面板像个迷宫：生命周期规则的配置埋藏在文档深处，还需要在终端中进行一些操作。一旦配置好，它能稳定工作，成本差异也很显著。

事务邮件：从 SendGrid 到 Lettermint

Lettermint 是一个欧洲的事务邮件服务，功能齐全而不臃肿。送达率可靠，API 干净，定价也很直接。

这次迁移让我削减了一些成本，因为我原来有两个独立的 SendGrid 账户，现在可以合并为一个。

和 SendGrid 相比，它的分析功能更精简，生态系统集成也更少。SendGrid 背后有多年积累的工具链、文档和社区答案。Lettermint 更新更小。对于大多数事务发送场景（密码重置、通知、收据），这问题不大。但如果你在做复杂的多流邮件基础设施，得先仔细审查功能集。

错误追踪：从 Sentry 到 Bugsink

Bugsink 是一个自托管的错误追踪工具，兼容 Sentry 的 SDK——迁移路径几乎是无缝的，改一行配置就行。

老实说：Bugsink 很简陋。没有性能监控、没有会话回放、没有高级告警。对于正确使用 Sentry 的团队来说，它不是 Sentry 的替代品。对我来说，它就是一个简单的远程错误日志——当生产环境出问题时，我得到堆栈跟踪，这就够了。Sentry 的云产品确实很优秀，对于大规模工程团队来说，其广度几乎肯定对得起成本。但如果你的用例只是「出问题了告诉我，并显示堆栈跟踪」，自托管的 Bugsink 完全能满足，而且数据不会离开你的基础设施。

AI API 集成：从 OpenAI 到 Mistral

对于 AI API 集成，我从 OpenAI 切换到了 Mistral。结果非常理想，因为我本来主要用的就是较简单的模型。

Mistral 总部位于巴黎，在提供 API 的同时还发布了令人印象深刻的开源权重模型。API 干净、模型快速且有能力，一个欧洲的 AI 提供商倾向于开放而非封闭，这一点有些内在的一致性。对于我的推理工作负载来说，这次切换在质量上是平移的，从资金流向角度则更有意义。

CDN：例外——仍然用 Cloudflare

不是所有东西都迁移了。Cloudflare 是一家美国公司，我仍然在使用它，而且我对此心安理得。

理由是这样的：Cloudflare 位于我的公网网站前面。它的工作是缓存、防御 DDoS 攻击、让全球访问者快速加载内容。流经它的数据从定义上来说已经是公开的了。我没有通过 Cloudflare 路由私人通信或敏感应用数据；我使用它来提供任何互联网用户都可以阅读的页面。当你保护的东西已经是公开的时，主权的计算方式是不同的。

我确实尝试过 Bunny CDN，这是一家欧洲公司，声誉很好。对于单纯的 CDN 使用来说它很出色。但 Cloudflare 的功能集（安全规则、Workers 平台、配置选项的广度）不足以让我为了特定的需求切换过去。有时候务实的答案胜出。

支付：例外——仍然用 Stripe

Stripe 是我尚未迁移的少数服务之一，尽管支付基础设施正是我希望放在可信司法管辖区的那类东西。Mollie 是一家荷兰支付处理器，拥有完整的欧盟法人资格、内置的强 GDPR 合规性以及近年来显著成熟的产品。其 API 在大多数常见支付流程上已经趋向于与 Stripe 持平。对于欧洲企业来说，它覆盖的区域支付方式（iDEAL、Bancontact、SEPA）甚至更好。

迁移在计划中。只是不是一件小事。支付集成涉及计费逻辑、Webhook、税务发票和面向客户端的流程，需要仔细测试并选好切换时机。而且，对我的使用场景来说，它比 Stripe 更贵。

AI 编码助手：从 OpenAI 到 Claude Code

这一项感觉早就该做了。OpenAI 用起来没问题，但公司的发展轨迹已经不再符合我个人的看法了。经过一段时间的犹豫，我觉得是时候切换了。理想情况下我想用 Mistral Vibe，但它未能达到标准——无法与 Claude 竞争。

Claude Code 现在是我日常编程的 AI 助手。推理能力强，上下文处理令人印象深刻，Anthropic 在安全性和透明度上的方法在结构上感觉更扎实。

Anthropic 是一家美国公司，所以这不符合我在其他地方应用的司法管辖权标准。但它满足了另一个标准——构建这个工具的组织对其正在构建什么以及为什么构建给予了认真的思考。

值得一提的是，本地模型正变得越来越可用。Qwen，阿里巴巴的开源权重模型系列，是一个很好的例子：它有能力处理许多真实工作负载，完全运行在你自己的硬件上，数据不会离开你的机器。前沿 API 模型和你可以在本地运行的内容之间的差距，缩小得比大多数人意识到的要快。

并非一切都理想。大多数数据中心仍然在欧洲之外，而且「开放」对不同组织意味着不同的东西。但方向是对的。一个世界里有能力的 AI 能在你自己的硬件上运行、权重公开、训练透明，这比所有推理都流经少数几家封闭 API 提供商的世界，对数字自主权要好得多。我们还没到那个地步，但趋势是令人鼓舞的。

Git 版本控制：例外——GitLab 和 GitHub

GitLab 暂时保留。GitLab 总部在美国，但提供自托管选项，而且在透明度和开源方面该公司一直有很强的承诺。自托管实例已在路线图上，但迁移源码控制的难度大多了。

GitHub 为了一个特定的目的保留：面向公众的 NPM 包和开源项目的 Issue 追踪。当你发布一个包或维护公共工具时，GitHub 是开发者期望找到它的地方。网络效应是真实的，那是 fork、star 和 Issue 报告的来源。对于开源工作的公开展示面，没有什么有意义的主权顾虑，而且有很多实际好处。

值得吗？

实际的摩擦是真实存在但可以管理的。大多数迁移只是花了一个下午的工作：这里更新一个凭证，那里修改 DNS 记录，导出导入一些数据。少数几个花了更长时间。没有一个是一场灾难。总的来说，花费的时间比预期的要长，但大部分时间花在了研究和规划上。两个月后，一切都在无事故运行。没有起火，没有后悔。

数字主权不是偏执。它是有意识地审视你的基础设施，由你决定谁持有你的数据、谁能访问它，以及当政治环境变化时会发生什么。工具就在那里。生态系统已经基本成熟。唯一阻碍我的是惯性。完全可以在主要依靠欧洲基础设施的情况下运行一个可靠、有能力、专业的技术栈。这次迁移就是证明。