Vercel如何处理.env/secret变量？自建克隆的技术实现问询

一、Secret 的存储逻辑 #

Vercel 不会把用户提交的 API_KEY、DB_URL 这类敏感变量明文存储，更不会直接写入项目目录的 .env 文件。核心做法是：

• 用户提交 secret 时，立即通过AES-256 对称加密（结合信封加密机制，加密密钥与密文分开存储）处理后，存入内部加密数据库。
• 所有操作全程无明文留存，甚至 Vercel 内部人员也无法直接查看用户的明文 secret，权限体系严格限制只有项目授权人员能修改或触发解密流程。

二、构建阶段的变量注入 #

当触发项目构建时，Vercel 会跳过生成 .env 文件的步骤，直接通过进程内存注入变量：

• 构建容器启动后，Vercel 的调度服务会根据项目关联的 secret 列表，批量解密对应变量。
• 解密后的变量直接作为构建进程的环境变量传递（比如给 npm run build 或自定义构建命令），进程可通过 process.env.XXX 直接访问，但这些变量完全在内存中流转，不会落地到容器的文件系统。
• 同时，Vercel 会自动扫描构建日志，对疑似敏感内容进行打码，避免 secret 意外泄露到日志中。

三、运行阶段的变量处理 #

根据项目类型的不同，运行时的变量注入逻辑略有差异：

1. 静态站点 #

只有带 NEXT_PUBLIC_ 前缀的公开变量会在构建时被替换到静态代码中（因为静态文件会暴露给客户端），敏感 secret 不会被注入到静态产物里——如果静态站点需要调用敏感服务，必须通过 Vercel 的 Serverless/Edge 函数作为中间层转发。

2. Serverless/Edge 函数 #

函数实例启动时，Vercel 的执行环境会从加密存储中解密所需的 secret，直接注入到函数进程的环境变量中。函数执行完毕后，实例会被销毁，内存中的变量也会被清除，不会残留到后续请求中。

3. 部署后的全栈应用 #

对于部署后的后端服务，变量同样是在服务启动时动态注入进程环境，不存在本地 .env 文件，彻底避免了文件泄露的风险。

四、为什么不建议用 bcrypt 处理 secret #

bcrypt 是哈希算法，不可逆，适合存储用户密码（只需要验证匹配，不需要还原明文）。但 API_KEY、DB_URL 这类变量需要在构建/运行时使用明文，用 bcrypt 哈希后无法还原，完全不适用。Vercel 采用的是可解密的加密方案，既能保证存储安全，又能在需要时获取明文供进程使用。

核心流程总结 #

1. 存储：用户提交的 secret 立即加密，无明文留存
2. 构建：解密后注入构建进程内存，不落地磁盘
3. 运行：根据服务类型动态注入变量，用完即销毁

内容的提问来源于stack exchange，提问作者rutujp78