WireMock Cloud vs open-source WireMock

When does WireMock Cloud beat self-hosted open-source WireMock?

If your team mocks APIs for tests and is deciding whether the hosted service is worth paying for, the answer depends on what you need the mock layer to do. WireMock Cloud fits teams that want hosted management, stateful or chaos scenarios and single sign-on without operating the mock infrastructure themselves. Open-source WireMock fits teams that can run a container or standalone process inside their own CI pipeline and test environments. The decision turns on three things: which features your tests actually use, who will operate the mock infrastructure day to day, and where your mock definitions are permitted to live.

Start with the feature list, drawn from your existing test suites rather than from the product comparison. Stateful mocking, where a mock changes its response after earlier calls, and chaos rules, which inject delays or faults, are the capabilities most likely to separate the two options. Check whether your tests depend on them, then confirm with WireMock which of these features are included in the Cloud plan you are considering and which the open-source engine covers through its own extensions or configuration. If your suites only need static request matching and response stubs, the open-source engine may cover everything you require.

Next, decide who runs the mocks. A self-hosted WireMock needs a maintained image version, a place in your pipeline, access control for anyone who edits stubs and an owner for upgrades. A hosted service moves that work to the vendor but adds a subscription that recurs and a dependency on their availability. Ask the vendor where Cloud-hosted definitions are stored, how long they are retained, and how SSO and user roles are enforced. If mock definitions contain sensitive payloads or internal endpoint details, those answers may settle the question before any feature comparison does.

Which option fits each mocking scenario

This table matches common mocking needs to WireMock Cloud or self-hosted open-source WireMock. Read each row as a condition: if it describes your team, that option is the likelier fit. Confirm plan-specific features such as stateful mocking, chaos rules and SSO with WireMock before you decide.

Scenario	Better fit	Why
Stubbing HTTP calls in unit or integration tests	Open-source WireMock	Standalone or embedded WireMock runs inside your test suite with no vendor service in the loop.
Stateful flows such as a multi-step checkout	WireMock Cloud, after confirming scope	Open-source scenarios cover simple state changes. Check whether your flows fit them or need Cloud's stateful mocking.
Chaos or fault injection in staging	WireMock Cloud if chaos rules are required	Basic delays and faults are achievable in open source. Managed chaos rules save building and maintaining your own tooling.
Sharing mocks across several teams	WireMock Cloud	Hosted mock APIs give every team one shared location. Open source means you host, secure and govern a shared instance yourself.
Running mocks in air-gapped CI	Open-source WireMock	A container image or JAR runs inside your network. Hosted mocks need outbound access to the vendor service.
Needing SSO for access to mock definitions	WireMock Cloud, after confirming the plan	Hosted console access can use vendor SSO. Open source relies on a proxy in front of it, such as your identity provider.
Keeping definitions in version control and running containers	Open-source WireMock	Mapping files live in Git, get code review and deploy with the same pipeline as the service under test.
Exporting mocks to avoid vendor lock-in	Open-source WireMock	Definitions stay in files you own. Confirm the export format and any Enterprise requirement with WireMock before migrating.

What WireMock Cloud adds over open-source WireMock

WireMock Cloud wraps the mocking engine with hosted services for sharing, state, fault injection, specification sync and access control. Each capability below matters under different team sizes and test designs, and the open-source engine covers many of the same mocks without them.

Hosted mock APIs

WireMock Cloud runs mock APIs as a managed service, so teams do not start and maintain a WireMock process for each environment. This matters when several squads or partner teams need the same stub endpoints without each one running infrastructure. The cost trade-off is recurring subscription spend against the setup and upkeep of your own containers. Check the current free tier limits and Enterprise terms directly with WireMock before you size the decision.

Stateful mocking

Stateful mocking lets a stub return different responses depending on earlier requests, such as a payment that moves from pending to settled after a status check. It matters when a test scenario depends on the order of calls rather than on a single request. Open-source WireMock supports scenarios for this purpose, so confirm with WireMock which stateful features are Cloud-only before assuming a gap. Ask for a written list of supported state behaviors.

Chaos testing

Chaos testing lets a mock inject faults such as delays, dropped connections or malformed bodies to see how a client handles failure. It matters when resilience tests need to run in shared environments without changing the real dependency. Some fault injection exists in open-source WireMock through fixed delays and fault settings, but randomized or managed chaos rules may differ. Confirm the current chaos feature set with WireMock before planning tests around it.

OpenAPI sync

