Users are encountering a Bundler version warning during Discourse upgrades, which appears when the running Bundler version is older than the one that created the Gemfile.lock. watchmanmonitor initially reported the issue after upgrading a self-hosted site, noting the site functioned normally but the warning was concerning. codinghorror advised updating via SSH with git pull and ./launcher rebuild app, which resolved the issue. watchmanmonitor confirmed this fix worked but later encountered the same warning on another instance, questioning how to proactively detect outdated containers. sam and codinghorror clarified that rebuilding the container updates Bundler. Mittineague suggested the warning may stem from Bundler’s BUNDLED WITH feature, now removed from Discourse’s lockfile, making the warning misleading in production. gerhard confirmed the warning is harmless in Docker environments and stems from a recent change that removed BUNDLED WITH from the lockfile, advising users to ignore it during upgrades. The community agrees the warning is confusing and could be better handled by the Discourse team, especially since no admin notice alerts users to outdated containers. watchmanmonitor remains concerned about unpredictability during upgrades, as warnings only appear post-upgrade, requiring manual intervention.
On one of my self-hosted Discourse, (fully up to date docker_manager and a docker image only a few weeks old ) I just ran in this error upgrading. I don’t know what version the site was on before, but it was only about 30 commits behind on tests-passed.
The site seems to be fine & responding, but I figured I’d mention something before I ./launcher rebuild app
PS no, this isn’t the site I mess with server.en.yml, it’s just plain Discourse
This means you need to log in via SSH and do the classic 3-liner git pull , etc, to update the container.
ok, I didn’t see a notice in admin warning that my docker image was out of date, so I didn’t consider checking it.
# cd /var/discourse
# git pull
remote: Counting objects: 4, done.
remote: Total 4 (delta 2), reused 2 (delta 2), pack-reused 2
Unpacking objects: 100% (4/4), done.
From https://github.com/discourse/discourse_docker
9e83982..904f795 master -> origin/master
Updating 9e83982..904f795
Fast-forward
launcher | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
root@discuss:/var/discourse# ./launcher rebuild app
And, all seems to be well now.
So now I get this on another discourse I host..
$ cd /var/www/discourse && git fetch && git reset --hard HEAD@{upstream}
HEAD is now at fc090b4 FIX: With many stickies some latest posts got missed
********************************************************
*** Please be patient, next steps might take a while ***
********************************************************
$ bundle install --deployment --without test --without development
Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
How can be warned ahead of time that we need to update the container?
And, do we always need to rebuild after updating the container?
Rebuild their the container it will update bundler
I was 96 commits behind in a self-hosted forum, and just updated.
I got this bundler version warning again.. how can we warned ahead of time if our container is out of date?
(Didn’t we used to get this notice?)
Are you sure the container is out of date or if it’s Bundler having added “BUNDLED WITH” to the lock file?
I can’t find the discussion now, but AFAIK this was causing grief and it no longer does this.
Pretty sure bundler is out of date:
From may last one-click update:
$ bundle install --deployment --without test --without development
Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by runninggem install bundler.
But even if it’s just bundler being annoying.. I bet this is something the discourse team can make less confusing.
On my other two hosts where I did
Bundler must have been updated, because the issue goes away.
Correct, updating from the command line will update the docker image, etc.
One of my communities is 189 commits behind at the moment, I don’t see any notice that my container is out of date, but I don’t have any confidence that that bundler in use matches what’s current, or if it even matters.
Currently, I won’t know until I hit Upgrade, and get a warning. Then if I do, I’ll have to re-upgrade at the command line.
How are we supposed to predict what’s going to happen when I click Upgrade?
You won’t see one at the moment because the BUNDLED WITH in the Gemfile.lock got missing again (cc @eviltrout) 
No, it doesn’t matter when you are using the Docker container. It’s just an annoyance during development when there’s a version mismatch, but you can completely ignore it in production.
So, there’s no need to worry about Bundler when you click on Upgrade.