freighter-backend-v2

Freighter's next generation of backend system written in Go

Database

The service requires a PostgreSQL database (DATABASE_URL). For local setup, connecting with psql, migrations, deployed-environment access, and pool tuning, see internal/db/README.md.

Releases

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

1. Cut a prerelease

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.

2. Test the prerelease in staging

Deploy the staging image to your staging cluster and validate.

3. Promote to a release

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.

Tag format

• 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.

Hot-fixes / cherry-picked releases

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.