Microcks: API Mocking and Contract Testing from One Contract

Microcks is an open-source platform for API mocking and contract testing. You give it the contract you already have (an OpenAPI or AsyncAPI document, a gRPC Protobuf file, a GraphQL schema, a Postman collection, a SoapUI project or a SOAP/WSDL definition), and it starts serving a live mock for every operation, with realistic responses taken from the examples in that contract. When the real implementation exists, the same contract and the same examples become a conformance test that you run against it from a button, a CLI or a pipeline.

For a DevOps engineer the value is practical. Teams stop waiting for dependencies that are not built yet, test environments stop depending on third-party sandboxes that are slow or unreliable, and a breaking change in an API is caught by a pipeline step before it reaches an integration environment.

CNCF daily · Sprint 5, post 7 of 14 · Application Definition & Image Build

At a glance

Category	App Definition and Development, subcategory Application Definition & Image Build (CNCF Landscape)
CNCF status	Incubating. Accepted to the CNCF on 22 June 2023 and moved to Incubating on 3 May 2026 (CNCF project page)
Written in	Java for the main application; the Async Minion and some other pieces use Quarkus
License	Apache-2.0
Current release	1.15.0 (the GitHub releases page dates it 5 August; a Helm update pull request from 25 September 2026 shows it was the current chart then). Earlier: 1.14.0 on 29 April 2026, 1.13.0 on 25 October 2025
Contracts understood	OpenAPI, AsyncAPI, gRPC/Protobuf, GraphQL schema (with a Postman collection for examples), Postman collections, SoapUI projects, SOAP/WSDL
Event protocols (AsyncAPI)	Kafka (default), WebSocket, MQTT, AMQP 0.9 (RabbitMQ), NATS, Google Pub/Sub, Amazon SQS, Amazon SNS
Test runners	HTTP, SOAP, SOAP_UI, POSTMAN, OPEN_API_SCHEMA, ASYNC_API_SCHEMA, GRPC_PROTOBUF, GRAPHQL_SCHEMA
Install routes	Docker Compose, Helm chart, Kubernetes Operator, a single-container “Uber” distribution, Testcontainers modules
Identity	Keycloak (OpenID Connect), with roles user, manager and admin

The problem Microcks solves

Three things go wrong in a system made of many services.

Dependencies that are not ready. A front end or a consumer service needs an API that does not exist yet, or exists only in an environment shared with ten other teams. Developers hand-write stubs, and the stubs drift away from the real contract.

Third-party systems you cannot test against. Partner and carrier APIs, payment gateways and government services often have rate limits, costs, slow sandboxes or no sandbox at all. Tests become flaky, and some failure cases (a timeout, a 500, an odd payload) cannot be provoked on demand.

Contracts that rot. A specification is written once and then the code changes. Nothing checks that the running service still honours the document that consumers rely on.

Microcks’ answer is to treat the contract as the single source of truth and derive both the simulation and the test from it. The mock and the test share the same examples, so they cannot disagree with each other.

Key concepts

Term	Meaning
API or Service	A named, versioned API that Microcks has imported. Mock URLs and tests are addressed by name and version, for example API Pastry - 2.0:2.0.0.
Artifact	A file you import: an OpenAPI, AsyncAPI, Protobuf, GraphQL, SoapUI or Postman document. A primary artifact defines the API; a secondary artifact adds examples or metadata.
Operation	One method and path (for example GET /pastry/{name}), one gRPC method, one GraphQL query or one AsyncAPI channel and action.
Example	A named request and response pair (or a named message) taken from the artifact. Examples are what the mock serves and what the tests send.
Dispatcher and dispatching rules	The logic that picks which example to return for an incoming request. Microcks infers a default from the variable parts of your examples and lets you override it.
Templating	{{ ... }} expressions in response bodies and headers that insert request values, random values, dates or stored state.
Test and Test Runner	A test launches against a test endpoint (the system under test) with a runner, a strategy such as OPEN_API_SCHEMA or POSTMAN. Results and the exchanged requests and responses are kept in history.
API Metadata	A small APIMetadata file that attaches labels, delays and dispatcher settings to an API without editing the contract.
Async Minion	The component that publishes mock messages to brokers and connects to brokers to test messages.
Regular and Uber distributions	Regular is the full, persistent, production-oriented deployment. Uber is a stripped-down single container for laptops, unit tests and shift-left scenarios.
Service account	A Keycloak client that CLIs and pipelines use to import artifacts and launch tests.

