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.
בעבר יכולתי לבצע עדכון עם 2G RAM + 2G swap, אבל זה היה, אני חושב, לפני Ember, שדורש הרבה משאבים. אם יש לך מספיק מקום בדיסק כדי להגדיל את ה-swap ל-4G, זה עשוי לעבוד. לחלופין, תוכל להעביר באופן זמני ובזהירות לאינסטנס עם יותר RAM, לבצע את העדכון, ולהעביר בחזרה.
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.
שלי התחיל לעשות את זה גם כן, בסדר גמור במשך 4+ שנים ועכשיו זה נכשל. למרות שלפעמים זה טוען שהוא נכשל, וכשאני מרענן הכל מעודכן ואין מה לעדכן שוב. אבל זה כמעט תמיד מסתיים ב-
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Command failed with exit 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: FAILED TO UPGRADE
זה מה שתהיתי - אם זה קשור לבעיה בקוד עצמו ולא כל כך לחומרה של השרת שלי.
אני מניח שהאפשרות הבאה שלי היא פשוט לכתוב פלאגין משלי עם סקריפט כדי לעדכן את עצמי באופן ידני.
שמח שאחרים נתקלים באותה בעיה, כך שזה לא רק אני (אני יודע שזה מבאס). אולי מישהו שמפתח באופן פעיל עם Discourse יכול לבדוק את זה. אני גם מאחל שהיה מידע ניפוי באגים טוב יותר מעבר לזה שזה פשוט “נכשל”.
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!
********************************************************
*** يرجى التحلي بالصبر، قد تستغرق الخطوات التالية بعض الوقت ***
********************************************************
Cycling Unicorn، لتحرير الذاكرة
إعادة تشغيل Unicorn pid: 1580
في انتظار Unicorn لإعادة التحميل.
في انتظار Unicorn لإعادة التحميل..
في انتظار Unicorn لإعادة التحميل...
في انتظار Unicorn لإعادة التحميل....
في انتظار Unicorn لإعادة التحميل.....
في انتظار Unicorn لإعادة التحميل......
في انتظار Unicorn لإعادة التحميل.......
في انتظار Unicorn لإعادة التحميل........
في انتظار Unicorn لإعادة التحميل.........
في انتظار Unicorn لإعادة التحميل..........
في انتظار Unicorn لإعادة التحميل...........
في انتظار Unicorn لإعادة التحميل............
في انتظار Unicorn لإعادة التحميل.............
في انتظار Unicorn لإعادة التحميل..............
إيقاف 1 عامل Unicorn، لتحرير الذاكرة
إيقاف قائمة الانتظار لاستعادة الذاكرة، معرف العملية الرئيسي هو 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 complete! 160 Gemfile dependencies, 207 gems now installed.
Gems in the groups 'test' and 'development' were not installed.
Bundled gems are installed into ./vendor/bundle
3 installed gems you directly depend on are looking for funding.
Run `bundle fund` for details
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Scope: all 16 workspace projects
Lockfile is up to date, resolution step is skipped
Already up to date
Done in 2.9s using pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard is already at latest compatible version
docker_manager is already at latest compatible version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite migrator is running using 1 threads
Migrating default
Seeding default
*** Bundling assets. This will take a while ***
$ bundle exec rake themes:update assets:precompile
Updating themes with concurrency: 10
[db:default] 'Air Theme' - checking...
[db:default] 'Air Theme' - up to date
[db:default] 'Modern Category + Group Boxes' - checking...
[db:default] 'Modern Category + Group Boxes' - up to date
[db:default] 'Clickable Topic' - checking...
[db:default] 'Clickable Topic' - up to date
[db:default] 'Search Banner' - checking...
Node.js heap_size_limit is less than 2048MB. Setting --max-old-space-size=2048 and CHEAP_SOURCE_MAPS=1
Existing build is not reusable.
- Existing: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Current: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Running full core build...
Building
Environment: production
The setting 'staticAddonTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTrees: true' in your Embroider config.
The setting 'staticAddonTestSupportTrees' will default to true in the next version of Embroider and can't be turned off. To prepare for this you should set 'staticAddonTestSupportTrees: true' in your Embroider config.
building...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js as it exceeds the max of 500KB.
[BABEL] Note: The code generator has deoptimised the styling of /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js as it exceeds the max of 500KB.
...[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 Command was killed with SIGKILL (Forced termination): ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Command failed with exit 1: pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: FAILED TO UPGRADE
#<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>'
Spinning up 1 Unicorn worker(s) that were stopped initially
both in price and RAM, not to mention the disk space, etc.