OpenAPI sync keeps mock definitions aligned with a service's published specification, so stubs do not drift from the contract. It matters when many teams change APIs often and mocks must reflect the latest schema. Open-source WireMock can be driven from specification files in your own pipeline, which shifts the sync work to your team. Check how each approach handles spec updates and which spec versions are supported.

SSO and access control

Single sign-on and role-based access let an organization manage who can view and change mock APIs through its identity provider. It matters for regulated teams that need audit of who changed a test asset and need to remove access when staff leave. Standalone WireMock has no built-in user directory, so access control is usually handled by the network, the proxy or the CI platform. Ask WireMock which SSO protocols and roles the hosted service provides and whether audit logs are included in your plan.

How WireMock Cloud and open-source WireMock compare on capabilities

This table compares the hosted WireMock Cloud service with the Apache-2.0 WireMock engine you run yourself, row by row for each capability a mocking decision usually turns on. Where a capability is not covered by the information available here, the cell tells you what to confirm with the vendor or in your own test environment before you decide. Read the rows for hosting, export and CI first, since they usually settle whether the open-source engine fits your workflow.

Capability	WireMock Cloud	Open-source WireMock
Licensing	Commercial hosted service with free and paid tiers	Apache-2.0 licensed engine you can run without a subscription
Hosting	Hosted by the vendor, with mock APIs managed in the cloud	Standalone process, container or library in infrastructure you control
Stateful mocking	Offered as a Cloud feature; confirm the supported state model and limits	Confirm which scenario and state behaviors your engine version supports
Chaos testing	Offered as a Cloud feature; confirm fault types and how rules are scheduled	Confirm which fault injection options your engine version exposes
OpenAPI import and sync	Offered in Cloud; confirm whether sync is one-way and how changes are reviewed	Not covered in this comparison; confirm import tooling and sync approach with your team
SSO and user management	Offered in Cloud; confirm the identity protocols and plan level required	Not applicable as a hosted login; access control depends on how you secure your own network
Export as WireMock OSS JSON	Available as an Enterprise feature; confirm the export format and any restrictions	Mappings are plain JSON files you author, version and load into the engine
CI integration	Reached through the hosted service from your pipeline; confirm the access method and tokens	Runs standalone or in containers inside your own CI and test environments

Where mock definitions and test data live under each model

Mock definitions, recorded requests and test data end up somewhere under either model, and that location decides who can reach them, who operates them and what evidence you can produce. The cards below cover the decisions regulated teams should settle before choosing between WireMock Cloud and self-run WireMock.

Where the definitions are stored

WireMock Cloud keeps mock APIs, their rules and request logs on WireMock's hosted service, so the data location is set by the vendor's hosting regions. Self-run WireMock stores mappings and recorded requests in files, containers or volumes that your own team places, such as a repository, a build artifact or a cluster volume. Confirm the hosting regions for Cloud in writing and check whether any mock payload contains personal or account data that would need to stay in a specific jurisdiction.

Who operates the hosting

With WireMock Cloud, the vendor runs the service, applies its updates and maintains availability, and you manage your tenant and users. With open-source WireMock, your platform or test engineering team runs the JVM process or container, patches it and handles upgrades. Both models need an owner. Write down who responds to an outage in the mock service, who approves upgrades and who restores definitions from backup.

Identity, access and SSO

Check which sign-in methods WireMock Cloud supports for your identity provider and whether SSO and role-based access are available on your plan. Open-source WireMock has no built-in user accounts, so access control comes from the network path, the reverse proxy or gateway in front of it, and the controls around your CI system. Confirm SSO options with WireMock before you assume your directory integration will work.

Audit evidence for compliance readiness

Auditors often ask who changed a mock, when it changed and which test run used it. Ask WireMock Cloud for its audit log contents, export options and log retention period, and confirm them in the contract. With self-run WireMock, you produce this evidence yourself from Git history, CI logs and access logs of the host or proxy. DeployOpen prepares these controls and records for assessment, but independent auditors and certification bodies issue any attestation.

Reachability from CI runners

A hosted mock service must be reachable from your CI runners, which may sit behind egress rules, private subnets or allow lists. Self-run WireMock can run inside the same network as the system under test, so no traffic leaves your environment. Map which runners call the mocks, whether they need outbound access to a vendor domain, and how credentials for the mock service are stored and rotated in your pipeline.

What each edition and license allows

