ADR 0145: The production site deploys only from release tags

Status: accepted

The installed binary embeds help from a released source snapshot, but the initial Deno Deploy plan linked production to the repository's default branch. That lets documentation on main describe behavior users cannot install yet. The drift is subtle because both revisions can be individually correct while their public claims disagree.

Deno Deploy supports both GitHub-linked automatic builds and local-source CLI deploys. Automatic builds are convenient, but their branch trigger is the failure mode this decision must remove. Preview environments and a version selector would solve a broader problem the site does not have until two materially different released versions exist.

Production is a local-source Deno Deploy application, not a GitHub-linked default-branch application. The existing release workflow is the only production publisher: a v* tag builds and publishes the binaries, then the site job checks out that exact tag, verifies it matches deno.json's version, builds the site, and runs deno deploy --prod. The job authenticates with a production-environment organization token and names the organization and app through repository environment variables.

There is no production deploy on main, no preview deployment, no version selector, and no manual deploy from an arbitrary checkout. Re-running the release workflow for an existing tag is the recovery path.

• The public docs can lag an in-progress change on main, but can never lead the software users can install.
• A release tag is one source revision for binaries and site. A tag/version mismatch stops before production deployment.
• Deno Deploy must be created without automatic GitHub source builds, and the GitHub production environment must hold the token, organization, and app configuration.
• A failed site deployment leaves the previous release serving; there is no preview URL in this first release model.