Docker image

Running itCopy Anchor Link

docker run -d --name imgyoung --restart unless-stopped \
  -p 8721:8721 \
  -v imgyoung-data:/data \
  ghcr.io/x-haose/imgyoung:latest

Open http://<host>:8721/ and sign in with admin / imgyoung123; the first sign-in asks you to change the password right away.

The image is published for linux/amd64 and linux/arm64; Docker picks the right one for the host. To see the version inside an image:

docker run --rm ghcr.io/x-haose/imgyoung:latest -version

Image tagsCopy Anchor Link

The image is ghcr.io/x-haose/imgyoung. Tags have no v prefix:

Pre-releases get only their exact version tag and never move the major.minor tags or latest, so instances pinned to those never pull a pre-release.

The data volumeCopy Anchor Link

The data directory inside the container is /data (the image sets IMGYOUNG_DATA_DIR=/data). It contains:

During a restore from snapshot you may also see the staged file imgyoung.db.restore, and afterwards the previous database kept as imgyoung.db.pre-restore-<time>.

docker cp imgyoung:/data/master.key ./imgyoung-master.key

Using a host directory insteadCopy Anchor Link

To keep the data in a directory on the host, first give it to the user the image runs as (uid 65532):

sudo mkdir -p /srv/imgyoung
sudo chown 65532:65532 /srv/imgyoung
docker run -d --name imgyoung --restart unless-stopped \
  -p 8721:8721 \
  -v /srv/imgyoung:/data \
  ghcr.io/x-haose/imgyoung:latest

A named volume inherits the ownership of /data from the image the first time it is mounted; a host directory does not. With the wrong owner the process cannot create the database and fails at startup.

Environment variablesCopy Anchor Link

These are all bootstrap settings. Pass them with -e; changes take effect only after the container is recreated. See Configuration for the full reference.

A variable that is not set takes its default. Setting it to an empty string (or only whitespace) explicitly empties it instead of falling back to the default; the "When empty" column says what that means:

Running as nonrootCopy Anchor Link

The image is based on gcr.io/distroless/static-debian12:nonroot and runs as the nonroot user (uid 65532). It contains no shell and no package manager, so docker exec -it imgyoung sh does not work. When you need to work on the data directly (for example editing the database to reset a forgotten password), stop the container and mount the same volume into another container that has the tools.

Behind a reverse proxyCopy Anchor Link

ImgYoung trusts X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host only when the connecting peer is inside IMGYOUNG_TRUSTED_PROXIES. The default trusts loopback only, but inside a container the peer is almost never loopback:

• The proxy runs in another container on the same Docker network: the peer is the proxy container's address.
• The proxy runs on the host and reaches the container through a port published with -p: the peer is usually the Docker bridge gateway (such as 172.17.0.1), not 127.0.0.1.

In both cases, mark the proxy's network as trusted:

docker run -d --name imgyoung --restart unless-stopped \
  -p 127.0.0.1:8721:8721 \
  -v imgyoung-data:/data \
  -e IMGYOUNG_TRUSTED_PROXIES=172.16.0.0/12 \
  ghcr.io/x-haose/imgyoung:latest

172.16.0.0/12 covers most networks Docker allocates by default; check the actual subnet with docker network inspect <network>. If you leave it unset:

• Login rate limiting is keyed on the proxy's address, so every visitor shares one allowance (a burst of 5, then 1 more every 12 seconds): when someone keeps mistyping a password, everyone else is temporarily locked out too.
• Without base_url, links returned by uploads use http:// even though the site is served over HTTPS, and the session cookie is not marked Secure.
• The /metrics allowlist also sees the proxy's (private) address, so anyone going through the proxy can scrape metrics unless the proxy blocks /metrics. The Caddy and Nginx samples under deploy/ in the repository already block it.

For the proxy itself, see Reverse proxy; for running it together with Caddy, see Docker Compose.

Restart policyCopy Anchor Link

"Restore" under "Settings → Backups & export" in the console first stages the snapshot in the data directory, then makes the service exit cleanly (exit code 0); the snapshot is swapped in before the database is opened on the next start. Therefore:

• Use unless-stopped or always. on-failure does not restart a container that exited cleanly, and the default no never restarts it.
• Without a suitable policy, the container stays exited after a restore, and the snapshot is swapped in only when you run docker start imgyoung yourself.

The restart policy also brings ImgYoung back after the host or the Docker daemon restarts.

UpgradingCopy Anchor Link

Pull the new image and recreate the container with the same flags. All data lives in the volume and is untouched; the database schema is migrated automatically when the new version starts:

docker pull ghcr.io/x-haose/imgyoung:latest
docker stop imgyoung && docker rm imgyoung
docker run -d --name imgyoung --restart unless-stopped \
  -p 8721:8721 \
  -v imgyoung-data:/data \
  ghcr.io/x-haose/imgyoung:latest

docker stop waits 10 seconds by default before killing the container, which is enough for ImgYoung: on the stop signal it stops accepting new requests and waits up to 6 seconds for in-flight ones, stops background work within 2 more seconds, then closes the database and exits.

Downgrading is not supported: if you switch back to an older tag, the older version refuses to start on a database migrated by a newer one. Rolling back takes the older image plus a snapshot taken before the upgrade.

Before upgrading, consider clicking "Back up now" under "Settings → Backups & export". See Upgrading for the rollback steps and more.