How we deploy

We ship changes to Binder often, in small pieces, on purpose. This page is a short, honest account of what happens between us finishing a change and you seeing it.

Every change is checked the same way

Before anything reaches production, it goes through the same set of checks: type-checking, linting, and the automated test suite. None of these are optional and none of them get skipped to move faster — a change that doesn't pass doesn't ship, no exceptions for "it's a small fix."

Preview before production

Changes get built and deployed to a preview environment first, separate from the app you use. That's where we look at the actual result — not just "the tests passed," but "does this look and behave the way we intended" — before it goes anywhere near your account.

Small, frequent releases

We'd rather ship a small change on Tuesday and another small change on Thursday than bundle a month of work into one release. Small releases are easier to reason about, easier to review, and — if something is wrong — much easier to trace back to the one change that caused it.

If something goes wrong

If a release causes a problem, we roll back to the last known-good version rather than trying to forward-fix under pressure. Your documents are never at risk during this — versioning and the release pipeline are entirely separate systems, so a bad deploy can't touch what you've written.

Status and changes

Every release, big or small, gets a line in the changelog. If you want to know what changed and when, that's the page to read.