# Images and releases

> How Grovs images are tagged on GHCR, and how to select a release or follow the latest one.

Source: https://docs.grovs.io/docs/self-hosting/configure/images

## Images

| Services                         | Image following the latest stable release |
| -------------------------------- | ----------------------------------------- |
| API, migrations and both workers | `ghcr.io/grovs-io/backend:latest`         |
| Dashboard                        | `ghcr.io/grovs-io/dashboard:latest`       |

Each release also publishes matching numbered tags, such as `ghcr.io/grovs-io/backend:2.3.1` and `ghcr.io/grovs-io/dashboard:2.3.1`. Always update the backend, workers and dashboard together.

## Select the latest release

The [latest completed release](https://github.com/grovs-io/self-host/releases/latest) is the source for every install guide. It is published after both images are available. This lookup prints its version when you run it, so the guides never need a version edit:

```bash
GROVS_RELEASE_URL="$(curl -fsSL -o /dev/null -w '%{url_effective}' https://github.com/grovs-io/self-host/releases/latest)"
printf 'GROVS_VERSION=%s\n' "${GROVS_RELEASE_URL##*/}"
```

The platform guides pass this version to setup as `GROVS_VERSION`. Setup saves it in the generated environment file, so both images use the same numbered tag. To pin a specific release, pass its version instead.

For a fresh local or server install, the installer attached to the latest release already selects its matching images:

```bash
curl -fsSL https://github.com/grovs-io/self-host/releases/latest/download/install.sh | bash
```

- An exported `GROVS_VERSION` overrides the installer's default. Unset it to get the installer's release.
- The installer downloads stack files from `main`. Its release version selects the application images.

## Existing installations

Setup preserves an existing environment file, so looking up a new version does not change the saved value. Set `GROVS_VERSION` in the file, then follow [Upgrades](https://docs.grovs.io/docs/self-hosting/operate/upgrades).

For Railway and Render templates, update the service image references. A runtime environment variable does not change the image being deployed.

## Follow the latest tags

For Compose installations that should take the newest images on each upgrade, set this in the existing `.env` or imported platform environment:

```dotenv
GROVS_VERSION=latest
```

This selects the two `:latest` images above.

| Flow                                                           | Accepts `latest`?                                   |
| -------------------------------------------------------------- | --------------------------------------------------- |
| Existing Compose installation (`.env` or platform environment) | Yes                                                 |
| Railway template services and Render Blueprint                 | Yes, as full `:latest` image references             |
| Setup scripts and Railway CLI configuration                    | No. Use a numbered version from the release lookup. |

`latest` moves when a stable image is published. Running containers keep their image until you pull and recreate or redeploy them; a restart alone does not fetch a new image. Follow the upgrade procedure, including migrations. To keep an exact backend and dashboard pair while a release is being published, use the numbered version.

## Verify the selected images

From a standalone installation:

```bash
docker compose --profile standalone config --images
docker compose --profile standalone pull
```

For a local trial, use `-f docker-compose.yml -f docker-compose.local.yml` instead of `--profile standalone`. Pulling only downloads images; the upgrade procedure starts the updated containers. See the [Docker Compose pull reference](https://docs.docker.com/reference/cli/docker/compose/pull/).