Get started

Docs

Versyka docs

Connect a repository, review your first migration, and make Versyka work with your checks.

Getting started

There are two ways to start.

Subscribe. Pick a plan on the pricing page. Your welcome email has an install button for the Versyka GitHub app; using it applies your plan to the account you install on. Reply to that email with the first migration you want, and Versyka opens tested pull requests from then on.

Join the pilot. Apply as a design partner and tell us which migration is stuck. We agree on one repository and one migration on a short call, you give access (see below), and you review the pull request. Design partners use Versyka free.

Not sure which upgrades you need? Paste a package.json, requirements.txt or pyproject.toml into the free upgrade check.

Connecting repositories

Choose whichever your team prefers:

OptionAccess grantedBest for
Versyka GitHub appContents (read/write), pull requests (read/write), metadata (read), on repositories you select. Dashboard sign-in adds read-only access to your email address.Ongoing use and monitoring
Collaborator accessWrite access to one repository for the pilotThe quickest pilot
You run itNone. You run Versyka with us on a callStrict security requirements

Remove access any time by uninstalling the GitHub app (GitHub → Settings → Applications) or removing the collaborator. See Security for how code is handled.

What a Versyka pull request contains

  • A branch named versyka/<vendor>-…. Versyka never pushes to your default branch.
  • Only files with affected call sites, plus the manifest and lockfile (package.json, requirements.txt, pyproject.toml, uv.lock, poetry.lock) when the upgrade needs a new version.
  • A description of what changed and why, with anything a reviewer should double-check.
  • A footer listing the checks that passed (for example "typecheck, build, test"), or a clear warning that the change is unverified when your repository has no checks.

If your checks still fail after three attempts, no pull request is opened, and we'll share what blocked it instead.

Commands on a pull request

Anyone with write access to the repository can comment on a Versyka pull request:

  • @versyka rebase: rebuild it on your latest default branch and run your checks again. It doesn't use another pull request from your plan, and if the rebuild doesn't pass, the pull request stays as it was with a comment saying why. (retry and refresh work too.)
  • @versyka explain: what it changes, why, and how it was checked, with the verification log.
  • @versyka help: the list of commands.

On Team and Scale, when a pull request gets merge conflicts, Versyka rebuilds it on its own, at most once a day. It never rebuilds one that someone has pushed their own commits to.

Configuration: .versyka.yml

Add an optional .versyka.yml to your repository root to control how Versyka works there:

# .versyka.yml (repository root). Every key is optional.

# Replace the auto-detected typecheck/build/test with your own command(s).
test:
  - npm run typecheck
  - npm run test:unit

# Replace the auto-detected install command.
install: pnpm install --frozen-lockfile

# Never edit files matching these globs (gitignore-style).
ignore:
  - legacy/**
  - "**/*.generated.ts"

# Maximum files changed in one migration (default 20).
max_files: 30

# Don't alert on or migrate these packages.
packages:
  ignore: [aws-sdk]

Commands run directly, without a shell, so pipes and && aren't supported. Put multiple steps in a list, or call an npm script. An invalid config stops the migration before any changes are made.

What Versyka finds and fixes

Once a day Versyka reads the manifests and lock files of your covered repositories (including projects in subfolders) and the code for AI model IDs. It finds three kinds of work, each in the Fix tab of your dashboard with its evidence:

  • Package upgrades: dependencies with known vulnerabilities from OSV.dev, grouped into the upgrades that fix them, each with its advisories. Version bumps go into one pull request per repository and use your plan's version-bump allowance; an upgrade that crosses a major version also updates your code and uses one migration pull request.
  • Outdated SDKs: API SDKs that are major versions behind or deprecated. A migration fetches the vendor's release notes, upgrades the package and rewrites the code its breaking changes affect (one migration pull request).
  • Retiring AI models: model IDs that are retired or retire within 90 days. One migration pull request per repository replaces them with the recommended models.

You tick what to fix and review it, with the cost, before anything starts. Your checks run before and after each change, so failures that were already there don't block a fix. When you merge, the alerts clear at once; when you close a pull request without merging, they come back with the reason. Use packages.ignore in .versyka.yml to silence packages you've decided not to upgrade, or Snooze (30 days) or Dismiss them in the dashboard. Packages your Dependabot or Renovate settings ignore entirely are left out of SDK alerts too. Overview: Monitoring.

