Discourse 側の問題軽減に役立つかもしれない追加情報があります。私のインスタンス（DigitalOcean の約 1GB ドロップレット、2GB スワップ付き）では、最近再構築に著しく時間がかかるようになり、4 回に 3 回の割合で同じ致命的なエラーが報告されています（./launcher cleanup を実行すると運が良くなるようですが、これを確定するにはサンプルサイズが不足しています）。
ヒープメモリ不足のエラーの直前に、次の行がログに記録されます。
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
私はこの分野の専門外なので、何か間違っていたら申し訳ありません。簡単な調査によると、ember-cli は node.js に依存しているため、これが関連していると考えています。--max-old-space-size フラグは、RAM よりも高く設定できる可能性があります（単にスワップスペースに入るだけで、前述のようにこの場合は問題ありません）。したがって、1024 は Discourse の再構築が収まらなくなった人工的な上限である可能性があります。
補足： apparently --optimize-for-size はメモリ使用量を削減するのに役立つ node.js フラグです（Discourse/ember によって使用されているかどうかはわかりませんが、おそらくすでに使用されています）、また、一部の node.js の使用ではガベージコレクタが有効になっていないという逸話があり、これは問題である可能性があります。
もしこれが ember/node.js の使用における Discourse 側から制御可能で関連性がある場合、誰かが調査する価値があるかもしれません。そうでなければ、心配しないでください。上記で提案されている一時的な 2GB アップグレードソリューションを実行します。