WireMock is licensed under Apache-2.0, so your team can download, run and modify the engine without a subscription to the company behind it. You run it yourself as a standalone process, in a container, or embedded in a test suite, and every mock definition stays in files and repositories you control. The trade-off is that features the hosted service adds, such as stateful mocking, chaos rules, OpenAPI sync and SSO, are not part of this edition, so your team builds or scripts any equivalent it needs.

Cost model. The license carries no fee. Cost comes from the hosts that run the engine, the time to wire it into CI, and the engineers who maintain mapping files.
Limits. The engine does not impose a vendor-set cap on mock calls, mock APIs or users. Capacity depends on the machines and runners you provide.
Hosting. You choose where it runs, including air-gapped networks and internal CI runners, which keeps request and response data inside your environment.
Missing pieces. Hosted collaboration, a managed console with SSO, and stateful or chaos scenarios are not provided by the open-source engine, so plan to build them or drop them.

Before you commit, confirm the WireMock version you will deploy and check its documentation against the scenarios your team actually tests.

What WireMock Cloud and self-hosted WireMock cost to own

WireMock Cloud costs are set by a subscription or a quote, and the Enterprise tier is priced on request. Your comparison material describes a free tier limited to one user, 1,000 mock calls a month and three mock APIs, which is useful for a proof of concept but unlikely to cover shared test environments. Call volume, the number of mock APIs, the number of named users and the number of environments are the main levers on the bill. When requesting a quote, ask whether pricing is per user, per call or per API, which features are included (stateful mocking, chaos rules, OpenAPI sync and SSO), how many environments are covered, what support terms apply, and whether exporting definitions as WireMock OSS JSON is part of the tier you are quoted.

The open-source WireMock engine carries no license fee under Apache-2.0, so the recurring cost of self-hosting is operational. It includes compute for the containers or standalone processes that serve mocks, CI minutes each time pipelines start them, and engineering time to write and maintain mapping files and wire them into pipelines. Upgrades, security patches and on-call coverage for a shared test environment recur for as long as the mocks are in use. The one-time costs are the initial setup, the migration of existing definitions and the rebuilding of any Cloud-only feature you depend on. The main drivers upward are the number of teams, environments and parallel pipeline runs, so count these before comparing totals.

Compare both sides over the same period and include the one-time migration effort, not only the monthly figures. Confirm with WireMock which Cloud features your team uses today, and confirm with your own engineers which of them have an open-source equivalent in the version you plan to run. Where a gap exists, estimate the cost of building or operating that capability yourself. If you want the self-hosted path scoped in writing, DeployOpen plans and implements WireMock in your own infrastructure under a fixed scope agreed before work starts, and a quote follows from that scope. DeployOpen does not publish a price list.

How to move mock APIs from WireMock Cloud to self-hosted WireMock

This sequence moves each hosted mock API into WireMock you run yourself, with a documented inventory, a tested CI run and a clear list of Cloud-only behavior that you have either rebuilt or accepted as a gap.

