Redocly CLI is a good tool. If you’ve used it to lint OpenAPI files, bundle a multi-file spec into one, or build Redoc docs from the terminal, you already know that. So why look for a Redocly CLI alternative at all?
Usually it comes down to shape. Redocly CLI is a focused, code-first specialist: lint, bundle, split, join, build docs. That’s exactly right for some teams and not enough for others. If you want one tool that also designs, mocks, and tests your API, the CLI isn’t trying to be that tool, and it shouldn’t be.
This article is about the Redocly CLI (the open-source @redocly/cli package), not the hosted Redocly docs product. If you’re comparing the hosted docs platform or Redoc itself, read our roundup of Redocly alternatives for API documentation instead. This post is for people who type redocly lint and redocly bundle and want to know what else fits their workflow.
What Redocly CLI actually does well
Redocly CLI is open source and terminal-native. You install it once and get a tight set of commands that do their jobs cleanly. The Redocly CLI docs cover all of them, but here’s the short version.
Linting is its signature strength. redocly lint validates your OpenAPI, AsyncAPI, Arazzo, or Open-RPC description and then runs style-guide rules on top. You configure everything through a redocly.yaml file: pick a built-in ruleset (minimal, recommended, recommended-strict, or spec) or author your own custom rules. That config-driven governance is hard to beat if you want consistent API design enforced in CI across many teams.
npm install -g @redocly/cli@latest
redocly lint openapi.yaml
Bundle, split, and join handle spec plumbing. redocly bundle follows $ref pointers and produces one consolidated file. redocly split does the inverse, exploding a single description into a multi-file layout. redocly join (experimental) merges multiple OpenAPI files into one.
redocly bundle openapi.yaml --output dist/openapi.json
Docs come from build-docs. It produces a standalone Redoc HTML page, and preview-docs gives you a live local preview.
redocly build-docs openapi.yaml -o docs.html
So if your needs are “validate against a style guide, bundle the spec, and ship Redoc docs, all from the terminal,” Redocly CLI is a strong default. Many teams should keep it. The reasons to look elsewhere are about scope, not quality.
Why people look for an alternative
A few patterns show up again and again:
- You want an all-in-one platform, not just lint plus docs. Redocly CLI doesn’t run API tests and doesn’t host a mock server. If you also need design, mocking, and a test runner, you’re assembling a toolchain around it.
- You want a GUI alongside the CLI. Redocly is code-first by design. If your team includes people who’d rather work visually, terminal-only governance is a hard sell.
- You want a built-in test runner for CI. Linting catches spec problems. It doesn’t tell you whether the running API behaves. That’s a separate tool.
- You don’t want to stitch together five tools. Spectral for lint, Redocly for bundle and docs, Postman or Newman for tests, something else for mocks. That works, but it’s a lot of moving parts to maintain.
Each of those points to a different alternative. Let’s match them up.
The shortlist, by what you actually wanted
Apidog, if you want one platform for the whole API lifecycle
Apidog is an all-in-one API platform: design, mocking, testing, and documentation in one place, with a CLI for import, export, and CI test runs. It’s the right pick when you’d rather have a single tool for the whole lifecycle than glue together a linter, a bundler, a test runner, and a mock server.
Here’s the honest part. Apidog does not have a configurable, code-first style-guide linter with custom rulesets like Redocly’s lint. There’s no apidog lint command and no way to author Spectral- or Redocly-style custom rules through the CLI. Apidog validates structure when you import a spec, but if strict, customizable design governance is the one thing you care about, Apidog won’t replace redocly lint on its own. Pair it with Spectral for that job. We’ll come back to this.
What Apidog gives you that Redocly CLI doesn’t: a visual designer, a built-in mock server, a visual test builder, and a CI test runner. The CLI handles the parts that belong in a terminal.
# Install and authenticate (token from the app: avatar > Account Settings > API Access Token)
npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
# Import a spec into a project (validates + resolves multi-file $refs)
apidog import --project 123456 --format openapi --file ./openapi.json
# Export a single consolidated file, and pick your OpenAPI version
apidog export --project 123456 --format openapi --output ./openapi.json --oas-version 3.1
# Run a test scenario in CI with multiple report formats
apidog run --project 123456 -t <testScenarioId> -e <environmentId> -r "cli,html,json,junit"
apidog import does the validate-on-ingest job, and apidog export does a bundle-on-the-way-out job (it emits one file and can upgrade the OAS version). The full command list lives in the Apidog CLI docs, and our complete Apidog CLI guide walks through every flag. Best for: teams that want design, mock, test, and docs under one roof.
Spectral, if all you wanted from Redocly was the linter
If the only thing you reach for is redocly lint, you don’t need to switch platforms. Spectral from Stoplight is the open-source, rule-based linter that overlaps most directly with Redocly’s linting. You write rules in YAML, run them against any OpenAPI or AsyncAPI document, and wire it into CI.
Spectral and Redocly’s linter are close cousins. Both are config-driven, both ship rulesets, both let you author custom rules. The choice between them often comes down to ecosystem fit and which ruleset format your team already knows. Our deep dive on Spectral OpenAPI linting covers rule authoring, and the broader guide to API linting compares the linting landscape if you want the full picture. Best for: teams whose real need is pure, customizable spec linting.
Scalar or Bump.sh, if you mostly wanted the docs
If the part of Redocly CLI you cared about was build-docs, the alternative is a documentation tool, not a platform. Scalar and Bump.sh both turn an OpenAPI description into hosted, browsable reference docs, each with its own look and feature set. They focus on the docs experience rather than linting or testing. Best for: teams whose primary goal is good-looking, maintainable API reference docs.
swagger-cli, which isn’t really an option anymore
You’ll still see swagger-cli mentioned in old guides, so it’s worth being clear: swagger-cli is deprecated. The swagger-cli GitHub repo says it’s no longer maintained and points users to Redocly CLI as the successor.
It only ever had two commands, swagger-cli validate and swagger-cli bundle. It never linted with style rules, never generated docs, never ran tests, and never mocked anything. If you’re on it today, the move is off it, not to it. Our guide on how to use swagger-cli covers what it did, and Redocly even publishes a migration guide from swagger-cli with the exact flag mapping. We’ll include that mapping below for completeness.
Comparison table
Here’s how the options line up against the jobs Redocly CLI handles. “Lint custom rules” means a configurable, code-first style-guide linter with custom rulesets.
| Tool | Lint custom rules | Bundle | Docs | Mock | Test | GUI | Open source | Best for |
|---|---|---|---|---|---|---|---|---|
| Redocly CLI | Yes | Yes | Yes (Redoc) | No | No | No | Yes | Code-first lint, bundle, and docs governance from the terminal |
| Apidog | No | Via export | Yes | Yes | Yes (CI runner) | Yes | No (freemium) | One platform for design, mock, test, and docs |
| Spectral | Yes | No | No | No | No | No | Yes | Pure, customizable OpenAPI/AsyncAPI linting |
| Scalar / Bump.sh | No | No | Yes | No | No | Yes | Varies | Hosted API reference docs |
| swagger-cli | No | Yes | No | No | No | No | Yes (deprecated) | Nothing new, it’s unmaintained |
A note on the table: Apidog’s “Via export” means apidog export emits one consolidated file, which covers the practical reason you’d run redocly bundle, but it’s not a like-for-like bundle command. And Apidog is freemium, not open source, while Redocly CLI and Spectral are both open source. Call those tradeoffs what they are.
swagger-cli to Redocly CLI bundle flag mapping
If you’re on deprecated swagger-cli and Redocly is your destination for bundling, the flags map cleanly:
| swagger-cli | Redocly CLI | Meaning |
|---|---|---|
-o, --outfile <file> |
--output (or -o) |
Write to a file instead of stdout |
-t, --type <json|yaml> |
--ext <json|yaml|yml> |
Output file type |
-r, --dereference |
-d, --dereferenced |
Fully inline all $refs |
So swagger-cli bundle -o output.json becomes redocly bundle --output output.json.
A clear recommendation
There’s no single winner, because the right answer depends on which Redocly CLI job you’re trying to replace.
Keep Redocly CLI if its governance is exactly what you need. A lightweight, open-source, config-driven linter, bundler, and Redoc doc builder that you run purely from the terminal is a genuinely good setup. Nothing here is a reason to abandon a tool that fits.
Choose Apidog if you’re tired of assembling a toolchain and want design, mocking, testing, and docs in one platform with a CLI for the terminal-shaped parts. You stop maintaining separate tools for each stage and get a GUI for the people on your team who want one. Just be clear-eyed that you’ll pair it with Spectral if you also need custom-rule linting. The Apidog CLI in CI/CD guide shows how the test runner slots into a pipeline, and Apidog CLI vs Newman compares it to the runner many teams already use. You can download Apidog and try it free, no credit card required.
Choose Spectral if linting is the whole point. Don’t switch platforms to replace one command.
The honest framing: Redocly is a code-first CLI specialist, and Apidog is an all-in-one visual platform. They’re different paradigms, not a drop-in swap. Pick by fit.
FAQ
Is Apidog a drop-in replacement for Redocly CLI? No, and it’s better to be upfront about that. Apidog covers more of the lifecycle (design, mock, test, docs) but it doesn’t have a custom-ruleset linter like redocly lint. If strict, configurable spec governance is your main job, keep Redocly’s linter or use Spectral. Apidog wins when you want one tool for the whole API lifecycle instead of several.
Does Apidog CLI have a lint command? No. Apidog validates structure when you import a spec with apidog import, but there’s no apidog lint and no way to author Spectral- or Redocly-style custom rules through the CLI. For that, pair Apidog with Spectral.
Can I bundle an OpenAPI file without Redocly CLI? Yes. apidog export --project <id> --format openapi --output ./openapi.json emits a single consolidated file and can target a specific OpenAPI version with --oas-version. It’s not a literal bundle command, but it covers the same practical need. If you only want bundling and nothing else, redocly bundle is still a fine, focused choice.
Should I use swagger-cli in 2026? No. swagger-cli is deprecated and unmaintained, and its own repo points to Redocly CLI as the successor. It only ever validated and bundled. Use Redocly CLI for that job, or move into a platform like Apidog if you want the rest of the lifecycle too.
What’s the difference between this and the Redocly docs platform comparison? This post is about the open-source @redocly/cli tool: lint, bundle, split, join, and build-docs. If you’re comparing the hosted Redocly docs product or Redoc as a documentation renderer, read Redocly alternatives for API documentation instead. The two cover different products that happen to share a name. For the spec itself, the OpenAPI Specification is the source of truth, and the Redocly CLI on npm is where you’ll find current install details.
