Synapse + synapse-s3-storage-provider, minimal extension image tracking upstream.
  • Dockerfile 100%
Find a file
Julian Lindner 226bea5894
All checks were successful
Build and Push Synapse + S3 Image / build (push) Successful in 22s
fix(ci): repair fondue build (jlxq0 CI image + dynamic buildkit host)
The build job referenced forge.oddie.app/julian/ci-elixir and a hardcoded
gruyere buildkit IP (10.0.1.57) — both invalidated by the forge gruyere->
fondue migration, so every scheduled build has failed since June (prepare
stage, ~1s, container-image pull unauthorized).

Match the working fondue pattern (lenno_web): pull the CI base image from
the jlxq0 namespace, and resolve BUILDKIT_HOST from the job container's
default-gateway at runtime instead of hardcoding it. Add registry build cache.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-22 09:39:06 +08:00
.forgejo/workflows fix(ci): repair fondue build (jlxq0 CI image + dynamic buildkit host) 2026-07-22 09:39:06 +08:00
Dockerfile build: thin stock image (element-hq base + stock s3 provider, no fork) 2026-07-22 09:35:21 +08:00
README.md build: thin stock image (element-hq base + stock s3 provider, no fork) 2026-07-22 09:35:21 +08:00

synapse-s3

Minimal extension of the official ghcr.io/element-hq/synapse image that pre-installs the stock synapse-s3-storage-provider, so Synapse's media_storage_providers config can use S3 directly without a per-pod pip install at startup.

Used by the Kampong Social Matrix homeserver on the fondue k8s cluster.

Image

forge.oddie.app/oddie-apps/synapse-s3:vX.Y.Z   # tracks upstream Synapse vX.Y.Z
forge.oddie.app/oddie-apps/synapse-s3:latest   # follows latest upstream stable

Build cadence

CI rebuilds on:

  • Push to main (Dockerfile / workflow changes)
  • Manual workflow_dispatch with synapse_version input
  • Weekly schedule (Mondays 06:00 UTC) — polls element-hq/synapse for new releases

Why this exists

Official ghcr.io/element-hq/synapse doesn't bundle the s3 storage provider. The plugin lives in matrix-org/synapse-s3-storage-provider and is pip install-able. Baking it into the runtime image is the standard pattern (alternatives — pip install at startup via init container, or a PYTHONPATH overlay — are messier) and the cleanest for production.

The one non-stock line

The Dockerfile carries a single sed that removes an overstrict assertion in synapse/handlers/profile.py (upstream bug element-hq/synapse#19702, still OPEN as of v1.157.0). Without it, avatar/profile updates for appservice (bridge) virtual users that lack an existing profile row crash. It is not a fork — one line on stock code, with a grep guard that fails the build once upstream removes the assert, forcing us to drop the workaround. No other patches; the s3 provider is used unmodified.

Bumping

Renovate in the platform repo auto-detects new tags here and opens a PR to bump the deployment image.