Freighter's next generation of backend system written in Go

Releases follow a two-step prerelease → promote flow. Both steps run in GitHub Actions; you trigger each with gh workflow run.

gh workflow run publish-prerelease.yml \
  -f version=v1.2.3-rc.1

This builds a Docker image from the current main HEAD, pushes it to the staging namespace of the internal ECR registry under the freighter-backend-v2 repository tagged v1.2.3-rc.1, and creates a GitHub prerelease at the same commit.

Deploy the staging image to your staging cluster and validate.

gh workflow run promote-release.yml \
  -f prerelease_tag=v1.2.3-rc.1 \
  -f release_version=v1.2.3

This re-tags the existing staging image into the production namespace (preserving the image digest — no rebuild) and creates a non-prerelease GitHub release.

• Releases: vMAJOR.MINOR.PATCH (e.g., v1.2.3)
• Prereleases: vMAJOR.MINOR.PATCH-rc.N (e.g., v1.2.3-rc.1)

The workflows enforce these formats — anything else is rejected before any side effect.

Out of scope for the current setup. All releases are cut from main. If you need to release a fix without including newer main changes, revert the unwanted commits on main first and cut from there.