Without connecting a repository

The free upgrade check runs the same lookup on a package.json, requirements.txt or pyproject.toml you paste, and stores nothing. Share links carry the file inside the link (after the #), so it never reaches our server. Email alerts watch the API SDKs from one check: confirm from the first email, then you hear from us only when a new major version ships or a package is deprecated. Each alert links to a page that stops alerts and deletes your email and package list. The SDK tracker lists every package we recognize, with its latest version.

Integrations: MCP server and GitHub Action

Two ways to use Versyka without opening the website, both free and without an account:

  • MCP server at https://www.versyka.com/api/mcp. Coding agents (Claude Code, Cursor, VS Code, Claude Desktop) can check SDK versions, look up AI model retirements and read migration guides. In Claude Code: claude mcp add --transport http versyka https://www.versyka.com/api/mcp.
  • GitHub Action versyka/versyka-action@v1. Comments on pull requests that add a retiring AI model or an outdated SDK, and can fail the check. Your code stays on the runner.

Setup for every client, the tool list and all Action options: Integrations. Retirement dates: model retirement calendar.

What's supported

Plans and your dashboard

Each plan covers a number of repositories at a time and a number of migration pull requests per month (pricing):

  • Connected vs covered. GitHub decides which repositories Versyka can see ("All repositories" or "Only select repositories"). Your plan covers up to its limit of those; only covered repositories are scanned and migrated. Connecting more costs nothing extra.
  • Choosing. When you first connect, the most recently active repositories fill your plan. Change which are covered anytime in the dashboard under Repositories.
  • Monthly pull requests. Counted across all repositories and reset on the 1st (UTC). Migrations that don't open a pull request don't count. When they're used up, finished migrations wait and we email you; extra pull requests are only opened with your agreement.
  • Changing GitHub access later. No need to sign out or reinstall: use Add or remove repositories in GitHub in the dashboard (or GitHub, Settings, Applications, Versyka, Configure) and switch between "All repositories" and "Only select repositories". New, deleted, renamed and archived repositories update in Versyka automatically.

Plan features. Every plan gets tested pull requests for all three kinds of fixes, the daily scan, model retirement alerts, Slack alerts (connect a channel under Slack alerts in the dashboard), a weekly digest, pull request commands and per-repo settings. On Starter, the account owner and 2 teammates sign in. Team adds dashboard access for everyone with write access to your repositories, Autopilot for version bumps, automatic rebuilds of pull requests that get merge conflicts, a pull request schedule (choose the days; migrations start between 9:00 and 17:00 in your time zone) and the audit log export. Scale adds custom migrations for your internal SDKs, staged rollouts (each change opens pull requests in up to 5 repositories you pick, and in the rest 3 days later, unless you close one of the first pull requests without merging), a shared Slack channel with our engineers, and invoices and security reviews. Each plan also allows migration attempts, failed ones included, up to twice its monthly migration pull requests. The dashboard shows which features your plan includes.

You get an email when a pull request opens, when a migration can't be completed, when your monthly pull requests are nearly or fully used, when repositories are beyond your plan, and for every subscription change or failed payment.

Sign in to the dashboard with the GitHub account that installed the app to see your plan, the repositories covered, pull requests used this month, and every migration with its status. Invoices, card changes and cancellation are in the billing portal linked from there.

Claude · rules + editsast-grep · call-site searchE2B · sandboxesGitHub App · least-privilege accessTrigger.dev · background jobsSupabase · data

How your code is handled: Security.

Troubleshooting

"No pull request was opened." Either no affected call sites were found, or your checks didn't pass after three attempts. The dashboard says which, in plain words, with Try again next to it, and the email says the same.

"It changed a file I didn't want touched." Add the path to ignore in .versyka.yml and close the PR. Future runs will skip it.

"Our tests need services (a database, env vars)." Point test at a command that runs your unit tests only, or tell us during onboarding and we'll set it up together.

Need a hand? karthik@versyka.com