在railway.app部署Rails应用如何同时运行web与Sidekiq进程

Railway使用Buildpacks部署时，单服务实例默认只会执行Procfile中声明的单个进程，要同时运行Puma（web服务）和Sidekiq（worker进程），有两类成熟方案可选：

方案一：拆分双服务部署（生产环境首选） #

这是官方推荐的生产级实现方式，不需要修改项目内原有Procfile的多进程配置，直接在平台侧拆分两个独立服务即可：

• 在Railway项目控制台新建第二个服务，关联和web服务完全相同的代码仓库，两个服务共享同一套项目环境变量、同一个Redis插件实例
• 分别给两个服务设置独立启动命令，不需要依赖Procfile的进程声明：
  • web服务启动命令设为 bundle exec puma -C config/puma.rb，正常配置端口映射、域名绑定规则
  • worker服务启动命令设为 bundle exec sidekiq，不需要配置对外暴露端口
• 这种方案的优势是两个进程资源完全隔离，Sidekiq消费长任务、内存占用过高时不会拖垮web服务，两边日志独立存储查看，故障排查效率高，也支持单独给worker扩容实例数适配任务峰值。

方案二：单实例通过进程管理工具拉起多进程（仅适合低流量测试场景） #

如果不想额外创建服务，要在单个实例内同时运行两个进程，不要直接在Procfile写两个进程条目，通过进程管理工具统一拉起：

1. 保留原Procfile内的两行进程配置不变
2. 安装进程管理工具（推荐Overmind，兼容性更好），可以通过追加自定义Buildpack的方式让部署时自动安装，不需要手动修改服务器环境
3. 修改Procfile的启动入口为单条指令，调用进程管理工具读取Procfile内的所有进程配置启动：

web: bundle exec overmind start -f Procfile

注意：不推荐使用shell脚本直接后台拉起进程的写法（比如先把sidekiq放到后台执行再启动puma），这种写法没有进程守护能力，Sidekiq崩溃后不会自动重启，也没有资源管控，出问题很难定位。

• 这种方案缺陷很明显：两个进程共享单实例的CPU、内存资源，Sidekiq任务峰值很容易抢占web服务资源导致请求超时，两边日志混在一起排查困难，只适合个人测试项目临时使用，不要用于生产环境。

配置校验注意点 #

不管选哪种方案，都要确认以下配置正确：

• 两个进程的RAILS_ENV、SECRET_KEY_BASE等核心环境变量完全一致
• Sidekiq配置的Redis连接地址和web服务使用的是同一个Redis实例，网络策略放通两个服务/进程到Redis的连接

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