[Feature] Remove all vectors for manual updates

[Fmstrat]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Immich is a containerized deployment, there should be no requirements for systems to do manual updates. As an example, with https://github.com/immich-app/immich/releases#release-v3.0.0:

First, update the IMMICH_VERSION in your .env file to v3:

• IMMICH_VERSION=v2

• IMMICH_VERSION=v3

If this value needs to be changed, it should be stored in the database and updated via a migration script. Or, better yet, don't use it at all since the container already knows what version it is.

v3.0.0 drops support for pgvecto.rs. If you run Immich before v1.133.0 and haven't done the migration step yet, see the migration guide here. https://docs.immich.app/install/upgrading/#migrating-to-vectorchord

Immich is already using it's own container for PG (ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0), so the addition of custom command and healthcheck in Docker Compose could be handled in the Dockerfile via CMD and HEALTHCHECK.

Note: I understand manual steps such as shifting from the Docker hosting PG to the Immich provided one would still be required, but that shift is a great example of eliminating the manual update requirements. And while pinning versions is a good thing to do in prod environments, ensuring all Immich containers have a latest (or stable, etc) tag for the version of all containers that should be supported together in production should exist (if they don't).

Platform

• Server
• Web
• Mobile

[bo0tzz]

IMMICH_VERSION is setting the image tag that you're telling the system to pull, it has nothing to do with the database or with the container knowing its own version.

ensuring all Immich containers have a latest (or stable, etc) tag

We have a release tag, but using rolling tags is bad practice and we generally recommend pinning a specific version.

[Fmstrat]

Ahh, I had not realized some tags were directly in the compose file, and others were in the .env, that was unexpected. (I host by pinning SHA, so it didn't occur to me, my bad on that one).

It's good to know on the release tag, as now I can target my orchestration on that tag for grabbing the pinned SHAs on update.

While it sounds like the other one is pretty straightforward Dockerfile changes, I was more creating this as a request to identify where future items might come up to make automated orchestration function in systems that provide it.

Thanks!

[Fmstrat]

@bo0tzz why was this closed? There are still items like the Dockerfile update.

[bo0tzz]

There are no cmd/arg in our default compose file, and the healthcheck block is just there to enable it which doesn't happen by default.