Rover 1.0 Is Now Generally Available

Rover has been the command-line entry point to the Apollo ecosystem since the earliest days of Apollo Federation. It has been the tool to publish subgraphs, run schema checks, compose supergraphs, and generally act as the bridge between your terminal and GraphOS. Today we’re shipping Rover 1.0, the biggest set of changes to the CLI since it was first released.

This isn’t a 1.0 in the “we finally feel confident enough to drop the 0.x” sense, though that’s part of it. It’s a 1.0 because auth, configuration, extensibility, and checks/publish were rebuilt around how teams are running Rover today. This includes local development and CI, across multiple graphs and environments, and through agentic tooling built on top of Rover.

Here’s what’s new.

Auth & Identity: OAuth instead of static API keys

Static API keys are simple, but they’re also the thing security teams ask you to rotate, the thing that leaks into CI logs, and the thing nobody remembers the scope of six months later.

Rover 1.0 introduces OAuth-based auth flows as an alternative to long-lived static API keys. Instead of minting a key in Studio and pasting it into an environment variable, you can now authenticate Rover interactively and let it handle token exchange and refresh for you:

1rover auth login

Alongside the new auth flow, Rover 1.0 adds first-class API key and grant management so you can manage credentials Rover is using without leaving the CLI:

1rover api-key create my-org client-credentials my-ci-job2rover api-key list my-org 

Static API keys aren’t going away as they’re still the right fit for a lot of CI pipelines, but they’re no longer the only path, and they’re no longer the easiest path either.

Config & lifecycle: profiles instead of environment variables

Rover has long supported multiple named auth profiles, but a lot of day-to-day configuration, such as graph refs, endpoints, output preferences, has historically lived in a scattering of environment variables that were easy to lose track of across shells, machines, and CI jobs.

Rover 1.0 consolidates that configuration into Rover profiles, giving you a single, inspectable place for the settings a given graph or environment needs:

1rover config list2rover config show --profile production

The same release also removes legacy Apollo Federation 1 support from Rover. Federation 2 has been the default for new graphs for a long time now, and carrying Federation 1 composition logic in the CLI was adding complexity for a shrinking number of users. If you’re still on Federation 1, now’s a good time to plan your migration. Federation 2 is a superset of Federation 1’s capabilities, and Apollo’s migration guide walks through the upgrade path.

A more reliable plugin system

Rover has always relied on a plugin mechanism, with the supergraph plugin as the clearest example, to keep specific pieces of functionality independently versioned. Rover 1.0 makes that mechanism more reliable, so the plugins backing a given Rover install behave the same way every time you run it.

That means:

• Pinned versions, so a given Rover install always resolves to the exact plugin version it expects, instead of a version that can drift out from under you
• Reproducible results, so check, publish, and composition behave identically run after run on your laptop and in CI
• Transparent install and download behavior, so that when Rover needs a plugin binary, it tells you what it’s fetching, from where, and why, instead of silently pulling something down

The result is a CLI you can trust to behave the same way today as it did yesterday, wherever it’s running.

Checks & Publish: contract variants

If you’re using contracts to expose different views of your supergraph to different consumers, Rover 1.0 now understands them natively in the two commands you run most: check and publish.

rover subgraph check and rover subgraph publish now surface contract variant results directly, so you can see how a proposed change affects each contract, not just the underlying source variant, before you ship it:

1rover subgraph check my-graph@my-variant \2  --schema ./products.graphql \3  --name products \4  --include-contract-checks

No more publishing a change, then separately checking Studio to see whether it broke a contract downstream. The information you need is in the output of the command you were already running.

Checks & Publish: client operations

We’ve introduced client operation checks to Rover. These were previously located in the legacy Apollo CLI. With this addition to Rover, the Apollo CLI is officially deprecated. This feature allows you to verify your client operations against your graph variants, ensuring that your code works with a target graph before you ship. You can see how this works in Rover by reading through the guide here.

Upgrading

Rover 1.0 is a major version bump, and while most of these changes are additive, the removal of Federation 1 support and the shift away from some environment-variable-based configuration mean it’s worth reading the migration guide before upgrading CI. To get the latest version:

1curl -sSL https://rover.apollo.dev/nix/latest | sh

or via npm:

1npm install -g @apollo/rover

Rover’s source is available on GitHub, and that’s also the best place to reach us. If you hit something that doesn’t feel right in 1.0, or you’re building a plugin and want to talk through the interface, open an issue. We’d love to hear from you.

Written by

Brian George

Read more by Brian George