我看到这个问题：git push heroku 之后 - Heroku 上传的文件丢失了
每次应用程序在处于非活动状态后关闭并重新启动时 x 分钟(，您的应用程序将重新创建，并且所有存储的数据都是 失去。(三(
现在我有用户可以上传两张照片。我收到了新用户的电子邮件确认。所以我可以检查用户在 4 小时和 14 小时前注册并上传的照片。我已经进行了最后一次提交，并在大约 19 小时前将其推送到 heroku。而新用户上传的这 4 张图片现在丢失了。但是如果我刚刚注册用户，我可以看到图像。因此，我的应用程序处于非活动状态 x 分钟，然后重新启动并删除图像似乎是真的。
我读过一些这样的问题 Rails]在 heroku 上重新提交后删除的图像那里说我应该使用像aws s3这样的外部服务器(我不知道它是什么，要花多少钱以及如何连接它(那么真的是这样吗？我还有什么其他选择？也许我应该简单地使用数字海洋(不会有同样的问题吗？(或其他东西。这个问题会在付费帐户中继续存在吗？
我使用 rails 并使用 carrierwave gem 上传文件，我无法在此处上传代码，因为我是从另一台笔记本电脑写入的。
Heroku 的文件系统是只读的。你不能指望你上传的任何内容都在那里，你需要使用外部存储机制，比如亚马逊的S3。
有关更多详细信息，请参阅链接。
https://devcenter.heroku.com/articles/s3https://devcenter.heroku.com/articles/dynos#isolation-and-security
运行 Heroku 实例的文件系统不是只读的，但它是暂时的 - 即您存储在那里的文件在实例重新启动后不会保留。
这是 Heroku 深思熟虑的设计决策，旨在迫使您考虑存储数据的位置以及它如何影响可扩展性。
您正在询问数字海洋 - 我没有使用过它们，但我从您的问题中假设它们允许您存储到持久的本地文件系统。
然后你必须问的问题是：如果要运行应用程序的多个实例，会发生什么情况？它们是否共享相同的持久文件系统？他们可以访问彼此的文件吗？当多个应用程序实例使用相同的文件系统时，如何处理文件锁定以避免争用条件？
Heroku的模型迫使你要么把东西放在数据库中，要么使用一些外部服务来存储它。通常，这些类型的系统中的任何一种都是合理的可扩展的 - 您可以拥有多个 Heroku 实例(可能在不同的机器、不同的数据中心等上运行(，并且它们都将很好地交互。
我确实同意，对于一个简单的用例，您只想在开发过程中运行应用程序的单个实例，这可能很不方便，但我认为这就是它背后的原因 - 强迫您设计这种东西，而不是在假设它可以在本地存储所有内容的基础上开发整个应用程序，然后发现您需要完全重新设计以使其可扩展。
你看到的是 Heroku 中称为ephemeral file system的东西：
每个测功机都有自己的
ephemeral filesystem，以及最近部署的代码的新副本。在测功机的生命周期内，其正在运行的进程可以使用文件系统作为临时暂存器，但是写入的文件对任何其他测功机中的进程都是可见的，并且在测功机停止或重新启动时，写入的任何文件都将被丢弃
简而言之，这意味着您上传的任何文件只会持续到测功机运行时。当dyno关闭时，文件将被删除，除非它们是local git存储库的一部分。
解决此问题的方法是将文件存储在第三方服务上 - 通常为 S3 。这会将文件存储在独立于 Heroku 的系统上。
Paperclip&Carrierwave都支持S3(简单存储服务( - 通过一个名为fog的Gem。S3为您提供了一个"免费"层，允许您免费存储一定数量的数据(我忘记了多少(。
我强烈建议设置一个 S3 帐户并将其链接到您的 Heroku 应用程序。这样，您上传的任何文件都将存储在异地。