Architecture

The webapp holds the repository, serves mocks and launches tests; the Postman runtime and the Async Minion are helpers; MongoDB and Keycloak are its dependencies. Blue is a contract or caller, dark grey is identity, purple is a Microcks component and green is a store, target or broker. Open the zoomable diagram, or download it as SVG or PNG.

Component	Responsibility
Webapp (microcks)	The main application. It serves the web console and the REST API, imports artifacts, runs the mocking engine for HTTP-based protocols, launches tests and records their results.
MongoDB	The database for the repository of APIs and Services and for test history.
Keycloak	Authenticates users with OpenID Connect and supplies roles, groups and service accounts. It can broker an external identity provider.
Postman runtime (microcks-postman-runtime)	Executes Postman collection tests and calls back the webapp to store results.
Async Minion (microcks-async-minion)	Publishes mock messages for AsyncAPI definitions and tests asynchronous endpoints. It loads definitions from the webapp at start-up and listens to a Kafka topic for changes.
Kafka broker	Carries a private topic for change events (and the triggers for contextualized messages) and the public topics where mock messages are published.
Uber distribution	A single container (microcks-uber) plus an optional microcks-uber-async-minion, designed for inner-loop use. The Uber async minion handles WebSocket directly, so no Kafka broker is needed unless you bring your own.

Design principle. Keep one description of the API and let tools derive everything else from it. The mock server, the examples for consumers, the conformance test and the event simulation all come from the same artifact, so there is one thing to review and one thing to keep correct.

Mock a dependency, then test the real one

Steps 1 to 3 give a consumer a mock; steps 4 to 6 test the real service against the same contract. Open the zoomable diagram, or download it as SVG or PNG.

1. You import an OpenAPI contract that carries named examples, through the UI, the API, the CLI or a scheduled importer.
2. Microcks creates an API entry, infers a dispatcher for each operation and starts serving mocks under /rest/<API name>/<version>/....
3. A consumer application calls the mock endpoint instead of the real dependency.
4. After the real service is deployed, a pipeline launches a test against its URL with a runner such as OPEN_API_SCHEMA.
5. The runner sends the contract’s example requests to the real service.
6. It checks the status codes and validates each response against the schema, then stores the result and the exchanged requests and responses in the test history.

Architecture and deployment options · Conformance testing

Install Microcks

The commands below follow the project’s installation guides. I did not run them here, so check the chart and image versions against the release you choose.

Docker Compose (laptop or a throw-away VM)

git clone https://github.com/microcks/microcks.git --depth 10
cd microcks/install/docker-compose
docker compose up -d

Open http://localhost:8080. The default compose setup sends you through Keycloak and documents a built-in admin user whose password is in the guide; change or remove that account before any shared use. A development mode without Keycloak is available with docker compose -f docker-compose-devmode.yml up -d; it also runs asynchronous features in a light way with a Redpanda broker instead of a full Kafka.

Kubernetes with Helm

kubectl create namespace microcks
helm repo add microcks https://microcks.io/helm
helm install microcks microcks/microcks --namespace microcks \
  --set microcks.url=microcks.example.internal \
  --set keycloak.url=keycloak.example.internal \
  --set keycloak.privateUrl=http://microcks-keycloak.microcks.svc.cluster.local:8080

Add --set features.async.enabled=true --set features.async.kafka.url=<kafka-host> to turn on asynchronous features; in the guides this also deploys a Kafka cluster managed by the Strimzi operator, which you install first. The chart can reuse existing infrastructure: set mongodb.install=false with mongodb.url, mongodb.database and credentials, and keycloak.install=false with keycloak.url and keycloak.realm.

The documentation states that the fully managed install, where the chart deploys single-instance Keycloak and MongoDB, is convenient for discovery and not recommended for a production environment.

Kubernetes Operator

The Operator (distributed through OperatorHub.io) installs Microcks from a Microcks custom resource, with companion resources such as APISource for importing artifacts. The older Ansible-based operator repository is archived; use the current operator and read its guide.

Embedded in tests

Testcontainers modules exist for Java, JavaScript, Go and .NET, and a community module for Python. They start a throw-away Microcks (an “ensemble” when the Postman runtime and the Async Minion are included) inside a unit or integration test.

Using Microcks

The examples are adapted from the official sample API (“API Pastry”) and the documentation. They use a neutral API on purpose. Snippets are untested here.

Import a contract and call the mock

