WireMock Cloud or Microcks: which fits your team's API testing?
A team deciding how to mock APIs usually asks whether a hosted subscription is still worth paying for. WireMock Cloud fits teams that want managed, hosted mock APIs and accept that a vendor operates the service. Microcks fits teams that want mocks and contract tests generated from their own API specifications and run inside their own infrastructure. The decision turns on four factors: who operates the service, where mock definitions may be stored, which protocols must be covered, and whether contract testing against OpenAPI or AsyncAPI specifications is central to the test strategy.
Start with operations. WireMock Cloud comes from the company behind open-source WireMock, so your team consumes a hosted service, and its plan limits and pricing are set by the vendor. Microcks is a CNCF incubating project that you install and run yourself, and it can be hosted on Kubernetes. That choice moves upgrades, backups, access control and availability onto your team. Next, check data location. If mock definitions contain internal endpoint names, sample payloads or credentials used in test environments, confirm in writing with the vendor where that data is hosted and how it is processed before your security team approves it.
Then map protocols and contract needs. Microcks accepts OpenAPI, AsyncAPI, gRPC, GraphQL, Postman collections and SoapUI projects as inputs, and uses the same artifacts to run contract tests, so a specification change can surface as a failing build. Confirm that each protocol you depend on appears in the current Microcks documentation, and check the WireMock Cloud feature list for stateful mocking and chaos rules that your scenarios require. If contract testing is central, begin by listing your specifications, their owners and their change frequency, then compare both products against that list.
Which option fits which testing scenario
This table matches common testing situations to the option that usually fits best, with the reason and the conditions you should confirm. Read each row against your own team size, protocols and data rules, because several answers depend on details only you can verify.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| A small team mocking a few REST dependencies | Mockoon or open-source WireMock | Quick HTTP mocks need little setup. Confirm whether you need stateful behavior or chaos rules, since those push the choice toward WireMock. |
| A platform team standardizing contract tests across services | Microcks | Microcks builds mocks and contract tests from OpenAPI and other specifications in one place. Confirm that your specs and the test pipeline can run on the Kubernetes cluster you plan to operate. |
| A team with asynchronous AsyncAPI channels | Microcks | Microcks supports AsyncAPI alongside REST and gRPC. Confirm the exact broker types and message patterns you need before you commit, since support varies by protocol. |
| A team needing stateful mocks or chaos rules | WireMock Cloud or WireMock you run yourself | Stateful sequences and fault injection are central WireMock capabilities. Confirm which of these features your engine version and edition provide, and whether you need the hosted service's extras. |
| A regulated team that cannot send mock definitions to a vendor cloud | Microcks or open-source WireMock on your own infrastructure | Self-hosted tools keep specifications, examples and test data inside your boundary. Confirm with your data protection and security owners that the deployment, logs and backups stay within approved locations. |
| A team that already keeps Postman collections as its test source | Microcks | Microcks can generate mocks from Postman collections, so existing assets carry over. Confirm that the collections contain the examples and response data your tests depend on. |
| A team with no Kubernetes skills or capacity | WireMock Cloud or standalone WireMock | Microcks is designed for Kubernetes hosting, which adds cluster operations to your duties. Ask who will patch, back up and upgrade the cluster before choosing it. |
Where Microcks' contract testing changes the comparison
Microcks changes the comparison because it starts from the API contract rather than from a mock definition. It generates mocks and contract tests from OpenAPI, AsyncAPI, gRPC, GraphQL, Postman collections and SoapUI projects, so the specification becomes the source of truth for both the mock and the test. If the mock and the test come from the same artifact, they cannot quietly drift apart in the way hand-written stubs often do.
For a team that already maintains OpenAPI or AsyncAPI files, this means the spec review process becomes the place where mock behavior and test expectations are agreed. Changes to an endpoint, schema or message channel flow into the mock and the conformance checks without a second set of definitions to keep in sync. The practical check is to take one existing spec, load it into Microcks, and confirm that the generated mock responses and the contract tests match what your services actually return. Ask whether your protocols (for example, gRPC or GraphQL) are supported in the version you plan to run, and confirm the exact contract-testing features in the Microcks documentation before deciding.
WireMock Cloud's workflow is different in emphasis. It centers on defining and hosting mock APIs that your tests and front-end teams call, with stubs, stateful behavior and chaos rules managed as mock definitions. The specification may inform those definitions, but the mock itself is the artifact you operate. Choosing between the two therefore depends on whether your organization wants the contract to govern the mock and the test, or wants a hosted mock service that teams configure directly. Confirm with WireMock Cloud and Microcks which of these features your own workloads depend on, since neither project's full feature set should be assumed from this overview.
Side-by-side capabilities of WireMock Cloud and Microcks
This table compares WireMock Cloud and Microcks across hosting, operation, protocol coverage, testing features, licensing and CI use. Where the supplied research does not settle a capability, the cell tells you what to confirm with the vendor or the project before you decide.
| Capability | WireMock Cloud | Microcks |
|---|---|---|
| Hosting model | Hosted commercial service from the company behind open-source WireMock | Self-hosted; runs on infrastructure you control, including Kubernetes |
| Who operates it | The WireMock vendor operates the hosted service | Your team, or a partner, operates the deployment and upgrades |
| HTTP mocking | Supported as the core use of the hosted service | Supported for APIs described by specifications; confirm exact coverage with the project |
| AsyncAPI and event mocking | Confirm with the vendor | Covered by the project's scope; confirm the supported broker bindings |
| gRPC and GraphQL | Confirm with the vendor | Covered by the project's scope; confirm the versions you need |
| SOAP via SoapUI projects | Confirm with the vendor | Imports SoapUI projects; confirm which SoapUI versions you use |
| Contract testing from specs | Confirm with the vendor | Generates mocks and contract tests from specifications; confirm the test workflow you need |
| Stateful mocking and chaos or fault injection | Documented as Cloud features; confirm the scope in your plan | Confirm with the project before relying on either |
| OpenAPI sync and SSO | Confirm sync behavior and SSO availability with the vendor | Confirm with the project and your own identity setup |
| Licensing | Commercial subscription with a free tier; check current limits with the vendor | Open source under the CNCF incubating project; confirm the license terms in the repository |
| CI integration | Runs through the hosted service; confirm the integration points for your pipeline | Can be deployed inside your own pipeline and cluster; confirm the invocation method you need |
Who controls the mock definitions and the data
A mock definition is rarely harmless: it can reveal internal endpoints, auth flows and sample payloads. The cards below cover where each option stores that material, who holds the keys, and what evidence your assessors will ask for.
Where WireMock Cloud holds definitions
WireMock Cloud is a hosted service, so mock APIs, request matching rules and recorded traffic live on infrastructure operated by the vendor. Ask the vendor where the data is stored, which regions are available, which subprocessors touch it, and how long request logs are kept. Those answers belong in your data flow diagram before any internal OpenAPI file is uploaded.
Where self-hosted mocks run
Self-hosted WireMock runs as a standalone process or container in your CI runners and test environments. Microcks runs as a service inside your Kubernetes cluster, so its database, mock artifacts and import sources sit in namespaces you already govern. In both cases the definitions stay inside your network boundary, and the team operating them decides where they live.
Identity and SSO implications
A hosted tenant brings its own user directory, role model and SSO configuration, so each mock team member becomes an account you must provision and remove. Self-hosted Microcks can be placed behind your existing identity provider, while standalone WireMock usually has no user login and relies on the security of the host and CI secrets. Confirm which SSO protocols and group mappings each option supports before you commit.
Effect on compliance evidence
Hosted services shift part of the control evidence to the vendor, which means you must request its security documentation and contractual terms rather than produce it yourself. Self-hosting moves the evidence to you: access reviews, change records, logging and backup tests all become your artifacts. DeployOpen prepares controls and evidence for assessments, but independent auditors issue any report or certification.
Data residency for sample payloads
Specs often embed real-looking customer identifiers, internal hostnames or tokens in example payloads. Before importing them into any hosted tool, strip or replace those values and decide which jurisdictions may hold what remains. Self-hosted deployments let you pin storage to a region you choose, which is the simplest way to answer residency questions from regulators or internal data owners.
Who holds keys and backups
In a hosted service, the vendor controls the encryption keys, backup schedules and restore process, and you depend on its recovery objectives. In a self-hosted deployment, your team owns the database encryption keys, backup jobs and restore tests. Kubernetes stores Secrets unencrypted in etcd unless encryption at rest is configured, so a Microcks cluster needs that setting and a tested etcd backup plan.
What running Microcks on Kubernetes asks of your team
Running Microcks usually means running it on Kubernetes, so the cluster becomes part of your operating scope before the first mock is generated. Kubernetes is open source under the Apache 2.0 license, but open source does not mean someone else maintains your cluster. Releases arrive about three times a year on a cycle of roughly 14 weeks, and the project maintains only the three most recent minor releases. Plan a recurring upgrade window, and remember that the version skew policy requires kube-apiserver to be upgraded first, one minor version at a time, before the controller manager, scheduler and kubelets. Your team needs a named owner for that calendar, and you should check which Kubernetes versions Microcks supports before you pick one.
Availability and data protection are the next decisions. A highly available control plane in the kubeadm guide uses at least three control plane nodes, either with etcd stacked on those nodes or with an external etcd cluster, and a TCP load balancer in front of kube-apiserver on port 6443. etcd should run with an odd number of members, and Kubernetes documentation recommends five members in production. Whichever topology you choose, write an etcd backup plan that uses etcdctl snapshot save, and test the restore path with etcdutl. A backup you have never restored is not yet a recovery plan. Microcks also stores its own state, so ask the project which databases and volumes need backups alongside the cluster.
Secrets need explicit attention. Kubernetes stores Secrets unencrypted in etcd by default, so anyone who can read etcd backups can read the credentials Microcks uses to reach your services. Configure encryption at rest, restrict list and watch on Secrets with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver if your policy requires one. Authentication for human administrators should also be set deliberately, since Kubernetes does not manage user accounts itself and relies on certificates, OpenID Connect tokens or a proxy. Before go-live, confirm Microcks' own deployment, upgrade and database requirements with the project, and compare your cluster settings against the CIS Kubernetes Benchmark.
What each option costs to own, by component
WireMock Cloud is a subscription service, so most of its cost is recurring and set by the plan you buy. The free tier limits (one user, 1,000 mock calls a month and three mock APIs) are published in the sibling comparison of WireMock Cloud and open-source WireMock, so use them as the baseline for what the free plan can cover. Enterprise pricing is not published here, so confirm it directly with the vendor.
- Subscription or licence: Recurring, and the largest line item once you exceed the free limits. Ask whether it is priced per user, per mock call volume or per mock API, and whether the rate changes at renewal.
- Compute and storage: Largely absorbed by the vendor, so you pay nothing extra for hosting the mocks, but confirm any data retention or egress terms in writing.
- Setup and CI integration: One-time work to connect the hosted mocks to your test pipelines, including tokens, environment variables and SSO configuration if you need it.
- Maintenance and upgrades: Handled by the vendor, which lowers internal effort, but your team still updates mock definitions as APIs change.
- Staff time: Recurring for mock authors and reviewers. Reduce it by reusing mock definitions across teams.
Before signing, ask for a written quote that lists plan tier, user count, call volume assumptions, renewal uplift and any Enterprise-only features your tests need.
Self-hosted Microcks is open source, so there is no licence fee. Your costs are the infrastructure to run it, mainly a Kubernetes cluster, plus the people who install, secure and upgrade it. Kubernetes is open source under Apache 2.0, and most of the one-time and recurring effort sits in operating that cluster, not in Microcks itself.
- Kubernetes cluster and upkeep: Recurring. A production control plane needs at least three control plane nodes, a TCP load balancer on port 6443, and an etcd backup plan. Kubernetes minor releases arrive about three times a year, so budget time for regular upgrades.
- Compute and storage: Recurring cloud or data centre costs for nodes, persistent volumes and backups. These scale with the number of mock services and environments.
- Setup and CI integration: One-time work to deploy Microcks and connect it to pipelines, including importing OpenAPI, AsyncAPI, gRPC or Postman definitions.
- Security hardening: One-time and recurring. Secrets are stored unencrypted in etcd by default, so configure encryption at rest and least-privilege RBAC.
- Staff time: Recurring for platform engineers. This is usually the largest and least visible cost, and it rises if no one owns the cluster.
Request a written scope from any partner that lists installation, hardening, backup, upgrade and support as separate line items, so you can see which costs are one-time and which recur.
Self-hosted WireMock is the open-source Apache-2.0 engine you run standalone or in containers, and it is the lighter option for comparison. It removes the Kubernetes requirement that Microcks usually brings, so the cost profile is closer to a small service in your existing CI environment. The trade-off is that you give up the hosted features of WireMock Cloud and build any collaboration layer yourself.
- Licence: None for the open-source engine.
- Compute: Small and recurring, usually running inside your CI runners or a container host you already operate.
- Setup: One-time work to write and version mock definitions and wire them into test pipelines.
- Maintenance: Recurring upgrades of the container image or binary, plus review of mock files in source control.
- Staff time: Recurring for test authors. Costs rise as the number of mock APIs and shared teams grows.
Use this tab as a floor for comparison: if your needs fit a single engine, the infrastructure you must maintain is smaller than a Kubernetes-hosted Microcks deployment.
How a move between WireMock Cloud and Microcks is staged
This sequence moves mock APIs and their contract tests from one platform to the other without a gap in test coverage. Each step ends with a check that the team can verify before moving on.
Inventory existing mock APIs and protocols
The test or platform lead lists every mock API in WireMock Cloud, noting its protocol (HTTP REST, SOAP, gRPC, GraphQL or event-based), the services and test suites that call it, and the features each mock depends on. Include any stateful scenarios, fault injection or chaos rules, and any mocks that are only used in manual exploratory testing. The step is done when the inventory names an owner and a consuming pipeline for every mock, so no dependency is left unassigned.
Sort definitions by spec coverage
For each mock, the team checks whether an OpenAPI, AsyncAPI, gRPC, GraphQL, Postman collection or SoapUI project can describe its behavior fully. Microcks generates mocks and contract tests from these artifacts, so definitions without a source spec will need to be written or reconstructed first. Mark the mocks that need a different approach, such as stateful sequences or chaos rules that a spec-based mock may not express. The output is a sorted list with three groups: ready to port, port after writing a spec, and keep on a different approach. Confirm with Microcks documentation which artifact types and export options your version supports, and confirm with WireMock Cloud which definition export formats your plan includes.
Stand up Microcks on the chosen hosting model
The platform team installs Microcks in the environment that will run the tests, either in a Kubernetes cluster the organization already operates or on a host that suits its change process. Kubernetes is open source under Apache 2.0, and the team should confirm that its cluster version is within the supported window and that the cluster meets the team's own hardening baseline before deploying. The step is complete when a sample API imported from a spec is served by Microcks and reachable from a test runner in a non-production network segment. Ask the Microcks maintainers or community which installation method they recommend for your Kubernetes version.
Port a pilot service and its tests
Choose one service with a stable interface and a small set of mocks as the pilot. The team imports the spec into Microcks, recreates the response examples and any contract tests, and points the service's test suite at the Microcks endpoint instead of WireMock Cloud. Record any behavior that differs, such as request matching, response delay or error simulation, and decide whether it is acceptable or needs a workaround. The pilot is done when the service's existing tests pass against Microcks with no changes to the test assertions, or when every difference is documented and approved by the service owner.
Wire the mocks into CI
The DevOps or platform engineer adds the Microcks instance to the pipeline configuration so that builds call the mocks instead of the Cloud service. Credentials for any remote mock endpoints are stored in the team's secrets manager, not in pipeline files. Contract tests should run on every change to a spec, and the team should confirm that failing contract tests block the merge. The step is complete when at least one full pipeline run has passed using Microcks mocks and the results appear in the team's existing test reporting. Confirm how your CI system reads test reports from Microcks before you rely on them as a gate.
Port remaining mocks in batches
The team moves the rest of the inventory in groups, starting with the mocks that are ready to port and then the ones that need a spec written. Each batch is tested in CI before the next one starts, and the inventory is updated with the new location of every mock. Features that Microcks does not cover directly, such as stateful behavior or chaos injection, are either kept on a separate tool or redesigned as tests with explicit setup and teardown. The batch is done when every mock in it is marked as migrated, tested and owned.
Retire WireMock Cloud mocks after tests pass
Once all pipelines have run against the new platform for a period the team agrees on in advance, the team disables the old mocks and removes the WireMock Cloud references from pipeline configuration. Before deletion, the team exports a copy of every definition and keeps it in version control, so the mocks can be recreated if a later audit or incident needs them. The step is complete when the inventory shows no active dependency on WireMock Cloud, the exported definitions are archived with a named owner, and the contract tests are documented as the source of truth for each API.
Questions teams ask before choosing or moving
What does it cost to move mocks from WireMock Cloud to Microcks?
The cost is mostly effort and infrastructure, not a license fee, because Microcks is open source. The main drivers are how many mock APIs you have, how many of them already have an OpenAPI, AsyncAPI, gRPC or GraphQL contract, and how much stateful or chaos behavior your current mocks rely on. One-time costs include exporting or rewriting definitions, building the deployment and CI pipeline, and training the team. Recurring costs include the Kubernetes cluster, storage, upgrades and the engineer time that keeps them running. When you request a quote, ask for the scope of mock APIs, the contract sources in use, the environments to be covered and which recurring operations support is included.
How long does a Microcks migration take?
The timeline depends on the number of contracts, the state of your specifications and the size of your Kubernetes footprint. Specification quality is often the longest step, since Microcks generates mocks and contract tests from the contracts you supply, so incomplete or inconsistent OpenAPI or AsyncAPI files slow the work. Cluster readiness is the second driver, including whether you already run a cluster that meets your standards. Teams usually move in stages, starting with one service and its CI job before expanding. Confirm the phases, dependencies and acceptance checks with your vendor or implementation partner before agreeing a schedule.
Can our own team migrate from WireMock Cloud without outside help?
Yes, a team with Kubernetes and CI experience can migrate on its own, especially for a small set of well-documented APIs. The work is manageable when the team already owns its test pipelines and can read API contracts. Outside help becomes more useful when you have many services, multiple protocols, no cluster to host Microcks, or strict compliance evidence requirements. A fixed-scope engagement from DeployOpen can plan, implement, harden and document the setup, and then hand it over. Your own team still needs to own the day-to-day operation after handover.
What does the migration need from our team?
Three areas need named owners before the work starts:
- Cluster access: a Kubernetes cluster that meets your standards, with rights to deploy workloads, manage namespaces and configure ingress. The Kubernetes project maintains the three most recent minor releases, so confirm which version your cluster runs and plan upgrades.
- Spec quality: versioned, validated OpenAPI, AsyncAPI, gRPC or GraphQL contracts, and Postman or SoapUI assets where they are used.
- CI ownership: a named team that maintains the pipeline jobs, test reports and rollback steps.
Ask the vendor which of these they will do and which remain with you.
Can Microcks replace WireMock Cloud for every test?
No, not for every test, and you should confirm the fit for each case. Microcks is strongest where contracts already exist and you need generated mocks and contract tests across several protocols. WireMock Cloud offers hosted mock APIs, stateful mocking, chaos testing and SSO, and those features need a separate check against Microcks before you decide. Map each test type to a tool, list the features it depends on, and run a pilot on your hardest cases. Where a feature has no equivalent, plan a workaround or keep that test on the existing tool for a period.
How do we keep mock definitions off a vendor cloud?
Run the mock engine in infrastructure you control, such as your own Kubernetes cluster or CI runners, and store contracts and mock assets in your own Git repositories or registries. This keeps definitions, sample data and any embedded credentials inside your network boundary. Confirm the data flows with your vendor: check whether any telemetry, licensing checks or update channels reach external services, and whether the mock server needs outbound access at all. Document these decisions, since security and compliance reviewers will ask for them.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement covers the scope, deliverables and timeline that are agreed in writing before work starts. For a Microcks move, the written scope typically lists the services and contracts in scope, the cluster design, deployment and CI integration, hardening, backup of the configuration, documentation and handover. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, which independent auditors provide. Ongoing support, upgrades and continuous testing are available as retainers. A quote follows from the written scope, so ask for each deliverable and its acceptance criteria.
How DeployOpen helps you choose and run API mocking
DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure, so the choice between WireMock Cloud and a self-hosted option like Microcks can be tested against your real contracts and pipelines. We start from written requirements, build in your environment, and document the result for your team to run.
How we scope
- We list which APIs, protocols and contract formats your teams need mocked, including OpenAPI, AsyncAPI, gRPC or GraphQL.
- We confirm where mocks must run, such as your Kubernetes clusters, CI runners or air-gapped test networks.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We deploy the chosen mocking platform in your environment and connect it to your existing API specifications and repositories.
- We wire contract tests into your CI pipeline so mismatches between specifications and mocks fail builds early.
- We test access controls, secret handling and network exposure before any team relies on the environment.
How we hand over
- We deliver runbooks covering installation, configuration, upgrades, backups and common troubleshooting steps for your operators.
- We document which WireMock Cloud features, such as stateful mocking or chaos rules, have no direct equivalent and how your team will cover them.
- We walk your engineers through the setup and confirm they can run, update and recover the platform without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped to your environment and release cadence.
- We can plan upgrades around the Kubernetes release schedule if you host Microcks on a cluster you operate.
- Before any upgrade or change, we review the scope with you and confirm the impact on existing mock definitions and tests.
