The redeploy is actually working, but the Railway template is stuck using an old prebuilt image (ghcr.io/railwayapp-templates/chatwoot:Community). That’s why you are still seeing the older v4.11.1 build on your end.

Can you update the template or switch the Dockerfile to pull directly from official Docker Hub? (e.g., chatwoot/chatwoot:latest-ce or v4.14.1-ce).

You will also need to make sure it kicks off bundle exec rails db:chatwoot_prepare post-update to handle the database migration.

This is a Railway template, I'm expecting them to update it.

Excuse me, just wanted to add a bit more context to this based on the repository's build files. Hopefully, this might help shed some light on what is happening behind the scenes.As correctly pointed out, the Dockerfile used directly by the Railway template is just a single line pulling the pre-built image from GHCR: FROM ghcr.io/railwayapp-templates/chatwoot:Community. Because of this, triggering a manual redeploy on the Railway dashboard unfortunately won't change anything on our end until that underlying GHCR image itself gets updated. Looking at how that GHCR image is generated, the Dockerfile.Community file pulls chatwoot/chatwoot:latest-ce from Docker Hub as its base, installs multirun and postgresql-client, copies start.sh, and sets up the entrypoint. The Enterprise setup follows the exact same logic using the standard latest tag. However, if we look at the main .github/workflows/build.yml file, the Build and Publish step currently doesn't include the pull: true and no-cache: true flags. Without these, even though the GitHub Actions workflow runs successfully every single day on a schedule, Docker Buildx might inadvertently reuse a cached layer of the older base image instead of checking for newer upstream layers. This is likely why the resulting GHCR image remains stuck on an older version. To ensure that each automated daily build genuinely fetches the freshest upstream image, we might just need to update that specific step in build.yml to look something like this (YAML) :

• name: Build and Publish

uses: docker/build-push-action@v5

with:

file: ${{ matrix.dockerfile }}

platforms: linux/amd64

push: true

pull: true

no-cache: true

tags: ghcr.io/${{ github.repository }}:${{ steps.extract_version.outputs.version }}

Since the official Chatwoot repository has already progressed well past v4.11.1 (currently at v4.14.0 as of May 2026), the latest-ce tag on Docker Hub is definitely pointing to a newer release. The gap we are seeing is most likely just due to this caching behavior during the GHCR build pipeline rather than upstream delays. Once these flags are added and the workflow runs again, any subsequent redeploy on Railway should immediately pick up the correct, updated version. Hopefully, the maintainers can take a quick look at this whenever they have some time.Hope this helps!

If you are using source image from https://hub.docker.com/layers/chatwoot/chatwoot/latest-ce you need to handle db operations. That's why it's not working. You may need to add below commands in predeploy steps.

bundle exec rails db:chatwoot_prepare

bundle exec rails db:migrate

I'm using the template provided by Railway

https://github.com/railwayapp-templates/chatwoot

Same here, it appears this template isn't getting updates anymore.