The package version runs ahead of the newest published tag

Install from npm, run mb, read the docs on port 2525

The whole getting-started path is one install command, one command to start it, and a browser.

npm install -g @mbtest/mountebank

Start it with mb, and the documentation is then served locally at http://localhost:2525. The public site lives at mbtest.dev, and the getting started guide is at mbtest.dev/docs/gettingStarted. If the defaults do not suit you, the command line has its own documented page at mbtest.dev/docs/commandLine. One naming detail is worth carrying in your head: the npm package is scoped as @mbtest/mountebank, and beta builds go under the beta npm tag rather than onto the main one. No beta build is published unless it has passed all tests, which is a stronger guarantee than most projects make about their early versions.

The manifest sits two versions ahead of the newest tag

package.json declares version 2.9.6 for @mbtest/mountebank, while the newest published tag is v2.9.4 from 2026-04-15, ahead of v2.9.3 in March 2026 and v2.9.2 in September 2025. So the repository carries two patch versions of work that were never cut and published, which is what a project between builds looks like from the outside. Two other details in the same file explain how the tool is packaged. The bin block maps the command mb to ./bin/mb, which is why the executable is two letters rather than the package name, and main points at ./src/mountebank.js, so the tool can also be required as a library. The files array lists exactly what ships: bin, src, the two package files, README.md, the legal file and a JSON record of published versions. That last one is unusual and deliberate, since a machine-readable history shipped inside the package is something tooling can consume.

Thirteen protocols, some built in and some from extensions

The protocol list is the actual product. mountebank implements http, https, tcp in both text and binary modes, smtp, ldap, grpc, websockets, graphql, snmp, telnet, ssh and netconf, and the README is careful about the distinction that some of those are implemented directly in the tool while others exist as community extensions. That distinction is the one to check before planning an integration test, because a protocol delivered as an extension has a different maintenance path and a different level of documentation than one in the core. The TCP entry carries its own qualifier, text and binary, which matters because a text protocol can be asserted with predicates on content while a binary one cannot. The claim the project leads with is a competitive one: it describes itself as the only open source service virtualization tool that matches commercial offerings on protocol diversity, capability and performance. That is a positioning statement rather than a benchmark, so treat it as a claim to test against the protocols you actually need.

Verify, stub, inject, record and replay

Three capabilities are named, and each answers a different testing question. Mock verification is the assertion side: you set expectations on a service your system calls and fail the test when reality does not match, which is how you test error handling without producing real errors. Stubbing with advanced predicates is the response side: conditions decide which reply to give, so a client can be walked through a sequence of answers rather than one fixed one. JavaScript injection extends that by letting the response be computed rather than looked up. Record and playback through proxying covers the case where you already have a working dependency: you let real traffic through to the real service while recording it, and then replay the recording with the dependency gone. Together these cover the three ways a service dependency enters a test, which is why the tool survives being pointed at an architecture rather than a single integration.

Your ISP can break the test suite by advertising

There is a bug report in the README that belongs in any evaluation of this project. Some tests require network access, and a few verify correct behavior under DNS failures. If an ISP hijacks the NXDOMAIN response, which some do to show an advertising page, those tests fail. The author's advice is to talk to the ISP about it, and the practical escape hatch is an environment variable, MB_AIRPLANE_MODE=true, which skips the tests requiring a DNS resolver. That variable is wired into the package scripts as the airplane target, alongside a standard test target. Two things follow from it. First, a corporate network or VPN that resolves wild subdomains will produce failures that have nothing to do with your setup, so knowing the flag saves a day. Second, the suite deliberately tests failure behavior against a real resolver rather than a mock, which is why it is sensitive in the first place.

Testing is split across two packages and five scripts

The build instructions name two packages: mountebank itself and mbTest, which holds all the out-of-process tests against mountebank. You install dependencies in both with npm install, then run everything with npm test. That single command expands into a chain worth reading: lint runs eslint over src, tasks, test, mbTest and bin, then three custom lint scripts named licenseCheck, deadCheck and objectCheck. test:cover runs mocha with --forbid-only and --forbid-pending under nyc, instrumenting src while excluding src/public. Then test:api, test:cli and test:js run the out-of-process suites. test:ci runs a shorter chain of cover, api and cli, and test:perf runs a performance suite. Several other configurations exist, with the CI pipeline in .circleci/config.yml. The forbid-only and forbid-pending flags are a small quality decision worth copying into any project with a large mocha suite, since they stop a skipped test from passing unnoticed.

Where mountebank is the wrong tool

Four cases. The first is a single service with a stable contract. If you have one dependency and its test double is a few lines of your own fake, mountebank is a process, a port and a documentation site in exchange for something you already had. The second is a language or protocol outside the thirteen listed, where a community extension is the only path and you are now maintaining that extension. The third is real end-to-end testing. Record and replay gives you a fast suite, but a recorded response is only as good as the recording, and behavior that depends on time, randomness or accumulated state is exactly what recording flattens. The fourth is contributing. The transition notice is unambiguous: work is under way to migrate and upgrade CI/CD integrations from personal accounts to organisation accounts, pull requests are welcome, and the README asks you not to expect anything to be merged until that infrastructure is running. The project credits Brandon Byars with building mountebank in the first place and maintaining it for more than a decade before handing it over, and that handover is exactly why the current state is what it is.

Editorial conclusion

mountebank suits a team with a microservice architecture whose integration tests are slow or fragile because the services they call are not there in a runnable form. It does not suit a contributor hoping to land a change this quarter, and it does not replace real end-to-end testing where timing and accumulated state matter. Before adopting, install @mbtest/mountebank globally, run mb and read the docs on port 2525, and set MB_AIRPLANE_MODE=true if your network answers NXDOMAIN with an advertisement.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. mountebank-testing/mountebank on GitHub
4. README
5. Releases