Import an OpenAPI file from the UI (Importers, or drag and drop), or with the CLI:

microcks-cli import 'specs/pastry-openapi.yml:true,specs/pastry-postman.json:false' \
  --microcksURL=https://microcks.example.internal/api/ \
  --keycloakClientId="$KEYCLOAK_CLIENT_ID" \
  --keycloakClientSecret="$KEYCLOAK_CLIENT_SECRET"

The :true or :false after each file says whether it is a primary artifact. Then call the mock; spaces in the API name become +:

curl 'https://microcks.example.internal/rest/API+Pastry+-+2.0/2.0.0/pastry/Eclair+Cafe' \
  -H 'Accept: application/json'

Write examples that Microcks can use

Microcks reads named examples from the contract. In OpenAPI, the same example name on a parameter and on a response links them:

paths:
  /pastry/{name}:
    get:
      parameters:
        - name: name
          in: path
          required: true
          schema: { type: string }
          examples:
            Eclair Cafe: { value: Eclair Cafe }
            Millefeuille: { value: Millefeuille }
      responses:
        '200':
          description: The pastry
          content:
            application/json:
              schema: { $ref: '#/components/schemas/Pastry' }
              examples:
                Eclair Cafe:
                  value: { name: Eclair Cafe, size: M, price: 2.5, status: available }
                Millefeuille:
                  value: { name: Millefeuille, size: L, price: 4.0, status: available }

With one path parameter, Microcks infers a URI_PARTS dispatcher with rule name, so /pastry/Eclair+Cafe returns the first response and /pastry/Millefeuille the second.

Return a default when nothing matches

A FALLBACK dispatcher works like try and catch: try a first dispatcher, and if it finds nothing, return a named response. Set it in the UI under Edit Properties, in the contract with the x-microcks-operation extension, or in an APIMetadata file:

x-microcks-operation:
  delay: 100
  dispatcher: FALLBACK
  dispatcherRules: |
    {
      "dispatcher": "URI_PARTS",
      "dispatcherRules": "name",
      "fallback": "Millefeuille"
    }

Settings written in the contract overwrite UI customizations at the next import.

Pick a response from the request body

JSON_BODY evaluates a JSON Pointer on the request body with an operator (equals, range, regexp, size or presence) and a map of cases to response names. The documentation example accepts beers from one country and rejects the rest, so one POST operation can return both a success and an error example.

Write your own dispatcher

For full control, use a script. Since 1.13 a JavaScript engine runs the script in a sandbox, alongside the earlier Groovy engine:

const accept = mockRequest.getRequestHeader("Accept").toString();
const name = mockRequest.getURIParameter("name");
log.info(`Dispatching for name=${name}, accept=${accept}`);

if (name === "Eclair Cafe" && accept === "text/xml") {
  return "Eclair Cafe Xml";
}
return "Millefeuille";

The script must return the name of a response. log.info output appears in Live Traces. Scripts also have a store (a service-scoped key-value store whose entries expire after 10 seconds by default, unless you pass a TTL) and a requestContext (request-scoped values for templates), which together allow stateful mocks such as a cart that remembers items.

Make responses dynamic

Responses and header values can contain {{ }} expressions:

{
  "id": "{{ uuid() > put(orderId) }}",
  "createdAt": "{{ now(yyyy-MM-dd'T'HH:mm:ss) }}",
  "name": "{{ request.body/name || randomFirstName() }}",
  "orderRef": "{{ orderId }}"
}

request.body/... is a JSON Pointer into the request, > passes a value to the next function (here put, which stores it in the context), and || provides a fallback when the left side is null. Header values can be templated too, which is how the project mocks an OpenID Connect redirect.

Run a conformance test

From a pipeline, with a service account:

microcks-cli test 'API Pastry - 2.0:2.0.0' https://pastry.staging.example.internal OPEN_API_SCHEMA \
  --microcksURL=https://microcks.example.internal/api/ \
  --keycloakClientId="$KEYCLOAK_CLIENT_ID" \
  --keycloakClientSecret="$KEYCLOAK_CLIENT_SECRET" \
  --waitFor=10sec

The three positional arguments are the API name and version, the endpoint under test and the runner. The command fails when the endpoint does not honour the contract, which fails the pipeline step. Per-operation request headers can be passed with --operationsHeaders. Official wrappers exist for GitHub Actions (microcks/import-github-action and microcks/test-github-action), GitLab CI components, Tekton tasks and a Jenkins plugin.