Inventory mock APIs and stateful scenarios
The platform or QA lead lists every mock API in the WireMock Cloud account, along with the consuming services, the test suites that call each one, and any stateful scenarios that change responses over successive calls. Record which mocks use response templating, custom extensions, proxying or chaos rules, because those are the items most likely to need rework. Confirm with the vendor which features your current plan and entitlements include before you rely on any export path. The step is done when every mock has an owner and a status of export, rebuild or retire.
Confirm export entitlement with the vendor
Before any work starts, the account owner asks WireMock whether your subscription includes exporting definitions as WireMock OSS JSON, which the vendor documents as an Enterprise feature. Ask in writing which export formats, limits and file layouts apply to your account and whether exported files can be used with the open-source engine without modification. If the export is not included, decide whether to recreate mappings by hand from the Cloud interface or to keep the hosted service until the entitlement question is settled. The step is done when the answer is in writing and the team has agreed on the export route.
Export definitions and review the mapping files
The platform engineer exports each mock API as WireMock OSS JSON and stores the files in the team's Git repository alongside the test code. Open each mapping file and check request matchers, response bodies, headers and priorities against the Cloud interface for a sample of endpoints. Remove any credentials, tokens or customer-like data that appear in response bodies before committing. The step is done when every exported mapping is in version control and a reviewer has signed off on the diff.
Run WireMock standalone or in a container
The engineer starts the open-source WireMock engine, either as a standalone process on a developer machine or as a container in the test environment, and loads the exported mapping directory at startup. Check that each mapping responds with the expected status code and body when called directly with a test client. Confirm which WireMock release your team has chosen and pin it in the build configuration so results do not change silently. The step is done when every exported mapping passes a smoke call against the local instance.
Wire mocks into CI with the existing test runner
The QA or DevOps engineer adds a step to the pipeline that starts WireMock before the test stage, points the service under test at the local mock URL through an environment variable, and stops the container afterward. The existing test runner keeps its current assertions, and the pipeline publishes results in the format it already uses. Confirm that the CI runners can reach the mapping directory and the container image from your internal registry. The step is done when a pipeline run passes end to end with the self-hosted mocks and fails when a mock is changed to return the wrong response.
Rebuild or accept Cloud-only stateful and chaos behavior
For each stateful scenario or chaos rule identified in the inventory, the test engineer decides whether to rebuild the behavior in test code, such as a small stub server with state held in the test, or to accept the gap and document it. Note that behavior tied to the hosted service, such as hosted sharing or hosted chaos controls, may not have a direct open-source equivalent, and confirm the exact scope of any feature you plan to replace with the vendor's documentation. Record each decision in the migration log with a named owner. The step is done when every Cloud-only item has either passing replacement tests or a documented acceptance.
Run parallel tests and retire hosted endpoints
The team runs the same test suites against both WireMock Cloud and the self-hosted instances for a period agreed in the migration plan, comparing responses and pass or fail results for each service. Any difference is traced to either the exported files or the test code and fixed before cutover. When results match and stakeholders accept them, the team switches the test environment variables to the self-hosted URLs, removes Cloud API keys from CI secrets, and ends the subscription at the renewal date the vendor confirms. The step is done when the hosted endpoints receive no traffic and the decommission record is filed.

What running WireMock yourself asks of your team

Running open-source WireMock is not a one-time install. Someone owns the version pin, the container image tag, the mock definitions stored in your repository, and the CI job that starts the server before tests run. Upgrades and image updates are the work most often left unowned. Each new WireMock release needs a test run against your existing stubs, and a base image update can change behavior in ways a green build will not reveal until a team hits it. Ask who approves a version change and whether it is tested against the full suite before it reaches shared pipelines.

Some of this work grows with the number of teams and environments, and some does not. Mock definition review scales directly: every team that adds stubs, response templates or request matchers adds review load and the risk of duplicate or conflicting mappings. Shared environment access also grows, because a single WireMock instance used by several squads needs agreed naming, cleanup rules and a way to reset state between runs. Backups of definitions are simpler, since the mappings are usually files in version control, but you must confirm that files and any runtime-registered stubs are both captured. Monitoring of the CI service, including server availability and job failures, is a fixed cost that falls on whoever runs your pipelines.

Most of this falls to a platform engineer or a test engineer, not to the developers writing stubs. Confirm who holds each task before adoption: version pinning and image rebuilds, pipeline integration, definition ownership, and on-call response when a shared mock server fails during a release window. DeployOpen can plan, implement, harden and support a self-hosted WireMock setup inside your own infrastructure under a written scope, and ongoing support, upgrades and testing are available as a retainer. Ask any provider for the written list of tasks, owners and response expectations so you can compare the work with what your team can absorb.

Questions buyers ask before choosing WireMock Cloud or self-hosting

Can open-source WireMock run in an air-gapped CI environment?

Yes, in principle. Open-source WireMock is a self-hosted engine, so it can run inside a network with no outbound internet access, provided its runtime, container images and build dependencies are mirrored into your internal registries and artifact stores ahead of time. Stub mappings are plain files, so they can sit in version control with the pipeline. Confirm the exact WireMock version and extensions you pin, the Java runtime or base image you use, and whether your CI runners can reach only internal repositories. Hosted mocking cannot meet this requirement, because the mocks are served from the vendor's platform. DeployOpen can plan the mirroring, version pinning and offline update procedure under a fixed-scope written agreement, and document it for your security review. Test an offline build before you commit to the design.

How much effort does a self-hosted WireMock setup take?

The effort depends on how many mock APIs you run, how many teams share one instance, whether mocks change per branch, and how the instance is hosted. One-time work includes container packaging, CI wiring, stub templates, access control on the admin endpoints, TLS, logging and documentation. Recurring work includes patching the runtime, applying WireMock upgrades, maintaining stubs as upstream APIs change, and responding to failures in a shared environment. A small team with a single pipeline usually carries a light load, while a shared instance serving many squads needs clear ownership. Ask any provider, including DeployOpen, to break the effort into setup and recurring operations in writing, with the assumptions about team count and mock volume stated so you can compare options on the same basis.

