ci(server): publish mem0-api-server Docker image with semver tags on release#5341
Open
shivamtyagi18 wants to merge 1 commit into
Open
ci(server): publish mem0-api-server Docker image with semver tags on release#5341shivamtyagi18 wants to merge 1 commit into
shivamtyagi18 wants to merge 1 commit into
Conversation
…release Adds a GitHub Actions workflow that builds and publishes the server Docker image (server/Dockerfile) to Docker Hub on each GitHub release event, producing semver-aligned tags for downstream pinning: - mem0/mem0-api-server:vX.Y.Z (exact pin — production-safe) - mem0/mem0-api-server:vX.Y (minor channel) - mem0/mem0-api-server:vX (major channel) - mem0/mem0-api-server:latest (moves with each release) Motivation: today only a single mutable `:latest` tag is published (last pushed 2025-09-10 as of opening), so Kubernetes / production deployments have no immutable target to pin against. This workflow follows the same release-triggered pattern as the existing PyPI publish workflow (cd.yml). Implementation: - Multi-platform build (linux/amd64 + linux/arm64) via Buildx + QEMU - GitHub-hosted layer cache (cache-from/to: type=gha) for fast subsequent builds without external infra - Fork-safe: workflow runs only on the canonical mem0ai/mem0 repo or via manual workflow_dispatch — forks won't fail confusingly on missing secrets - workflow_dispatch input lets maintainers re-publish a specific tag manually if needed (e.g. after a hotfix or secret rotation) Required secrets (configured by maintainers post-merge): - DOCKERHUB_USERNAME — the bot/account that owns mem0/mem0-api-server - DOCKERHUB_TOKEN — Docker Hub access token with push scope Until the secrets are configured the workflow stays dormant; the file just sits in repo. No risk to existing flows. Also adds a brief "Docker image" section to server/README.md documenting the tag scheme and recommending semver pinning over :latest for production use. See mem0ai#5340 for the broader rationale and discussion.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #5340
Summary
Adds a GitHub Actions workflow that publishes the server Docker image (
server/Dockerfile) to Docker Hub with semver-aligned tags on each GitHub release event.File added:
.github/workflows/server-docker-cd.yml(62 lines)File modified:
server/README.md(+12 lines, new "Docker image" section)What this gives downstream users on each release
mem0/mem0-api-server:vX.Y.Zmem0/mem0-api-server:vX.Ymem0/mem0-api-server:vXmem0/mem0-api-server:latestMotivation
Discussed in detail at #5340. Short version: Docker Hub currently has a single mutable
:latesttag (last pushed 2025-09-10, 264 days as of opening). Production K8s deployments need immutable pinned tags for rollback safety, audit trails, and vulnerability scanning baselines. This workflow closes that gap without changing any runtime behavior.Implementation notes
release.published(same pattern as the existingcd.ymlPyPI publish) +workflow_dispatchfor manual re-publish (with optional tag input).linux/amd64+linux/arm64via Buildx + QEMU. Drop thelinux/arm64line if you'd rather start amd64-only.cache-from: type=gha/cache-to: type=gha,mode=max). No external infra to set up; subsequent builds are fast.if: github.repository == 'mem0ai/mem0'guard prevents the workflow from running on forks (where it would fail confusingly on missing secrets). Manualworkflow_dispatchis allowed everywhere for testing.server-docker-cd.ymlrather than reusingcd.ymlso the existing PyPI publish flow stays untouched.What you'd configure post-merge
Two repo-level GitHub Actions secrets:
DOCKERHUB_USERNAME— Docker Hub account that owns themem0/mem0-api-serverrepoDOCKERHUB_TOKEN— Docker Hub access token with push scopeUntil those are configured the workflow stays dormant (won't run on release events because the guard short-circuits early). No risk to existing flows.
What I'm explicitly NOT touching
server/Dockerfile— your existing Dockerfile is fine. This PR only adds a publish workflow around it.server/docker-compose.yml— local-dev pattern stays as-is.cd.yml(PyPI publish) — completely separate.Optional follow-ups (NOT in this PR, happy to file as a separate PR if you want any of them)
docker/build-push-action'ssbom: true(~1 line)Test plan
gh actions-cli validate-equivalent locally)cd.yml)If you'd prefer a different shape (different workflow filename, no arm64, different tag scheme, etc.), happy to iterate.
Companion
This is the second of two issues split from the original #5337/#5339 thread. The first half (
MEM0_CONFIG_PATHfor K8s ConfigMap-driven config) is at #5338.Thanks again for mem0! 🙏