我刚好折腾过类似的低成本部署场景，来给你分享下实际能跑起来的最小配置——毕竟谁不想省点AWS账单呢😉

理论硬件下限（能启动的最小资源） #

Ruby和Rails本身对硬件的要求其实很低，官方文档没明确写是因为不同场景差异太大，但实际测试下来：

• 内存：纯Rails应用（无额外数据库）启动后大概占用150-200MB内存，加上基础系统开销，256MB是理论下限，但实际运行会非常紧张，容易触发OOM（内存溢出）。
• CPU：单核CPU完全够用，哪怕是最低频的通用处理器都能支撑简单的请求处理。

AWS EC2对应实例推荐（实际可运行） #

结合AWS的实例类型，最适合的低成本选择是：

• t3.nano：0.5vCPU + 512MB内存。这是AWS当前最小的通用实例，我自己亲测用它跑过Rails 7的简单项目（带SQLite数据库），只要做了优化完全能正常运行，供几个评审访问完全没问题。
• 备选：t3.micro：1vCPU + 1GB内存。如果你的项目用了PostgreSQL这类需要额外内存的数据库，或者要加Nginx反向代理，这个实例会更稳妥，不会轻易因为内存不足崩溃。

让小实例跑起来的关键优化操作 #

要让这么小的实例支撑Rails应用，这些优化是必须的：

• 精简Rails配置：在config/environments/production.rb里：
  • 开启类缓存和预加载：config.cache_classes = true、config.eager_load = true
  • 关闭资产调试：config.assets.debug = false，并预编译资产（rails assets:precompile）
  • 关闭不必要的中间件，比如不用Active Storage可以直接移除相关配置
• 调整Web服务器参数：用Puma的话，把进程和线程数降到最低：

  # config/puma.rb
  workers 0 # 单进程，多进程会占用更多内存
  threads 1, 1 # 单线程
  bind "tcp://0.0.0.0:3000"
  

• 用轻量数据库：评审场景不需要复杂的数据库集群，SQLite足够，它是文件型数据库，不需要单独的服务进程，能省大量内存。如果必须用PostgreSQL，记得把shared_buffers调到64MB左右（在postgresql.conf里）。
• 启用Swap分区：小实例内存不够，创建一个Swap文件能有效防止OOM：

  sudo fallocate -l 1G /swapfile
  sudo chmod 600 /swapfile
  sudo mkswap /swapfile
  sudo swapon /swapfile
  

• 清理系统冗余：禁用不需要的systemd服务（比如systemctl disable --now postfix这类默认启动的服务），定期清理日志文件（sudo journalctl --vacuum-time=1d）。

注意事项 #

• 这种小实例只适合低访问量场景（比如几个评审同时访问），如果访问量稍大就会卡顿甚至崩溃。
• 如果要对外提供更稳定的访问，建议加上CloudFront做CDN，同时把静态资源托管到S3，减少实例的负载。

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