Skip to content
Shiftrail
GlobalMulti-region contract coordination & rollout

Change the event.Keep every consumer.

Shiftrail is the agent that turns a distributed change into coordinated execution: it finds the global impact across all your repositories and regions, plans the rollout, and opens the pull requests. You keep control of merge and deploy.

See how it works

PaymentCreated v1, 4 consumers in production

Available today

Starting with Kafka and Protobuf. The agentic migration workflow is designed to extend across APIs, shared libraries, data contracts, and other cross-service changes.

  • Apache Kafka
  • GitHub
  • GitHub Actions
  • Java
  • Kotlin

The problem

Your schema registry already knows the change is breaking. It rejects the pull request, and that is where it stops. What follows is weeks of archaeology: finding every consumer across dozens of repositories, writing dual-read code in each one, sequencing deploys, waiting out consumer lag, and hoping nobody replays an old topic.

Shiftrail does that part.

One contract change. Every service, in the right order.

The agent owns the work between deciding to make a change and safely completing it. Event contracts are the first supported workflow, executed in four moves.

Map

Find every reader, with receipts.

Static analysis across your repositories finds each producer and every field-level reader. Each edge carries a file, a line, a commit and a confidence score.

  • Facts and inferences are kept apart
  • Unproven consumers block automation until an owner confirms

impact: PaymentCreated.amount

4 consumers found

orders-service

writes amount, currency · PaymentPublisher.kt:38

producer
  • billing-service

    fact0.99

    PaymentListener.java:52 @ 4d21f3b · reads amount, currency

  • fraud-detector

    fact0.97

    FraudTopology.kt:30 @ b70a9e2 · reads amount

  • notifications-worker

    fact0.94

    NotificationDispatcher.ts:44 @ e3f5c10 · reads currency

  • order-read-model

    needs owner0.58

    OrderProjector.scala:19 @ 51aa0d4

Judge

Wire-compatible is not the same as safe.

Deterministic checks run first. Then every change is judged on four axes: wire, source, behavior, and whether old and new versions can coexist through a rolling deploy.

  • Registry and Buf results feed the verdict
  • The model never overrides a deterministic failure

payment.proto

proposed change

message PaymentCreated {
string payment_id = 1;
- double amount = 2;
- string currency = 3;
+ Money amount = 2;
}
  • WireField 2 changes wire type: double → messageunsafe
  • SourcegetAmount() now returns Money in generated codeunsafe
  • BehavioralDepends on how consumers read amountunknown
  • OperationalMixed versions fail during a rolling deployunsafe
Registry check: BACKWARD incompatibleNeeds a migration plan

Plan

A rollout, not a patch.

Shiftrail picks a strategy and orders it into steps. Each step has a gate that must hold before the next one starts, and irreversible steps are marked before anything runs.

  • Expand, dual-read, dual-write, contract
  • Replay and retention are part of the risk check

plan: expand and contract

8 steps · 1 irreversible

  1. Expand the contract

    Plan approved by a human

    Shiftrail
  2. Migrate consumers to dual-read

    Project CI passes on every consumer PR

    Shiftrail
  3. Deploy consumers

    Deployment observed for each consumer

    Your deploy
  4. Producer dual-writes

    All consumer gates satisfied

    Shiftrail
  5. Verify semantic equivalence

    Semantic assertions hold

    Shiftrail
  6. Stop legacy writes

    Explicit approval of an irreversible step

    You approve
  7. Remove legacy reads

    No legacy-only events left to read

    Shiftrail
  8. Retire the old fields

    Cleanup PR reviewed and merged

    Shiftrail

Execute

Draft pull requests in every repo. Gates between them.

Each consumer gets a tested pull request in its own repository. Your CI decides whether it passes. Shiftrail repairs failures, then waits for your deploys before it moves on.

  • Never merges, never deploys
  • Every action lands in the audit log

migration: PaymentCreated v2

step 2 of 8

  • billing-service#412

    Build, unit, contract fixtures

  • fraud-detector#88

    Build, unit, contract fixtures

  • notifications-worker#1203

    Test failure: ReceiptRendererTest, patch 2 of 3

  • order-read-model

    Awaiting owner confirmation of field usage

Gate: producer dual-write

holding

Opens when every required consumer has deployed dual-read.

2/4

Autonomy, with the brakes built in.

Shiftrail may be slower than your best engineer. It is never allowed to be confidently unsafe.

Pull requests are the only write path.

Changes land as draft pull requests on a branch. Your review rules, branch protection and CI stay exactly as they are.

shiftrail/dual-read-moneymainmerged by your team

Irreversible steps wait for a person.

Once new-only events exist, rollback stops being free. Those steps are marked in the plan and need an explicit approval.

Hold to approve: stop legacy writes

Least privilege, by design.

Scoped credentials, ephemeral runners, and no access it does not need.

  • GitHub App on an allowlist of repositories(granted)
  • Read-only Schema Registry access(granted)
  • CI status, optional deploy metadata(granted)
  • Production deploy credentials(never requested)
  • Write access to brokers or the registry(never requested)

Every decision is on the record.

Plans, approvals, PRs, CI results and gates are written to an append-only audit log, tied to commit SHAs.

  • 14:05:55CI_FAILED
  • 14:05:08PR_OPENED
  • 14:04:21PLAN_APPROVED
  • 14:03:34PLAN_GENERATED
  • 14:02:47IMPACT_DISCOVERED

A coding agent edits. A migration agent coordinates.

Registries detect incompatibility and coding agents work inside one repository. Shiftrail gives the entire change an owner: one agentic workflow with shared context, rollout state, and safety gates across every affected service.

What each tool covers in an event-contract migration
CapabilityRegistryAgentShiftrail
Detects a breaking changeYesNouses yours
Finds every consumer across repositoriesNoNoYes
Chooses a migration strategyNoNoYes
Writes the code changeNoone repoYes
Orders the rollout across servicesNoNoYes
Waits for deploys and gates each stepNoNoYes
Keeps migration-wide state and an audit trailNoNoYes

Questions platform teams ask first.

Bring us your next breaking change.

We work hands-on with a small group of platform teams. Bring one real migration: we map it, plan it and open the pull requests.

or write to partners@shiftrail.dev
  • Kafka with Protobuf and a schema registry today
  • 20 or more independently deployed services
  • GitHub, with CI on every pull request
  • Java or Kotlin consumers