ci: push production image to DockerHub alongside GHCR

[levivannoort]

Problem

The production deployment workflow never pushed images to DockerHub. The step named "Login to DockerHub" actually had its registry: set to ghcr.io, so production only ever authenticated against and pushed to GHCR. Staging, meanwhile, already pushes to both registries.

Changes

• Renamed the existing login step to "Login to GitHub Container Registry" (it was always GHCR).
• Added a real "Login to Docker Hub" step using the DOCKERHUB_USERNAME / DOCKERHUB_TOKEN secrets (same as staging).
• Added REGISTRY_GITHUB, REGISTRY_DOCKERHUB, and IMAGE_NAME env vars.
• Build/push now emits both tags:
  • ghcr.io/appwrite/website:<tag>
  • docker.io/appwrite/website:<tag>

The production-only SENTRY_RELEASE build-arg is left untouched.

Notes

• Relies on the DOCKERHUB_USERNAME / DOCKERHUB_TOKEN repo secrets being available to release events — staging already uses them.

🤖 Generated with Claude Code

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Building	View Logs	Preview URL

Tip

MCP server integration brings LLM superpowers to Claude Desktop and Cursor IDE

[greptile-apps]

Greptile Summary

This PR fixes a long-standing misconfiguration where the production workflow's "Login to DockerHub" step was actually authenticating against ghcr.io, so production images were never pushed to DockerHub. The fix mirrors what the staging workflow already does correctly.

• Renames the existing login step to "Login to GitHub Container Registry" (accurate) and adds a true "Login to Docker Hub" step using DOCKERHUB_USERNAME / DOCKERHUB_TOKEN secrets.
• Adds REGISTRY_GITHUB, REGISTRY_DOCKERHUB, and IMAGE_NAME env vars (matching staging), and updates the build-push tags to emit to both ghcr.io/appwrite/website:<tag> and docker.io/appwrite/website:<tag>.

Confidence Score: 5/5

Safe to merge — the change is a direct copy of the staging workflow's working pattern applied to production, with no functional risk to the existing GHCR push or the deploy job.

The diff is a minimal, mechanical alignment of the production workflow with staging. Both registry logins use pinned action SHAs already present in the file, the secrets are the same ones staging already relies on, and the build-push step is unchanged except for the added DockerHub tag. No logic in the deploy job is touched.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/production.yml	Adds DockerHub login step and dual-registry tags to match the staging workflow pattern; renames the previously mislabeled GHCR login step

_{Reviews (1): Last reviewed commit: "ci: push production image to DockerHub a..." | Re-trigger Greptile}