Renovate Automation

How Renovate Works

Renovate is a GitHub App that runs on Renovate's servers (not in our CI). On its configured schedule, it scans every package.json in the monorepo, compares versions against the npm registry, and opens PRs for anything outdated.

Each PR triggers the normal CI pipeline (see Pipeline), which runs formatting, linting, dependency cruising, dead code detection, duplication checks, type checking, tests, and a full build. If CI passes and the PR matches the automerge rules, Renovate merges it without human intervention.

Schedule and Limits

From renovate.json:

Setting	Value	Rationale
Schedule	every weekend	Batches updates to avoid weekday disruption
Timezone	America/Denver	Aligns with the founder's timezone
Concurrent PR limit	5	Prevents a flood of open PRs that overwhelm CI runners
Base config	config:recommended	Renovate's recommended defaults (includes grouping for monorepos, lockfile maintenance, etc.)

Automerge Rules

Renovate applies three merge policies based on dependency type and update severity:

DevDependency patches and minors -- automerge

{
  "matchUpdateTypes": ["minor", "patch", "pin", "digest"],
  "matchDepTypes": ["devDependencies"],
  "automerge": true,
}

Tooling updates (ESLint plugins, type definitions, test utilities) merge automatically when CI passes. These do not ship to production, so the risk of a silent regression reaching users is zero.

Runtime dependencies -- manual merge

{
  "matchDepTypes": ["dependencies"],
  "automerge": false,
  "labels": ["dependency-runtime"],
}

Any package in the dependencies field ships to production. These PRs are labeled dependency-runtime and require manual review. Even if CI passes, a human verifies:

• The changelog for behavioral changes
• Whether the update affects a critical path (auth, database, AI)
• Whether any API surface changes require code updates

Major updates -- always manual

{
  "matchUpdateTypes": ["major"],
  "automerge": false,
  "labels": ["dependency-major"],
}

Major version bumps may contain breaking changes. These are labeled dependency-major and always require manual review, regardless of whether the dependency is a devDependency or runtime dependency.

Package Groups

Related packages are grouped so they update in a single PR instead of generating separate PRs per package. This prevents version mismatches between packages that must stay in sync.

Group	Packages Matched	Why Grouped
drizzle	drizzle-orm, drizzle-kit, drizzle-seed	ORM, codegen, and seeder must match
trpc	@trpc/client, @trpc/server, @trpc/react-query	Client and server share protocol types
tanstack	@tanstack/react-query, @tanstack/react-query-devtools	Query core and devtools must match
better-auth	better-auth and related packages	Auth core and plugins share internals
eslint	eslint, @eslint/*, typescript-eslint	Plugin APIs are tied to the core version
tailwindcss	tailwindcss, @tailwindcss/*, tailwind-merge, prettier-plugin-tailwindcss	PostCSS plugin, merge utility, and formatter must agree on class names
types	All @types/* packages	Type definitions are low-risk; grouping reduces PR noise
vitest	vitest, @vitest/*	Test runner and coverage plugin share APIs
sentry	@sentry/nextjs, @sentry/cli	Sentry SDK components must stay in sync
inngest	inngest and related packages	Single-package group for future plugin additions

When to create a new group

Create a new Renovate group when:

• Two or more packages share internal types or protocol versions (e.g., a client/server pair)
• Updating one without the other causes type errors or runtime failures
• The packages are from the same vendor and release in lockstep

Add the group to renovate.json with a matchPackagePatterns array. Use ^prefix patterns for vendor-scoped packages.

Dependency Dashboard

Renovate maintains a "Dependency Dashboard" issue in the GitHub repository. This issue provides:

• A list of all pending updates (grouped and ungrouped)
• The status of open Renovate PRs
• Packages that Renovate is having trouble updating (e.g., version conflicts)
• A checkbox interface to trigger updates manually

Check the dashboard when a dependency seems stuck or when you want to see the full update picture across the monorepo.

Reviewing Renovate PRs

Automerged PRs (devDependencies, patch/minor)

No action needed. These merge after CI passes. Skim the merged PRs list periodically to stay aware of tooling changes.

Runtime dependency PRs (dependency-runtime label)

1. Read the changelog linked in the PR description.
2. Check for behavioral changes that affect Trovella's usage of the package.
3. If straightforward, approve and merge.
4. If the update touches a critical path (auth, RLS, database), test the specific flow manually.

Major update PRs (dependency-major label)

1. Read the full migration guide (not just the changelog).
2. Assess scope: is it a trivial API rename or a fundamental architecture change?
3. If straightforward, update code in the PR branch and merge.
4. If complex, create a Linear issue and schedule a dedicated migration session. Close the Renovate PR and check the "Ignore this update" box on the Dependency Dashboard (Renovate will re-open when you uncheck it).

Interaction with the Catalog

Renovate updates the version in pnpm-workspace.yaml for cataloged dependencies. It does not touch the "catalog:" specifiers in individual package.json files. This is the correct behavior -- the catalog indirection is preserved.

For non-cataloged dependencies, Renovate updates the version directly in the relevant package.json file.