big-release
Go Node Python PHP
This repo ↗
bigbase canary · Node

This page is live on v0.2.0.
big-release set that number.

A real Node.js service, versioned and shipped by big-release on every merge to main. The version on the right isn't a screenshot — it's this app reading its own VERSION file, right now.

Add it to your Node project See the 3 files ↓
node.bigbase.click
LIVE · deploy passing
v0.2.0
served live from this app's VERSION file
▲ version computed & released by big-release — no human typed it
How this version happened

One merge, three automatic moves

big-release runs in CI after tests pass. It reads your commits, decides the next version, and ships it — no manual tagging, no changelog edits.

1

A conventional commit lands

Someone merges feat: add /healthz endpoint to main. That prefix is the only versioning input.

→
2

big-release computes the bump

feat means a minor bump. It reads the last git tag and calculates the next semantic version automatically.

→
3

It tags, releases & deploys

Pushes the git tag, creates the GitHub Release with notes, bumps VERSION — and this page redeploys.

The three files that did it

Copy these into your repo. That's the setup.

Straight from this canary — nothing hidden, nothing generated on the fly.

.big-release.yml release config 
# big-release configuration
tagFormat: "v${version}"
initialVersion: "0.1.0"

plugins:
  - changelog
  - git
  - github
.github/workflows/test-build-release.yml CI 
release:
  if: github.ref == 'refs/heads/main' && github.event_name == 'push'
  needs: [build]
  permissions: { contents: write }
  steps:
    - uses: actions/checkout@v7
      with: { fetch-depth: 0 }

    - name: Install big-release
      run: |
        curl -sL https://github.com/danielvm-git/big-release/releases/latest/download/big-release-linux-amd64 -o big-release
        chmod +x big-release && sudo mv big-release /usr/local/bin/

    - name: Run big-release
      run: big-release release --verbose
      env: { GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" }
package.json scripts 
"scripts": {
  "start": "node server.js",
  "test": "node --test server.test.js",
  "lint": "eslint server.js server.test.js"
}
Add it to your Node project

From zero to automated releases in four steps

No plugins to wire, no version fields to hand-edit. One static binary in CI does it all.

terminal local test 
# preview the next release without publishing
big-release --dry-run
  1. 1

    Commit with a convention

    Use feat: / fix: prefixes. That's the whole contract.

  2. 2

    Drop in .big-release.yml

    Set tagFormat and pick your plugins. Copy the block on the left.

  3. 3

    Add the release job

    Install the binary, run big-release release after your tests pass.

  4. 4

    Merge to main

    big-release does the rest — tag, GitHub Release, changelog, deploy.

Why the version is what it is

Every bump is decided by a commit — not a human

big-release maps Conventional Commit types to semantic-version bumps. That's the entire rule set.

feat:→minor

A new feature bumps the middle digit — 0.3.1 → 0.4.0.

fix:→patch

A bug fix bumps the last digit — 0.3.1 → 0.3.2.

BREAKING CHANGE:→major

A breaking change bumps the first digit — 0.3.1 → 1.0.0.

See this canary's real release history on GitHub →