When updating using the UI updater in the admin section - It always fails. It has failed since I installed Discourse over a year ago. I can easily SSH into my server and update manually, but it is frustrating to have a feature that is not behaving correctly.
Since Discourse is ran with Docker, and I am not strongly knowledgeable with it, I would like to know if anyone has any issues like this as well, and how can I fix it.
In Short: UI Updater Fails always, Command Line works first try and I would like to fix it where I do not have to SSH into the server (as often).
I realize after doing some digging it could be that I am using the bare bones amount of RAM recommended but, this is for a private install with less than 50 users, so I really do not need to go above the minimum for my use case.
Vroeger kon ik een update uitvoeren met 2G RAM + 2G swap, maar dat was, denk ik, vóór Ember, wat erg veeleisend is. Als je de schijfruimte hebt om naar 4G swap te gaan, zou dat kunnen helpen. Of, migreer tijdelijk en voorzichtig naar een instantie met meer RAM, voer de update uit en migreer terug.
Wat je ook doet, maak een back-up en download deze eerst.
Merk op dat de meeste providers je toestaan om naar dezelfde schijf of een grotere schijf te migreren. Je kunt niet naar een kleinere schijf migreren. Je moet dus een aanbieding vinden die meer RAM heeft, maar dezelfde schijfruimte.
Uiteindelijk ben ik van provider veranderd om een grotere machine te krijgen tegen lagere kosten. (4G RAM en 40G schijf)
In the US market, both Contabo and IONOS allow inbound port 25, which is critical for mail-receiver configurations — so there’s no functional limitation there.
The real difference lies in reliability and support reputation:
Contabo (Trustpilot 4.2/5, ~6,700 reviews) offers aggressive pricing and high specs, but US-based users often report high latency, slower support response, and performance instability, especially under load. Contabo’s US data centers exist, but they’re not always as responsive as expected.
IONOS (Trustpilot 4.5/5, ~31,000 reviews) performs better in the US than many assume. It has a stronger support reputation and more reliable infrastructure, with fewer 1-star reviews (~10% vs Contabo’s 16%). Users consistently report better uptime, live support, and account management compared to Contabo.
Conclusion (US):
If you’re US-based and need stability, fast support, and low risk for production workloads, IONOS is the safer pick. Contabo may still be worth considering for dev/test environments or cost-sensitive deployments, but expect trade-offs in latency and support quality.
Het mijne begon er ook mee, al meer dan 4 jaar helemaal prima en nu faalt het. Soms geeft het aan dat het faalt, maar als ik ververs is alles up-to-date en is er niets meer te updaten. Maar het eindigt bijna altijd met
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Commando werd beëindigd met SIGKILL (Geforceerde beëindiging): ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Commando mislukt met exit 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: FAILED TO UPGRADE
Dat vroeg ik me ook af - of het te maken had met een probleem met de code zelf en niet zozeer met de hardware van mijn server.
Ik denk dat mijn volgende mogelijkheid is om mijn eigen plugin te schrijven met een script om mezelf handmatig bij te werken.
Blij dat anderen hetzelfde probleem hebben, dus het ben ik niet alleen (ik weet dat het vervelend is). Misschien kan iemand die actief ontwikkelt met Discourse ernaar kijken. Ik wou ook dat er betere debug-informatie was, meer dan dat het gewoon “faalt”.
I’m not a developer or an expert when it comes to servers and all that. I went with Digital Ocean, just because it was the one mentioned in the official installation instructions, and because I’ve seen that name mentioned over and over again over the years.
At the moment I’m on the second lowest plan which is $6 a month for a server that seems to be way “slower” than the ones offered by Contabo or IONOS. Since the minimum for a good Discourse performance is at least 2GB of RAM, I would have to upgrade the $12 plan. For the Contabo $4.95 a month, I would get 8GB… it’s a “small” difference both in price and RAM, not to mention the disk space, etc.
So, asking you and any other users who are experienced, does it make sense that I migrate my Discourse to Contabo, for example, instead of staying with Digital Ocean? Even though I’m still building the whole community and all that, so far DO has been ok, apart from the issue of updating Discourse on the web, even with a swapfile of 4GB (because my disk space is just 25GB), but I don’t want to migrate everything to then start noticing other issues.
I found this page, but I’m not sure how reliable these tests really are and if they are enough to make me switch?
Any feedback would be greatly appreciated!
Thanks!
********************************************************
*** Wees geduldig, de volgende stappen kunnen even duren ***
********************************************************
Cycling Unicorn, om geheugen vrij te maken
Unicorn herstarten pid: 1580
Wachten tot Unicorn herlaadt.
Wachten tot Unicorn herlaadt..
Wachten tot Unicorn herlaadt...
Wachten tot Unicorn herlaadt....
Wachten tot Unicorn herlaadt.....
Wachten tot Unicorn herlaadt......
Wachten tot Unicorn herlaadt.......
Wachten tot Unicorn herlaadt........
Wachten tot Unicorn herlaadt.........
Wachten tot Unicorn herlaadt..........
Wachten tot Unicorn herlaadt...........
Wachten tot Unicorn herlaadt............
Wachten tot Unicorn herlaadt.............
Wachten tot Unicorn herlaadt..............
1 Unicorn worker(s) stoppen, om geheugen vrij te maken
Job queue stoppen om geheugen vrij te maken, master pid is 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD is now at 20ff23ed0 DEV: remove redundant translations for disabled new topic btn (#33929)
$ bundle install --retry 3 --jobs 4
Bundle compleet! 160 Gemfile dependencies, 207 gems nu geïnstalleerd.
Gems in de groepen 'test' en 'development' zijn niet geïnstalleerd.
Gebundelde gems zijn geïnstalleerd in './vendor/bundle'
3 geïnstalleerde gems waar je direct van afhankelijk bent zoeken financiering.
Voer `bundle fund` uit voor details
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Scope: alle 16 workspace projecten
Lockfile is up-to-date, resolutie stap wordt overgeslagen
Al up-to-date
Klaar in 2.9s met pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard is al op de nieuwste compatibele versie
docker_manager is al op de nieuwste compatibele versie
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite migrator draait met 1 threads
Migreren van default
Seeden van default
*** Assets bundelen. Dit duurt even ***
$ bundle exec rake themes:update assets:precompile
Thema's updaten met concurrency: 10
[db:default] 'Air Theme' - controleren...
[db:default] 'Air Theme' - up-to-date
[db:default] 'Modern Category + Group Boxes' - controleren...
[db:default] 'Modern Category + Group Boxes' - up-to-date
[db:default] 'Clickable Topic' - controleren...
[db:default] 'Clickable Topic' - up-to-date
[db:default] 'Search Banner' - controleren...
Node.js heap_size_limit is minder dan 2048MB. Instellen van --max-old-space-size=2048 en CHEAP_SOURCE_MAPS=1
Bestaande build is niet herbruikbaar.
- Bestaand: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Huidig: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Volledige core build uitvoeren...
Bouwen
Environment: production
De instelling 'staticAddonTrees' zal standaard true zijn in de volgende versie van Embroider en kan niet worden uitgeschakeld. Om hierop voor te bereiden, moet u 'staticAddonTrees: true' instellen in uw Embroider configuratie.
De instelling 'staticAddonTestSupportTrees' zal standaard true zijn in de volgende versie van Embroider en kan niet worden uitgeschakeld. Om hierop voor te bereiden, moet u 'staticAddonTestSupportTrees: true' instellen in uw Embroider configuratie.
bouwen...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Opmerking: De code generator heeft de styling van /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js gedeoptimaliseerd omdat deze de limiet van 500KB overschrijdt.
[BABEL] Opmerking: De code generator heeft de styling van /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js gedeoptimaliseerd omdat deze de limiet van 500KB overschrijdt.
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Commando werd beëindigd met SIGKILL (Geforceerde beëindiging): ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Commando mislukt met exit 1: pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: UPGRADE MISLUKT
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
1 Unicorn worker(s) opstarten die aanvankelijk gestopt waren
both in price and RAM, not to mention the disk space, etc.