Questions

TypeScript, JavaScript, Python, Go, Java and Kotlin repositories, on GitHub or GitLab.

• Package managers: npm, pnpm, yarn, bun, pip, uv, poetry, Go modules, Maven and Gradle.
• Next: Ruby, C#, PHP, Rust and Swift, and Bitbucket.

Email us the language you need: the most requested ships first.

Those tools bump version numbers. When a new version has breaking changes, the upgrade PR fails and someone still has to rewrite the code.

• Version bumps: Versyka does these too, several in one pull request.
• The rewrite: when an upgrade breaks your code, Versyka changes the code as well.
• Proof: your tests run before and after.

Yes. For connected repositories, a daily scan flags every package that is major versions behind or deprecated, including API SDKs.

• Each alert links to the release notes.
• Starting a migration from an alert fetches the vendor's notes automatically.
• Packages you ignore in .versyka.yml, Dependabot or Renovate are skipped.

The daily scan reads your code and config for exact model IDs from each vendor's own retirement list, written the way a call or a setting writes them.

• Counted: a model ID as a value: a quoted string, a config file or an .env setting, including gateway prefixes such as openai/ or models/ and Bedrock IDs.
• Not counted: a model named in ordinary text ("GPT-4, Claude and Gemini" in a sentence), tests, fixtures, docs, and files that list ten or more models (a price list or a model picker).
• Every file is fixed: the replacement changes the model ID in every file that names it, in any language (a JavaScript file in a Python repository is included).
• The dashboard says how many files use each model, and the review lists each file and line before anything runs.

Yes. The daily scan checks your dependencies against known vulnerabilities (OSV.dev) and groups them into the upgrades that fix them.

• They show up as package upgrades in your dashboard: tick the ones you want and review them first.
• On Team and Scale, Autopilot can open the security fixes (version bumps that close known vulnerabilities) every Monday on its own.
• Version bumps go into one pull request per repository and are unlimited on every plan: they don't use your migration pull requests.
• A breaking upgrade also updates your code and uses one of your monthly migration pull requests.
• The smallest safe move: each fix goes to the lowest version that closes the advisories, not the newest one, so it's least likely to break anything.
• Transitive dependencies (a vulnerable package pulled in by another one) are pinned to the fixed version with your package manager's own setting (npm and bun overrides, pnpm pnpm.overrides, yarn resolutions), and the fix only counts once the lockfile shows every copy upgraded.
• No fix released yet: it's tagged so, checked daily, and offered the day a fixed version ships.
• Packages your code never imports sort to the bottom, so the ones that matter come first.

Each one lists the advisories behind it, so you can check every claim.

Anthropic's Claude writes migration rules and code edits.

• Deterministic structural search (ast-grep), not the model, decides which files are touched.
• Simple changes use no AI at all: version bumps, swapping a retired AI model ID for its replacement, and the impact report in each upgrade dialog. Claude steps in only when code needs rewriting, or when your checks fail after a swap.

Yes, by commenting on the pull request. Anyone with write access can use these commands:

• @versyka rebase rebuilds it on your latest default branch and runs the checks again, without using another pull request from your plan.
• @versyka explain says what it changes and how it was tested.
• @versyka help lists the commands.

A pull request someone added commits to is never rebuilt.

Your repository's own checks, in an isolated sandbox, before and after the change: it doesn't invent tests.

• Syntax: every edited Python file is parsed with Python's own parser; for other languages the build or typecheck covers it.
• Typecheck and build: mypy on the edited files (when configured), your typecheck script or tsc --noEmit, your build script, go build and go vet.
• Lint: your linter, when the repository configures one: ruff check or flake8 on the edited Python files, or your lint script. Like every check, only new lint errors count.
• Tests: pytest (when the project has pytest config, a tests/ folder or test_*.py files), your test script, go test ./..., mvn test or ./gradlew test.
• Install first: your dependencies go into an isolated environment. If the project itself can't be built (a misnamed build backend, say), the dependencies it declares are installed instead, so your tests still run.

The full table per language is in the docs, under How a fix is verified.

Versyka runs every check your repository defines: typecheck, build, and tests, before and after the change.

• The pull request lists which checks passed.
• If there are none, it clearly says the change is unverified, so reviewers know what was proven.

They don't block the fix. Versyka runs your checks on the unchanged code first, then again after the change, and only new failures count.

• Errors are compared by file and message, not line number, so an edit that moves code doesn't make an old error look new.
• The pull request names what passed and what was already failing, so you see both.
• The AI is only shown the new failures, never asked to fix unrelated code.

It's built not to: the pull request opens only when your own checks show no new failures, it never pushes to your main branch, and nothing merges unless you merge it.

• If your repository has no tests, the pull request says the change is unverified, so you know what was and wasn't proven.
• If your own CI fails on a Versyka pull request, Versyka comments with whether it also fails on your main branch. On Team and Scale, when it passes on main, Versyka rebuilds the pull request once with your CI's errors as feedback.
• The new model or version can still behave differently in ways tests don't catch, so the pull request says what to look at.

No pull request opens. Versyka only opens one when your checks pass with no new failures, so a change that breaks something never reaches your review queue as if it were ready.

