Changelog

A release every other Thursday. Latest: v2.14, Sep 24.

What shipped, and when.

Small releases on a fixed day, each one written up by the engineer who built it, caveats included.

Read the docs

Every other Thursday, written by the people who built it.

  1. v2.14

    Sep 24, 2026

    New

    Previews wake in about four seconds

    A sleeping preview used to cold-start its containers when someone opened the link, which took a median of 19 seconds. Canary now snapshots each service's memory as the preview goes to sleep and restores it on wake. The median is 4.1 seconds, and the first request is held instead of dropped, so the page simply loads.

    It is on for every workspace, with nothing to configure. One caveat: a service holding more than 4 GB of memory still cold-starts, and the wake log says so. The reasoning behind sleep is in A preview that nobody opens should cost nothing.

    • The spend page shows awake and asleep hours for each preview.
    • canary open waits for the wake instead of opening a loading page.

  2. v2.13

    Sep 10, 2026

    New

    Helm values per branch

    Charts rarely want the same values in a preview as in production. preview.values takes a values file, or inline keys, that Canary layers over the chart's defaults for every preview. Because canary.yml is read from the branch, a pull request that changes the values previews the change first.

    preview:
  from: charts/app
  values:
    replicaCount: 1
    ingress.class: canary

    Compose projects are unaffected. A values file that refers to a secret still needs that secret declared under secrets; Canary does not read secrets out of the chart. Every key is in the canary.yml reference.

    • Charts with OCI dependencies now resolve on the runner.
    • Fixed a build log that printed the values file twice.

  3. v2.12

    Aug 27, 2026

    New

    Mask rules reach inside JSON columns

    Masking worked on whole columns, which left out the phone number sitting inside a profile document. A mask rule now takes a path: users.profile->phone masks that key and leaves the rest alone.

    database:
  mask:
    - users.email
    - users.profile->phone

    Postgres json and jsonb columns and MySQL JSON columns are supported. Paths are checked when the snapshot is restored, so a typo fails the build instead of quietly masking nothing. It is not free: a large JSON column adds about 40 seconds per million rows to the restore. How masking keeps keys consistent across tables is in Masking a snapshot without breaking foreign keys.

    • The seed step lists every masked path in the build log.
    • Fixed masking of columns with a NOT NULL check on format.

  4. v2.11

    Aug 13, 2026

    Improved

    The build cache is shared across branches

    Each branch used to keep its own layer cache, so the first build of a new pull request started cold even when it changed one file. The cache now lives on the runner and is shared by every branch in the repository. A new branch reuses whatever main last built.

    In the two weeks we ran it behind a flag, the median rebuild across all workspaces fell from 1m 52s to 48s. It is now on by default. The cache is scoped to one repository and never leaves your runner. When a build needs a clean start, canary up --no-cache still gives you one.

    • The cache is capped at 40 GB per repository and trimmed oldest first.
    • The build log marks each layer cached or rebuilt.

  5. v2.10

    Jul 30, 2026

    New

    Comments pinned to the page sync to the pull request

    Reviewers who do not live in GitHub or GitLab can now click anywhere on a preview and leave a comment pinned to that spot. Each one is posted to the pull request with the page, the viewport size and a screenshot, and resolving it in either place resolves it in both.

    Turn it on for a workspace under Settings, or for one repository with review.comments: true. Commenters need the preview link and nothing else. A comment pinned to an element that a later commit removes is kept, but it falls back to the top corner of the page. Priya wrote about why we built it in What designers catch in a preview that screenshots hide.

    • Preview links can be limited to the workspace or protected with a password.
    • Fixed the comment table wrapping badly on narrow pull request views.

  6. v2.9

    Jul 16, 2026

    Fixed

    Teardown waits for running jobs to finish

    Teardown used to stop every container the moment a pull request merged. If a worker was halfway through a job, the job died, and a few of you had previews whose last act was half a batch of test emails.

    Teardown now stops web first, gives workers up to 10 minutes to finish the jobs they have already picked up, and then removes containers, volumes and DNS. Most previews have nothing queued and are gone as fast as before; the median is still 2m 12s. Set drain: 0s beside teardown to get the old behavior. Rowan's longer account is in Teardown is a feature.

    • Fixed volumes left behind when a pull request was closed and reopened within a minute.
    • The teardown notice names the merge commit.

  7. v2.8

    Jul 2, 2026

    Improved

    GitLab merge trains and self-managed GitLab 17

    On GitLab, a preview used to be torn down when its merge request entered a merge train, and nothing covered the minutes it spent waiting there. Canary now keeps the preview until the train actually merges it, and rebuilds it against the train's combined ref, so the last look is at what will land.

    Self-managed GitLab 17 is supported alongside 16. Connect it with a group access token, as the GitLab guide describes. Merge trains on a self-managed instance need 17.2 or later; earlier versions fall back to teardown on merge.

    • The merge request comment folds the service table into a collapsible section.
    • Fixed webhooks from subgroups nested three levels deep.