Repository navigation
v0.9.0 — Docker image registry and simplified setup
Release Notes — v0.9.0
Release date: 2026-05-20
Overview
v0.9.0 adds a Docker image registry to AutoFlowOps. Backend and frontend images are now published to GitHub Container Registry (GHCR) on every release tag. A new setup script and a dedicated docker-compose.registry.yml let anyone run the full stack from a single command — no local build or clone required.
All existing features (RBAC, audit log, WebSocket real-time stream, notifications, Celery worker) remain unchanged.
What's New
Docker images on GHCR
Two images are published on every v*.*.* tag:
| Image | Registry path |
|---|---|
| Backend | ghcr.io/btcneves/autoflowops-backend |
| Frontend | ghcr.io/btcneves/autoflowops-frontend |
Each release produces three tags:
| Tag | Example | Meaning |
|---|---|---|
vX.Y.Z |
v0.9.0 |
Exact release — pinned, immutable |
X.Y |
0.9 |
Minor stream — updates on patch releases |
latest |
latest |
Latest stable release |
Images include OCI metadata labels (title, description, source, licenses, version, revision).
docker-compose.registry.yml
A new compose file that starts the full stack — backend, worker, frontend, PostgreSQL, Redis — using GHCR images. The IMAGE_TAG environment variable controls the version (default: latest).
# Start with latest
docker compose -f docker-compose.registry.yml up -d
# Pin to a specific release
IMAGE_TAG=v0.9.0 docker compose -f docker-compose.registry.yml up -dscripts/setup.sh
An interactive setup script for first-time installation:
- Checks that Docker and Docker Compose are installed
- Copies
.env.exampleto.env(if not already present) - Prompts for an image tag (default:
latest; skipped whenIMAGE_TAGis set) - Pulls backend and frontend images from GHCR
- Starts the stack via
docker-compose.registry.yml - Waits for the backend health endpoint (
/api/health) and frontend to respond - Prints service URLs and credentials reminder
# Interactive
bash scripts/setup.sh
# Non-interactive (CI / scripted environments)
IMAGE_TAG=v0.9.0 bash scripts/setup.shMakefile targets
| Target | Description |
|---|---|
make pull |
Pull backend + frontend images from GHCR (IMAGE_TAG=latest) |
make registry-up |
Start stack using GHCR images |
make registry-down |
Stop registry-based stack |
make registry-logs |
Stream logs from registry-based stack |
Override the tag: IMAGE_TAG=v0.9.0 make registry-up
docker-publish.yml workflow
A new GitHub Actions workflow (publish-backend + publish-frontend jobs) triggered on v*.*.* tag push:
- Logs in to GHCR using
GITHUB_TOKEN(no secrets to configure) - Builds each image with
docker/build-push-action@v5 - Uses GitHub Actions build cache (
type=gha) — subsequent builds of unchanged layers complete in seconds - Applies OCI metadata labels automatically via
docker/metadata-action@v5 - Can also be triggered manually via
workflow_dispatch
Dockerfile improvements
Backend:
- Added
curlto the image (required for theHEALTHCHECKinstruction) - Added
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3using/api/health - Added OCI labels
- Non-root user (
appuser, UID 1000) created early in the build .dockerignoreextended:tests/,*.egg-info/,*.sqlite,*.pyd,.env.*
Frontend:
- Added OCI labels
.dockerignoreextended:src/tests/,coverage/
Upgrade Steps
No database migration is required. No new environment variables are required.
From v0.8.0 (build from source)
- Pull the latest code:
git pull origin main - Rebuild:
docker compose up -d --build
Switch to registry images
# Pull the v0.9.0 images
make pull IMAGE_TAG=v0.9.0
# Stop any existing stack
docker compose down
# Start from registry
make registry-up IMAGE_TAG=v0.9.0Known Limitations
- GHCR packages start private — after the first
docker-publish.ymlrun, go to the repository → Packages → make the packages public (or authenticate withdocker login ghcr.iousing a personal access token withread:packagesscope). vite previewin production — the frontend image usesvite previewto serve the built assets. For high-traffic deployments, replace with a dedicated static server (nginx, Caddy). The productiondocker-compose.prod.ymlflow (with Caddy) is unaffected and recommended for production.IMAGE_TAGnot propagated todocker-compose.registry.ymlautomatically — always pass it explicitly (IMAGE_TAG=v0.9.0 make registry-up) or export it in the shell.- No Windows support for
scripts/setup.sh— the setup script is a Bash script and requires WSL2 or Git Bash on Windows.