MCP 目录迁到 TanStack 和 Railway

做 MCP 目录站的人大多会先选 Next.js + Vercel + Supabase：上手快、SSR 顺手、数据库也现成。流量上去之后，账单往往比功能更吵。wong2 把自家 MCP 导航站从这套迁到了 TanStack Start + Railway，目标很直接：每个月能不能少花大约 100 美元。

下面按「为什么换、怎么换、换完注意什么」写一遍，方便你自己做同类导航或内容站时对照。

为什么 Vercel + Supabase 会变贵

目录站的访问模式很典型：列表页、分类页、详情页、搜索，读多写少，但页面多、SSR 频繁。

Vercel 按带宽和 Serverless/Edge 执行计费，目录页一多，预览部署和 ISR/SSR 都会抬高成本。Supabase 的 Postgres、连接池、存储如果挂在免费档之外，再加带宽和备份，月费很容易到三位数。两家叠在一起，对独立开发者就不「轻」了。

Railway 这边更像传统 PaaS：按实际 CPU/内存/流量秒级计费，App 和 Postgres 放在同一个项目里，连接走内网，少一层跨云延迟和额外账单。TanStack Start 本身是 Node 服务形态，正好对上 Railway 的部署模型。

新栈各自干什么

TanStack Start 建立在 TanStack Router 上，带 SSR、streaming、server functions。构建产物一般是 Node 入口（常见路径 .output/server/index.mjs），不是一堆 Serverless Function，所以在 Railway 上当一个常驻服务跑更自然。

MCP 目录站需要的能力其实很克制：分类浏览、搜索、详情、偶尔写后台。这些用 Start 的 loader / server function 都能覆盖，不一定非要绑在 Vercel 的平台特性上。

迁移可以怎么拆

别一次改完。更稳的顺序是先复刻数据模型，再换框架壳，最后换托管。

1. 先复刻数据模型：把 Supabase 里的表结构（servers、categories、tags、提交记录等）导出 schema，在 Railway 新建 Postgres，用迁移脚本或 pg_dump / psql 灌进去。连接串改成 Railway 的 DATABASE_URL。

2. 再换框架壳：用官方脚手架起一个 Start 项目（create-start），安装依赖后本地跑起来。把原来 Next 的页面改成 Start 的文件路由：列表、分类、详情各一条。数据访问集中到 server function 或 API route，客户端只拿结果，别把数据库密钥塞进 VITE_ 前缀变量。

3. 最后换托管：本地能跑通后再推到 Railway。官方文档给了 CLI、GitHub、容器镜像三条路。CLI 最短，先 init 再 up。

部署完在服务 Settings 的 Networking 里 Generate Domain。端口默认 3000，记得让进程读 Railway 的 PORT 环境变量。在 app.config.ts 里把 server.port 设成 Number(process.env.PORT) 或回退到 3000。

容器镜像备一手

Railpack 偶尔认错启动命令时，用多阶段构建更省事：构建阶段装依赖并 build，运行阶段只拷贝 .output 与 package.json，用 node 启动 .output/server/index.mjs，监听 3000。TanStack Start（经 Vinxi/Nitro）打完包后入口就在这个文件。Railway 看到容器定义文件会优先用它构建。完整示例见官方文档 https://docs.railway.com/guides/tanstack-start

数据库怎么接到 Start

在 Railway 项目里新建 PostgreSQL，然后在 App 服务变量里引用 Postgres 服务的 DATABASE_URL。服务端路由里读 process.env.DATABASE_URL 即可。ORM 用 Prisma 或 Drizzle 都行。注意：只有 VITE_ 开头的变量会进前端打包，数据库相关一律留在 server。

从 Supabase 迁过来时，Auth、Storage、Realtime 如果还在用，要单独评估：Railway 不自带这些 BaaS 能力。纯目录站往往只要 Postgres；若依赖 Supabase Auth，可以暂时保留 Auth、只迁业务库，或换成自己的会话方案。别为了「全迁」硬拆登录。

成本上大概能省什么

具体数字因流量和套餐而异，迁移动机通常落在这几块：

• 少交平台溢价：Vercel 对 SSR/带宽敏感；Railway 按资源用量更线性。
• 数据库合包：App 和 Postgres 同项目，少一份独立托管账单和出口流量。
• 常驻 Node vs Serverless：目录站长连接、缓存、连接池更容易在一个进程里控住，而不是被请求次数放大。

wong2 的目标是月省约 100 美元。对个人项目来说，这已经够构成一次迁移的理由。上线后盯一两周账单和响应时间，比空谈「哪家更香」有用。

上线前检查清单

• 生产环境 DATABASE_URL 指向 Railway Postgres，本地 env 文件别提交
• 构建产物能用 node 单独启动 .output/server/index.mjs
• PORT 绑定正确，健康检查路径可访问
• 旧域名 DNS / 反代切到新域名，旧 Vercel 项目设只读或下线避免双写
• 搜索与分类页做一次全量点检（目录站最容易在路由参数上翻车）
• 备份：迁移前对 Supabase 做一次 dump，保留至少一周

小结

MCP 目录这类「读多写少、页面多」的站点，并不绑定 Next.js + Vercel + Supabase。换成 TanStack Start + Railway，框架侧保留 SSR 和类型友好的路由，托管侧换成按用量计费的 Node + Postgres，往往账单更可控。先迁数据、再换壳、最后切域名，比一口气重写稳得多。

参考：

• https://docs.railway.com/guides/tanstack-start
• https://mcpservers.org
• https://tanstack.com/partners/railway