Container Images

The four container images built from Hrida.ai Studio's source: the app, the API gateway, the PostgreSQL database with backups, and the off-server backup sidecar. What each one runs, its tags, and how to pin them.

Hrida.ai Studio is published as container images in GitHub's container registry, under ghcr.io/hrida-ai. Four packages are built from Studio's source. Only the first is the app; the other three run beside it in the production stacks.

Package	What it is	Service	When you need it
hrida-ai-studio	The app: web interface, API and background jobs	hrida-ai-studio, hrida-ai-studio-worker	Always
hrida-ai-gateway	The API Builder gateway as a service of its own	hrida-ai-gateway	For heavy API traffic
hrida-ai-studio-postgres	PostgreSQL 16 with pgvector, plus continuous backup and automatic restore	postgres	When Studio runs on PostgreSQL
hrida-ai-studio-backup	Encrypted off-server backups of files, the app's data volume, LDAP and Grafana	hrida-backup	Recommended in production

Each image is built for linux/amd64 and linux/arm64, and Docker pulls the one that matches the server.

Pulling the images

The packages are private. On each server, log in to the registry once with a GitHub user and a personal access token (classic) that has the read:packages scope:

bash

echo "<token>" | docker login ghcr.io -u <github-user> --password-stdin

On Docker Swarm, deploy with docker stack deploy --with-registry-auth so the other nodes can pull too. On Kubernetes, use an image pull secret, as the gateway's manifests do.

Where each image runs

Deployment	Images
Single container (docker run)	hrida-ai-studio, with its data (SQLite, files) in one volume
Docker Compose, docker-compose-studio-prod.yaml	hrida-ai-studio (twice: the app and the workflow worker), hrida-ai-studio-postgres, hrida-ai-studio-backup
Docker Swarm, docker-compose-studio-prodSwarm.yaml	hrida-ai-studio (app and worker), hrida-ai-gateway
Docker Swarm, docker-compose-common-app-prodSwarm.yaml	hrida-ai-studio-postgres, hrida-ai-studio-backup
Kubernetes, kubernetes/gateway/	hrida-ai-gateway

The stacks also run standard images that aren't built from Studio's source, such as MinIO, Valkey, OpenLDAP and Grafana.

hrida-ai-studio

The app: web interface, API, chat, agents, knowledge bases and everything else Studio does. The production stacks run it as two services from the same image:

• hrida-ai-studio serves the web interface and the API;
• hrida-ai-studio-worker runs queued workflow jobs (python -m hrida_ai_studio.worker.hrida_workflow_worker).

Every change merged into Studio is published as a release, with these tags:

Tag	Points to	Use it for
1.4.2, v1.4.2 (for example)	One release; never moves	Production: pin it
1.4	The newest 1.4.x release	Following patch releases
latest, main	The newest release; moves with every release	Trying things out
git-<commit>	The build of one commit	Checking exactly which build runs

Each release's notes on GitHub list both the app and the gateway image. The version tags appear a few minutes after the release, when the image build for its commit finishes.

Variants

Tag	Difference
cuda	NVIDIA GPU support, CUDA 12.8
cuda126	NVIDIA GPU support, CUDA 12.6, for older drivers
ollama	Ollama bundled in the same container
slim	Smaller: the embedding and speech-to-text models aren't included and download on first use

A version tag takes the variant as a suffix, for example 1.4.2-cuda. Variants are built on request, not with every release, so check the package's tag list for the versions available.

hrida-ai-gateway

The API Builder gateway as a service of its own, for API traffic at scale: the published APIs' proxy without the web interface, document tools or machine-learning libraries. It's built from Studio's source with every release and has the app's tags, so one HRIDAAI_DOCKER_TAG pins both.

Releases before this package existed published the gateway as Studio's image with a -gateway tag (hrida-ai-studio:1.0.25-gateway). Those tags are still added, so deployments that pull them keep getting updates.

→ Dedicated Gateway Service

hrida-ai-studio-postgres

The database server: the stock pgvector/pgvector:pg16 image plus WAL-G for backups.

• Without STUDIO_PG_BACKUP=true it behaves exactly like the stock pgvector image.
• With STUDIO_PG_BACKUP=true it archives every change to S3 or MinIO within about a minute, takes a full backup every night, and restores itself when it starts on an empty data volume.

It's PostgreSQL 16, so an existing pgvector/pgvector:pg16 database can switch to it and keep its data volume.

Tags: latest, pg16, main and git-<commit>. It's rebuilt only when its own files change, not with every release, so it has no release numbers. To pin it, use a git-<commit> tag or the image's digest in STUDIO_POSTGRES_TAG.

→ Backup & Restore: database backups

hrida-ai-studio-backup

A backup sidecar for what the database backup doesn't cover: the files in MinIO (including the database backups themselves), the app's data volume, LDAP, Grafana and the secondary database. It copies them, encrypted, to an S3 bucket on another server or provider, on a schedule, and its restore.sh script brings them back.

It does nothing until BACKUP_ENABLED=true, so the stacks can include it safely.

Tags: latest, main and git-<commit>. Like the database image, it's rebuilt only when its own files change; pin it with STUDIO_BACKUP_TAG.

→ Backup & Restore: off-server backups

Pinning versions

The stacks read the tags from .env:

Setting	Image	Example
HRIDAAI_DOCKER_TAG	hrida-ai-studio and hrida-ai-gateway	1.4.2
STUDIO_POSTGRES_TAG	hrida-ai-studio-postgres	git-1a2b3c4
STUDIO_BACKUP_TAG	hrida-ai-studio-backup	git-1a2b3c4
GATEWAY_IMAGE (Swarm stack)	The gateway image, used with HRIDAAI_DOCKER_TAG	ghcr.io/hrida-ai/hrida-ai-studio runs the gateway from Studio's own image

All default to latest. In production, pin them: with a moving tag, a container that restarts or moves to another node can start a newer build than the others.

To see what a tag points to, and its digest:

bash

docker buildx imagetools inspect ghcr.io/hrida-ai/hrida-ai-studio:1.4.2

Pinning by digest (ghcr.io/hrida-ai/hrida-ai-studio@sha256:… in the compose file) fixes the exact build even if a tag is moved.

Before updating, back up your data: see Updating and Backup & Restore.