• A plain version upgrade that breaks your tests: you're told which tests broke, so you know it needs code changes. For an API SDK, start it as a migration from Outdated SDKs: Versyka rewrites the code that breaks and runs your checks again.
• A migration that still fails after three attempts: your dashboard says exactly what still fails, by test or error, with Try again, and you get an email.
• Open as draft: if you'd rather finish it yourself, open the last attempt as a draft pull request, clearly marked with what still fails. It doesn't use a pull request from your plan.
• One major at a time: when an SDK is several major versions behind and the full jump fails, move to the newest release of the next major only, then go on from there.

A fix that can't pass your checks is never counted against your plan.

Versyka finds which one. When a group of upgrades fails together, it tries them one at a time from the original versions, ships the ones that pass, and names the one that breaks with the tests it broke.

Each case is handled on its own, and none is blamed on the change by mistake.

• Flaky: a check that fails is run once more before the change is blamed; the pull request says if a check only passed on the second run.
• Slow: a check that runs past 15 minutes is reported as too slow, not as broken. Point test: in .versyka.yml at a faster command.
• Needs services: tests that need a database or secrets fail the same way before and after, so they don't block the fix, and the pull request says they were already failing. You can point test: at your unit tests.
• Install problems: if part of the install fails in the sandbox (a requirements file with conflicting pins, say), the pull request names it, so you know which checks may not have run fully. If the project itself can't be built, its declared dependencies are installed instead.

A pull request never looks complete when it isn't.

• AI model replacements cover every file that names the model, in any language, however many and however large.
• Code migrations change up to 20 files per pull request (raise it with max_files). Anything beyond that is listed under "Not changed in this pull request", and the title says it's partial.
• Paths you exclude with ignore in .versyka.yml are listed too.

Versyka only sees your repository, so model IDs kept in environment variables, secrets, deploy settings or a database aren't changed. Every model replacement pull request reminds you to check those, so a retired ID isn't still called after you merge.

Never to your default branch.

• Versyka opens a pull request on a separate branch.
• Nothing merges without your team's review.

Through our GitHub app, only on the repositories you choose:

• Read and write: contents and pull requests.
• Read-only: checks, commit statuses, issues and metadata, to show your CI result and receive @versyka commands.
• Your email address when you sign in to the dashboard.

Access tokens expire after about an hour, and you can uninstall the app at any time.

No. Your code is cloned into a disposable sandbox for each job and destroyed when the job ends.

• We keep metadata such as file paths, line numbers, status, and PR links.

Design partners use Versyka free during the pilot. After it, plans are priced by migration pull requests a month:

• Free: to try Versyka on your own repositories, with unlimited version upgrades and free AI model swaps.
• Starter: 10 for $49 a month, or $39 a month billed yearly.
• Team: 60 for $249 a month, or $199 a month billed yearly.
• Scale: 200 for $749 a month, or $599 a month billed yearly.
• API provider plans: from $1,500 a month.

Anyone who subscribes in the first 6 months keeps their price.

Every plan has the whole product: tested pull requests for outdated SDKs, vulnerable packages and retiring AI models, a weekly upgrade pull request, a daily scan, email and Slack alerts, a weekly summary and pull request commands.

• Free and Starter: for you and 2 teammates.
• Team: your whole team with no seat fees, Autopilot for security fixes, automatic rebuilds when a pull request gets conflicts, a pull request schedule and an audit log export.
• Scale: custom migrations for your own internal libraries, staged rollouts across many repositories, a shared Slack channel with our engineers, and invoices and security reviews.

Bigger plans also cover more repositories and pull requests, at a lower price per pull request.

Each plan includes a number of migration pull requests per calendar month (10, 60 or 200 on the paid plans), counted across all your repositories and reset on the 1st (UTC).

• Only opened pull requests count. Attempts are capped at twice the allowance, failed ones included.
• Version upgrades are unlimited on every plan, including the weekly upgrade pull request and security fixes (fair use: a daily cap on test runs). A package upgrade that needs code changes counts as one migration pull request.
• Replacing a retiring AI model is free when the vendor names a direct replacement: the model IDs are swapped without AI, so it uses no migration pull request. The dashboard marks these "Replace · free".
• When they're used up, finished migrations wait and we email you. Wait for the 1st, upgrade, or ask for extra pull requests at $5 each.

We never open or charge for extra ones without your agreement.

Each plan covers a set number of repositories at a time (25, 100 and 500 on the paid plans); you choose which ones in your dashboard.

• Most teams never reach the limit, because plans are priced by pull requests, not repositories.
• If you give the GitHub app access to more, nothing extra is charged: the others stay connected but aren't scanned or migrated.
• When you first connect, the most recently active repositories fill your plan, so it's worth choosing carefully.

Yes, anytime, in your dashboard: unselect one and select another, up to your plan's limit.

• Migrations only run on repositories covered at the time.

Change plans from the pricing page or your dashboard; Stripe shows the prorated amount before you confirm.

• Upgrades apply immediately.
• Cancelling keeps your plan until the end of the period you paid for, then your account moves to Free.
• Nothing is deleted, and you get an email for every change.

A major version is where SDKs remove or rename methods, so upgrading across one usually means changing the code that calls it, not just the version number.

No. It reads only package names and versions, looks them up on the public npm registry or PyPI, and stores nothing.

• A share link carries the file inside the link itself, so it is never sent to or stored by us.

After a check, you can ask for an email when those API SDKs get a new major version or are deprecated.

• Nothing is sent until you confirm from the first email.
• We store only your email and the package names and versions.
• Every alert has a link that stops alerts and deletes both.
• Unconfirmed requests are deleted after 7 days.