How long does a migration from WireMock Cloud take?

The timeline is set by the inventory of what you have to move. The main drivers are the number of mock APIs and endpoints, how many consuming teams and test suites depend on them, whether you use stateful scenarios or chaos rules, and how much of the CI pipeline has to change. Cloud-only features need a design decision, and each one can add redesign and test time. Export of definitions as WireMock OSS JSON is described as an Enterprise feature, so confirm with the vendor what your current plan includes before you plan the export. Build a complete inventory first, then agree the scope and deliverables in writing. No general timeline applies across teams, so treat any figure you are given as meaningful only once it is tied to that inventory.

Can our team move WireMock Cloud mocks to self-hosting without outside help?

A team can do it alone when it already runs containers and CI, has engineers comfortable writing JSON stub mappings, and has a small number of mock APIs with no Cloud-only features in use. The risks grow with the number of teams, the amount of stateful or chaos behavior to redesign, and whether auditors will ask for evidence of how the mocks are controlled. Check whether your engineers have time alongside their product work, because migrations often stall when they compete with delivery. DeployOpen can take on the work under a fixed-scope agreement, covering planning, implementation, hardening, documentation and handover, or it can support your team with a retainer for upgrades and continuous testing. Choose the model that matches your capacity, not the one that sounds simplest.

What skills do engineers need to run self-hosted WireMock?

Engineers need to write and review JSON stub mappings, understand HTTP methods, status codes, headers and request matching, and read the request journal when a test fails. They also need working knowledge of the container or runtime you deploy, CI configuration, and secrets handling so that credentials are not stored in stub files. Security skills matter as well: the admin API must not be exposed beyond the test network, and access to it should be restricted and logged. Someone must own upgrades and stub changes, and that role is easy to leave unassigned. Map these skills against your current team before choosing the operating model, and confirm the gaps with whoever will be on call for the shared mock environment.

How do we compare a WireMock Cloud quote with self-hosting costs?

Compare the same components on both sides. The vendor side includes the subscription, the seats or usage tier, the support level and the features your plan needs. The self-hosted side includes compute and storage for the instance, CI runner capacity, backup and recovery, engineer time for setup and upkeep, on-call coverage, and any outside services you buy. Separate one-time costs, such as migration and pipeline work, from recurring costs, such as subscriptions, infrastructure and maintenance. Ask a WireMock Cloud quote to state seats, expected mock call volume, the number of mock APIs, term length and which Enterprise features are included. Ask the vendor to confirm current free tier limits, since they change and affect the baseline.

Do stateful and chaos features have open-source equivalents?

Partly. Open-source WireMock includes scenario support for stateful behavior, so a stub can return different responses as the scenario moves between states. It can also simulate delays and faults on individual stubs. What you have to build yourself is the centralized management that the hosted product provides, such as a single place to define and rotate chaos rules across many mock APIs and to view results. Confirm each Cloud feature you use against the open-source documentation, list the gaps, and decide whether to keep them as code in your repository or to add a separate fault-injection tool. Treat any feature you cannot map as a scope item to agree in writing before migration starts.

How DeployOpen helps evaluate, implement or migrate mocking

DeployOpen works on WireMock Cloud vs open-source WireMock as a fixed-scope engagement that starts with your test environments and CI pipelines. We plan, build and document self-hosted WireMock inside your own infrastructure, and we can also prepare the handover needed if you move mock definitions off WireMock Cloud.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We inventory which mock APIs, stateful scenarios and chaos rules you actually depend on in WireMock Cloud.
We confirm which test environments, CI runners and data boundaries the self-hosted WireMock must reach.

How we build

We deploy standalone or containerized WireMock in your own cloud accounts, data centers or air-gapped networks.
We wire mock runs into your existing CI pipelines and check that test results are reported where your teams expect them.
We test each mock against the real contract tests your consumers run, and document any gaps against Cloud-only features.

How we hand over

You receive written documentation covering setup, configuration, mock definitions, and the CI integration.
We walk your engineers through running, updating and troubleshooting the mocks, so knowledge stays in your team.
Where a feature has no open-source equivalent, the handover records the workaround and the decision behind it.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover WireMock version upgrades and changes to mock definitions as your APIs evolve.
Ask any provider to confirm response times and coverage in writing before you sign, and we will do the same.