SHSelfHostIndex
SC

Scalar

Modern OpenAPI documentation and API reference

Developer Tools & Git ★ 16.2k stars Easy setup MIT

Scalar is an open-source API documentation platform that generates interactive reference docs from OpenAPI specs. It includes a built-in API client and can be self-hosted alongside your services.

Official siteSource code

Key features

  • Interactive API reference
  • Built-in API client
  • OpenAPI native
  • Themeable docs

Pros & cons

Strengths

  • Interactive try-it client
  • Modern polished design
  • Easy static deployment

Trade-offs

  • Young rapidly evolving project
  • Docs still maturing

Scalar replaces

Self-hosted Stoplight alternativesSelf-hosted ReadMe alternatives

Last reviewed Aug 26, 2026 · 769 words

The whole deployment can be one HTML file:

<!doctype html>
<html>
  <body>
    <script id="api-reference" data-url="/openapi.json"></script>
    <script src="https://cdn.jsdelivr.net/npm/@scalar/api-reference"></script>
  </body>
</html>

Serve that from Caddy next to the API it documents and you have reference documentation that looks better than Swagger UI, reads like a modern product's docs, and includes a working request client with no second tool to install. Scalar is MIT licensed, 15,993 GitHub stars, TypeScript, and it is the tool I now reach for when a self-hosted service needs docs that the people using it will actually read.

Three ways to serve it, all cheap

The static file above is the lowest-effort route and needs the browser to reach both the page and the spec URL. The second route is the official container image, which serves the reference on its own port and takes the spec location as configuration, useful when the API is somewhere else entirely. The third is a framework integration: packages exist for Express, Hono, Fastify, NestJS, FastAPI, Django, Laravel and ASP.NET Core among others, mounting the docs at a path inside the API process itself, which means auth and CORS are handled for you because the docs and the API share an origin. For a homelab service, the integration route is the one with the fewest moving parts; for documenting something you did not write, the static file wins. Either way the listed 256 MB minimum is generous; the static route needs nothing beyond a web server.

The built-in client replaces a separate tool for the simple cases

Every operation in the reference has a "try it" panel that sends real requests with headers, auth and body, and shows the response inline. For exploring an API you host, this covers what most people open Hoppscotch for. It does not replace a proper client for saved collections, environments and scripting; Scalar ships a standalone API client app for that, but the embedded one is deliberately a quick-fire tool. The key operational detail is that requests go from the reader's browser to your API, so CORS must allow the docs origin, or the docs must live on the same origin. The number of "try it does nothing" bug reports that are actually a missing Access-Control-Allow-Origin header is high.

Scalar against Swagger UI and Redoc

ScalarSwagger UIRedoc
Interactive requestsYes, full clientYes, basicNo (free edition)
DesignModern, three-column, themeableDated, functionalClean, read-only
OpenAPI 3.1 supportYesYesYes
Maturity2023 projectVery matureMature
Self-host effortOne fileOne fileOne file

Swagger UI is everywhere, which is its main virtue; it is also the reason API docs have looked the same for 10 years. Redoc produces the best static read-only reference and no request client. Scalar takes Redoc's layout, adds the client Swagger has, and looks like a product page. For an internal API the difference is cosmetic. For an API other people integrate against, it is the difference between being taken seriously and not.

Young project: pin the version

The catalogue lists "rapidly evolving" as a drawback and it is true in the way that matters. The CDN snippet above loads the latest build every time, which is fine for a demo and a liability for a docs page you want to be stable: a breaking change in the configuration format lands on your readers without you touching anything. Pin it, @scalar/[email protected] with a version you tested, and bump deliberately. The configuration surface has also been reshaped more than once, and older blog posts describe options that no longer exist; the official docs at scalar.com are the only source to trust, and they are still catching up in places.

What I'd do

If the API is your own code, mount the framework integration at /docs and pin the package version in your lockfile. If it is someone else's service, put the 6-line HTML file above in a static directory behind Caddy, pinned to a tested version, and add a CORS header on the API for the docs origin. Skip the container image unless you need the docs on a separate host. Keep Swagger UI only where a tool already generates it and nobody reads it anyway. For anything a human will consult more than once, Scalar is the better developer tooling choice, and it costs about 10 minutes.

Compare Scalar

3 head-to-head comparisons.

Similar developer tools & git apps