Mock and test events

Import an AsyncAPI document and Microcks publishes example messages to the configured broker at a set frequency. Add a binding block for protocols other than Kafka. A contextualized message reuses values from a synchronous call:

examples:
  - contextualized:
      payload:
        id: '{{ response.body/id }}'
        fullName: '{{ request.body/fullName }}'
        sentAt: '{{ now() }}'

With Sync-to-Async triggers (1.14), invoking a mocked POST /register publishes this message on the AsyncAPI channels. To test a real producer, run the ASYNC_API_SCHEMA runner against a broker endpoint such as kafka://<bootstrap>:9092/<topic>; Microcks consumes messages for the wait period and validates them against the payload schema.

Features

Area	What you get
Multi-protocol mocks	REST, SOAP, GraphQL, gRPC and event-driven APIs from one tool and one repository.
Dispatching	Inferred dispatchers (URI_PARTS, URI_PARAMS, URI_ELEMENTS, QUERY_ARGS, QUERY_MATCH), plus QUERY_HEADER, JSON_BODY, FALLBACK, PROXY, PROXY_FALLBACK and SCRIPT (Groovy or JavaScript).
Templating	{{ }} expressions for request values, random data, dates, stored context and response headers.
Stateful mocks	Script store and requestContext to remember data across calls.
Constraints and delay	Per-operation delay and, since 1.11, parameter constraints such as required headers matched by a regular expression. Random-latency strategies arrived in 1.13.
Callbacks and webhooks	OpenAPI callbacks with ordering (x-microcks-callback.order) and a Manage Webhooks UI and API (1.14).
Sync-to-Async triggers	A synchronous mock call publishes a contextualized event (1.14).
AsyncAPI request-reply	Correlated request and response messages (1.14).
Live Traces	Real-time view of how a request was matched, built on OpenTelemetry traces and spans, which can also go to your own OpenTelemetry stack (1.13).
Contract testing	Eight runners, test history with the recorded requests and responses, and a test API.
Automation	CLI, GitHub Actions, GitLab components, Tekton tasks, Jenkins plugin, Testcontainers modules, Backstage plugin, Docker Desktop extension.
Repository management	Labels, multi-tenancy by label with Keycloak groups, scheduled imports from Git or HTTP, snapshot and restore.
AI Copilot (optional)	An application setting for AI-generated examples; 1.14.0 added OpenAI example generation. It is off unless configured.
MCP endpoints	The 1.13 notes mention support for the 2025-06-18 MCP protocol version on MCP endpoints; I did not read that page, so check it before relying on it.

Configuration reference

The configuration pages list far more keys than are shown here. These are the ones you meet first.

Where	Key	Purpose
Webapp application.properties	tests-callback.url	URL the Postman runtime calls back with test results
	postman-runner.url	Where the Postman runtime is reachable
	async-minion.url	Where the Async Minion is reachable
	async-api.enabled, async-api.default-binding, async-api.default-frequency	Turn on AsyncAPI support, pick the default binding (Kafka) and the default publishing delay in seconds
	kafka.bootstrap-servers	Broker used for change events and triggers
Webapp features.properties	features.feature.async-api.endpoint-<BINDING>	Broker endpoint shown to users for a binding
	features.feature.repository-tenancy.enabled	Label-based multi-tenancy
	features.feature.repository-tenancy.artifact-import-allowed-roles	Roles allowed to import artifacts
Async Minion	minion.supported-bindings	Protocols the minion serves, for example KAFKA,WS
	minion.restricted-frequencies	Allowed delays between publications, in seconds
	kafka.bootstrap.servers, mqtt.server, amqp.server, nats.server, googlepubsub.project, amazonsqs.region, amazonsns.region	Connections to brokers and cloud messaging
	amazonsqs.credentials-type	env-variable or profile; endpoint-override can point to LocalStack
Helm chart	microcks.url, keycloak.url, keycloak.privateUrl	Hostnames and the in-cluster Keycloak URL
	mongodb.install, mongodb.url, mongodb.database	Reuse an existing MongoDB
	keycloak.install, keycloak.realm	Reuse an existing Keycloak
	features.async.enabled, features.async.kafka.url	Asynchronous features

The Async Minion, when run with Docker Compose, uses a profile named docker-compose, so its properties are prefixed with %docker-compose..

Production reference design

A defensible shape for a shared Microcks, from the documentation’s own advice:

