Update metabase in docker

I’m currently trying to update my metabase instance which is running in docker. I tried it like this:

If you are running it via docker, then you simply kill the docker process, and start a new container with the latest image. On startup, Metabase will perform any upgrade tasks it needs to perform, and once it is finished, you’ll be running the new version.

Unfortunately this is not working, it’s still the old version.

How can I update?

Have you run something like docker pull metabase/metabase:latest? (simply running doesn’t pull a new version)

Many thanks, it worked! Obviously the upgrade procedure is not well described…

Glad to hear! It’s probably worth mentioning that you’d need to set up a volume for the Metabase database (or have it persisted outside the container somehow) before doing this – or you’ll lose information.

Seems like a small note could be added to the documentation to mention pulling the new version of the image before running…

Sorry for the trouble, guys. I’ll take a look at the documentation and see where we can clarify the upgrade process.

1 Like

Was this the specific doc page you were looking at, @jshort?


@maz that’s probably where @Dadash was looking? Either that or http://www.metabase.com/docs/latest/operations-guide/running-metabase-on-docker.html

The link you gave probably has the right wording already: “… simply kill the docker process, and start a new container with the latest image”; maybe the docker-specific guide can shed extra light on how to get the latest image?

1 Like

I’m a little bit hesitant to update metabasse using docker and maybe lose my configuration. I’ve got no experience with Docker so could anyone please give a step by step instruction?

The upgrade docs says:

you simply need to kill the Docker process and start a new container with the latest Metabase image

but it isn’t described what we should type exactly and in which order into the command line. It’s probably really simple but I’m not sure how to do this. I could also not find any other topics that lays out these steps.



You shouldn’t be using H2 in production, so if you’re using Postgres/MySQL, then the Metabase container is just an application and can be destroyed, since the settings/metadata is stored in the external database.

Just remember to always backup before doing major changes, so you can always revert.

If you decided to use Docker, then you should really read the documentation, so you’re comfortable with how it works - upgrading containers is not unique to Metabase:

Without knowing your container names, you would do something like this (ref):
docker stop metabase
docker rm metabase
docker pull metabase/metabase:latest
docker run -d -p 3000:3000 --name metabase metabase/metabase … (I don’t know your run config)

Thanks for your response. I am not using H2 as the data source, I’m using MySQL and Google Analytics as database sources.

I’m just not sure where the metabase dashboard config (not the actual data) like questions, dashboard names, pulses, etc are stored. If I upgrade the container like you described above, will I lose this config?

If not I will continue using your above example, I have used all default names for docker. I have made a backup.

H2 is the default internal database (not a data source). That’s where all settings and metadata is stored.
So since you don’t know, then I would guess you’ll lose everything on upgrade, since by default the H2 is located inside the container.

I think this is unnecessarily complicated for users like me. Almost everything about metabase is very user friendly and easy to understand, except upgrading for some reason. I would prefer just clicking on update, and it will do the work for me. Or better even, just upgrading automatically in the background without clicking update or me even noticing it.

There is probably some reason for it that that is not the case now, but from a users perspective that would be the best solution imo.

1 Like


Having Metabase “magically” upgrade would be a really bad idea. The only time where you want auto-upgrade is for security, not when an application introduces new features.
Metabase is being used by all sizes - so from a single user running it to big companies with thousands of users running on multiple servers.

Since Metabase is essentially a JAR-file, a feature like auto-upgrade would be really difficult. There’s probably ways around this, but that would require another service running that would take care of the upgrade.

You can just use the JAR-file instead of Docker, which would mean that you simply download and replace the existing JAR-file and that would be the upgrade.

H2 was chosen because you could start using Metabase really fast, with almost zero configuration. But if you started to use Metabase in production, then you should move to a different backend database (as noted many times in the documentation).
If you want to continue using H2, you can even place the database outside of the container, so you’re not destroying it, when upgrading - but that would still be using H2, which is not recommended for production, since it doesn’t handle corruption very well.

So having an easy-upgrade-feature, would mean that the setup process would become more difficult.

1 Like

I’ve done the upgrade and migration away from H2 like the docs describe, but have found out that I can’t login to the new container via the website (localhost:3000) since one of the configs isn’t reading right. So with a fast set up, there does need to be a warning or two in the UX that say - “don’t configure this without migrating off H2” or something.

There should be no differences between the H2 and whichever database you chose.
You should probably start a new thread and post more details like versions, which database and logs.
But it’s possible to run with H2 - just make sure your computer/server never crashes or shutdown because of power problems.
The documentation has multiple sections about not using H2 in production.
The log has a big warning on startup about not using H2 in production.

Thanks @flamber! We finally just re-configured from zero in Postgre for the session we’re building. Now we’re on to figuring out how to implement Charts.

I know this is fairly old, and having looked at the documentation mentione here, I too am using Docker to run metabase. The documentation appears to be directed at the use of metabase installed directly to the server it’s running on, and the commands don’t seem to take into account H2 in docker and MySQL on the native OS. Is there any difference in the migration commands and environment variables used when Docker is in play?

@bmcgonag Let’s continue in your own topic: Run the Migration from H2 to MySQL from inside Docker?

Hello, community! I'm new to metabase and was trying to update to a newer version.
Here're the commands I've used:

docker stop aca7dade0d15
docker pull metabase/metabase:latest
docker rm aca7dade0d15
docker run -d -p 3000:3000 -e MB_DB_CONNECTION_URI="jdbc:postgresql://<host>:5432/metabase?user=<username>&password=<password>" --name metabase metabase/metabase:latest

But now there's nothing on the ip adress I used to have it (error connectionfailure).
The instance is active in docker (having a new id though). What am I doing wrong?

@alexpti4ka Unless you provide static IPs to your container, then it will get an automatic IP, which you can see with docker ps https://docs.docker.com/config/containers/container-networking/