TokayOps
0.1.0 Current release

A version you can pin.

Releases are cut from main, tagged v0.1.0, and written up in the changelog. The build in front of you says which one it is: /api/version, and the footer of its own UI.

version
0.1.0
shipped
2026-08-18
image
ghcr.io/tokayops/tokayops:0.1.0
apache-2.0 on
2028-08-18

Source-available under FSL-1.1-Apache-2.0: every release converts to Apache-2.0 two years after it ships, on its own clock. 0.1.0 converts on 2028-08-18, whatever the product does by then.

Changelog All releases
semver What a number promises

Minor can break you. Patch cannot.

TokayOps follows Semantic Versioning. While the version is 0.x, the leading zero is doing the work a major number does later:

minor 0.1.0 → 0.2.0
May change the public contract, and may need a manual step on upgrade. The changelog says which.
patch 0.1.0 → 0.1.1
Fixes only. Nothing to read before taking it.
The public contract
  • The REST API under /api
  • The Alertmanager webhook it accepts
  • The environment variables and tokay.yaml
  • The CLI commands
  • The image tags above
Not part of it
  • The Go packages under internal/ - this is an application, not a library
  • The frontend assets
  • make seed
ghcr Image tags

Which tag to pull.

Multi-architecture images (linux/amd64, linux/arm64) on GHCR. Start from :latest; pin when you would rather choose the moment you move.

Tag Points at
latest The newest stable release. What the compose file pulls when nothing is pinned.
0.1.0 That release, and nothing else afterwards.
0.1 The newest patch of the 0.1 series. Picks up fixes, never a minor bump.
develop The current build of the develop branch. Not a release, not supported.
sha-<commit> A CI build of one commit, for trying an unreleased fix.
Pin a version 
# .env - follows nothing, moves only when you say so
TOKAY_TAG=0.1.0

A version tag is never re-pointed at a different build. That is policy, not physics: registry tags are mutable by nature, and sha-<commit> is not covered by the promise at all, because re-running CI on a commit rebuilds and replaces it. For a reference that provably cannot move, use the digest.

Pin a digest 
# Every GitHub Release lists the digest of its images
image: ghcr.io/tokayops/tokayops@sha256:...
support Support and upgrades

The newest release, and only that.

  • Fixes, security ones included, ship as a patch on top of the newest release. Older releases, develop builds and sha-<commit> images are not patched: upgrade instead.
  • Upgrade forward one minor version at a time, reading the upgrade notes of each release you pass through.
  • Downgrades are not supported. The schema is created and extended in place on startup, so going back means restoring a database backup taken before the upgrade. Take one.
  • Anything on its way out is announced in the changelog at least one minor version before it is removed.

Found something security-shaped?

Not a public issue. Report it privately through the GitHub advisory form; you get an acknowledgement within 3 working days and an assessment within 10. Scope and what counts as an operator's own configuration are in the security policy.

1.0 Not yet

What 1.0 is waiting on.

Two things: a versioned migration system, and holding the API still. Neither is a feature you would notice in the UI, and both are what makes a promise about upgrades worth having. Until then the honest instruction is the boring one - read the release notes before every minor upgrade.

Installation guide Changelog