• Bring your own MongoDB and Keycloak. Use the chart’s install=false switches and point it to managed, backed-up instances. The fully managed install runs single, untuned instances.
• Scale the stateless parts. The Operator’s full example shows replicas for the webapp and the Postman runtime. Keep the Async Minion separate so that event traffic and HTTP traffic scale on their own.
• Expose it deliberately. Ingress for the console and mocks, with TLS; gRPC mocks are exposed with TLS passthrough and need an ingress controller that supports it.
• Wire it to CI. One service account per pipeline family, credentials in the CI secret store, an import step on every contract change and a test step after every deploy.
• Plan the async side. A Kafka broker for the minion, or the Uber minion with WebSocket only. For AWS messaging, version 1.13 added IRSA and EKS Pod Identity support for SQS and SNS connections.
• Sizing. I found no official sizing guidance for the regular distribution, so measure with your own contract count and traffic.

Security

Area	What the documentation says
Authentication	Delegated to Keycloak with the OpenID Connect Authorization Code flow. Keycloak can broker corporate identity providers.
Roles	user (default after first sign-in), manager (adds and removes APIs and edits mock operation properties) and admin (manages users, configures external repository secrets, backs up and restores).
Default realm	The default realm ships built-in users (user, manager, admin) with a well-known password. Replace them with your identity provider before sharing the instance.
Service accounts	CLIs, actions and plugins authenticate with Keycloak service-account credentials. The Backstage guide suggests a dedicated, read-only client for catalog sync.
Multi-tenancy	Label-based segmentation creates Keycloak groups so that managers see only the resources for their label.
Secrets	Secrets for Git repositories and for test endpoints (for example a QA broker) are managed in the Administration section, available to admins.
Scripts	Groovy dispatchers run on the JVM and the documentation shows them loading external libraries and calling external URLs, so treat the right to edit scripts as privileged. The JavaScript engine runs in a sandbox, according to the 1.13 release notes.
Mock endpoints	I did not confirm whether mock endpoints require authentication by default; verify this on your version and keep mocks off the public internet.

Monitoring and day-2 operations

Task	How
Debug a mock	Live Traces on the operation page show which dispatcher matched and why; script log.info lines appear in the trace
Trace usage	Live Traces page by user; export traces to your OpenTelemetry stack
Upgrade	Helm chart or Operator version bump; read each release’s notes, since several releases changed installation and defaults
Back up	Back up MongoDB; the admin console also offers snapshot and restore of the repository
Keep contracts fresh	Scheduled importers or an import step in CI, so the repository follows Git
Review conformance	Test history per API and version; the application settings include conformance metrics computing
Extend	Mount extra libraries into /deployments/lib (webapp) or /deployments/lib-ext (minion), or build a custom image

Symptom	First checks
Test fails on a real service	Open the test details; compare the recorded request and response with the schema; check headers the service requires (--operationsHeaders)
Wrong example returned	Look at the operation’s dispatcher and rules in Live Traces; consider an explicit FALLBACK or JSON_BODY rule
No async messages	Confirm async-api.enabled, the minion’s supported-bindings, broker connection and credentials, and that the binding block exists in the AsyncAPI document
Login loop or token errors	Check keycloak.url against keycloak.privateUrl and that the user has the user role in the Microcks client
Settings lost after import	Overrides made in the UI persist, but values written in the contract overwrite them at the next import

Usage cases

• Parallel development. A front end or consumer builds against mocks while the provider is still being written.
• Contract conformance in CI. A pipeline step proves that each deployed build still honours its published contract.
• Third-party sandboxes. Replace slow, rate-limited or missing partner APIs with controlled simulations, including error cases.
• Event-driven systems. Publish realistic messages on Kafka, MQTT, AMQP or SQS to test consumers, and validate the messages a producer emits.
• Service virtualisation for test environments. Stand up complete, repeatable environments from contracts instead of copies of real systems.
• Developer inner loop. Testcontainers or the Uber image run Microcks inside unit and integration tests.
• Cold-chain sprint project. The Sprint 5 final project uses Microcks to mock and contract-test the partner and carrier APIs that the platform depends on.

Operational considerations

