Mend Renovate

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the dependency updating I actually need instead of a hosted Renovate — and read the first paragraph, because the free answer is probably the right one.

Read this first: Renovate itself is open source and free, and running it as a scheduled job in your own CI costs nothing. So does Dependabot, on the main forges. There is very little reason to build this from scratch, and the honest recommendation is to configure one of them well. What follows is what to build if you genuinely need something they do not do — a private registry they cannot reach, an in-house package format, or a policy they cannot express.

STACK
- Node 20+ with Fastify for the scheduler and the dashboard
- SQLite through better-sqlite3, WAL mode
- Each update runs in a container with the repository checked out
- Caddy in front, on a private network

THE DATA MODEL
- repos: id, name, remote_url, default_branch, config_json, credentials_encrypted, is_active, last_scanned_at
- dependencies: id, repo_id, manager, file_path, name, current_version, current_constraint, latest_version, latest_satisfying, is_direct, is_dev, last_seen_at
- updates: id, dependency_id, from_version, to_version, kind, group_key, status, branch, pr_number, opened_at, merged_at, closed_at, error — kind is patch, minor, major, pin, digest or lockfile maintenance
- runs: id, repo_id, started_at, finished_at, status, log_path, created_count, updated_count
- advisories: id, package, ecosystem, affected_range, severity, identifier, published_at, fixed_in
- Everything append-only enough that 'why did this open' is answerable months later

THE SCAN
- Detect the package managers in the repository and read every manifest and lockfile
- One adapter per ecosystem: parse the manifest, resolve the current version from the lockfile, ask the registry what is available, and produce the update. Each adapter is small and independently testable
- The lockfile is the truth about what is installed. A manifest constraint is not a version
- Private registries with credentials from the environment, never in a config file
- Run on a schedule and on demand, with a per-repository concurrency of one

GROUPING AND SCHEDULING, WHICH IS THE ENTIRE DIFFERENCE
- Ungrouped updates on a large repository produce forty pull requests a week, and forty is the number at which everybody stops reading them
- So: group by ecosystem, by monorepo package family, by update kind, or by a named rule. All patch updates in one weekly pull request is the setting most teams end up at
- A schedule: only outside working hours, only on certain days, with a limit on open pull requests and a limit on new ones per run
- Automerge for patch updates whose tests pass, with a minimum age so a package published an hour ago is not merged automatically — that delay is a genuine supply-chain defence
- Security advisories bypass the schedule and the grouping, and open immediately with the severity in the title

THE PULL REQUEST
- Title and body generated: what changed, from and to, the release notes, the changelog section, and the compare link
- Release notes fetched from the forge and included inline. A pull request that makes you go and find the changelog is a pull request that gets merged unread
- A confidence signal — how long the version has been out, and whether it is adopted — stated as the weak signal it is
- Rebase on conflict, and close-and-reopen handled without losing the branch's history
- If it is closed unmerged, remember that and do not reopen the same update. Ignoring that is how these tools get switched off

SAFETY
- Every update runs the repository's own tests before the pull request is opened, in a container with no network beyond the registries it needs
- Lockfile-only updates for transitive dependencies, which are most of the security fixes
- Never run a package's install scripts during the scan. That is arbitrary code from a package you have not decided to trust yet
- Credentials scoped per repository and never written to a log or a branch

THE DASHBOARD
- Per repository: what is out of date, what is open, what failed and why
- A single issue in the repository listing everything pending, with checkboxes to trigger an update — which is a good pattern worth copying, because it keeps the state where the developers are
- Advisories affecting you, ranked

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, ENCRYPTION_KEY, FORGE_TOKEN, SESSION_SECRET, REGISTRY credentials
- Migrations on boot, each once
- Nightly backup, restore script
- Health endpoint reporting scan lag and the oldest unscanned repository

WHAT MATTERS MOST
Grouping, scheduling and honouring a closed pull request. Those three decide whether the tool is used or muted, and they are also exactly what the existing free tools already do well — so before building any of it, spend an afternoon configuring one of them and see whether you still need this.

Give me the repository, one ecosystem adapter, migrations, .env.example, and a README that opens with the recommendation to configure the free option first.