• A mock is only as good as its examples. Microcks serves what the contract contains. Thin examples give thin mocks.
• Conformance is schema-level. OPEN_API_SCHEMA checks status codes and payload shape for the example requests. It is not a replacement for business-logic tests, and the project’s own author describes it as provider-driven, protocol-level contract testing, different from consumer-driven tools such as Pact.
• Not a production gateway. It is a development and testing tool. Do not put it in front of real traffic.
• A real stack to run. The regular distribution needs MongoDB and Keycloak, and Kafka plus the minion for events. Use the Uber image where that is too much.
• Documentation age. Several guides carry page ages of hundreds of days, and examples use older versions (the Helm page mentions Kubernetes 1.17 or later and chart 1.9.1). Check the chart and operator versions against the current release.
• Operator history. The Ansible-based operator repository is archived, and a newer microcks.io/v1alpha1 operator appears in the guides.
• GraphQL needs a companion file. A GraphQL schema has no examples, so mock data comes from a Postman collection.

Adoption

The project keeps an ADOPTERS.md that lists organizations by public information and self-registration. It names, among others, CNAM (mocking SOAP services of the French healthcare system), Nordic Semiconductor, the Belgian national employment office ONEm (OpenAPI contract testing and mocking), Traefik, Fluent CI and GetYourGuide; J.B. Hunt has a published case study on the project blog. The AsyncAPI Generator project also uses Microcks in its acceptance tests. The CNCF incubation announcement reports 2.5 million container image downloads in 2025, three times the 2024 total.

Alternatives

Solution	Model	Best suited to
WireMock	Stubs defined in code or JSON, with fine control over matching and fault simulation	HTTP stubbing inside JVM tests or as a standalone server, when you want explicit stubs rather than contract-derived ones
Prism (Stoplight)	OpenAPI mock server and validation proxy	A spec-first team that needs only OpenAPI mocks and request validation
Mockoon	Desktop and CLI mock servers	Individual developers and quick local mocks
Pact	Consumer-driven contract testing with scoped assertions	Teams that want each consumer to state what it needs and the provider to verify it
MockServer	Programmable HTTP mocking and proxying	Test suites that need programmable expectations
Postman mock servers	Cloud-hosted mocks of collections	Teams already centred on Postman; the DEV.co profile notes they lack contract testing and multi-protocol support

Strengths and limitations

Strengths	Limitations
One contract drives mocks, tests and event simulation	Needs MongoDB and Keycloak, and Kafka plus a minion for events
Covers REST, SOAP, GraphQL, gRPC and eight messaging bindings	Mock quality depends on the examples in the contracts
Kubernetes-native install plus a light Uber image for laptops	Conformance testing is schema-level, not full behaviour verification
Strong CI story: CLI, GitHub, GitLab, Tekton, Jenkins, Testcontainers	Documentation is uneven, with older pages and examples
Live Traces on OpenTelemetry make dispatch problems easy to see	Groovy scripting needs careful access control
CNCF Incubating, Apache-2.0, active release cadence	Production sizing guidance is thin

Project status and roadmap

Microcks moved from Sandbox to Incubating on 3 May 2026. Releases arrive a few times a year: 1.13.0 in October 2025 (Live Traces, the JavaScript engine, a dark theme, quick imports), 1.14.0 in April 2026 (OpenAPI callbacks and webhooks, Sync-to-Async triggers, AsyncAPI request-reply) and 1.15.0 in August 2026. Items I saw in the 1.15.0 changelog excerpt include TLS support for the Microcks HTTP endpoint, Workload Identity for Google Pub/Sub, nested and multiple GraphQL fragment spread selection and a configurable default TTL for the service state store. I did not check for later patch releases. In the incubation announcement the maintainers say they will work on deeper AsyncAPI toolchain integration, AI and MCP simulation support, and making contract testing a first-class part of CI/CD.

Recommendation

Adopt Microcks when several teams or services depend on each other’s APIs, or when you need controllable simulations of third-party and event-driven dependencies, and you are willing to run MongoDB and Keycloak next to it. Start with the Docker Compose or Uber image on a laptop and a single OpenAPI contract, then add an OPEN_API_SCHEMA test step to one pipeline. Assess it first against WireMock or Prism if all you need is a handful of HTTP stubs in JVM tests, and look at Pact when consumer-driven contracts are your goal. Before a shared install, replace the default users, bring your own MongoDB and Keycloak, and decide who may edit scripts.

References: Microcks documentation · CNCF project page · CNCF incubation announcement · Architecture and deployment options · Dispatchers and rules · Mock templates · Test parameters and runners · Using the CLI · Docker Compose install · Helm chart parameters · Application configuration · Security configuration · AsyncAPI conventions · Async triggers · 1.13.0 release · 1.14.0 release · GitHub releases