wiremock-standalone-docker
giuseppe-trisciuoglio/developer-kit
Run WireMock as a standalone Docker container to mock APIs for integration testing.
What is wiremock-standalone-docker?
Provides patterns and configurations for running WireMock 3.5.2 as a standalone Docker service. Use this skill to mock external APIs, simulate error conditions, and validate integration scenarios without depending on real third-party services.
- Generate mock HTTP endpoints with configurable status codes and response bodies
- Create stub mappings for success, error, timeout, and rate-limit scenarios
- Simulate error conditions (4xx, 5xx, timeouts) for testing retry logic and error handling
- Validate API contracts and test HTTP client configurations
- Reset and inspect unmatched requests via WireMock admin API
How to install wiremock-standalone-docker
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill wiremock-standalone-docker- Docker and Docker Compose installed
- Port 8080 available (or configured to a different port)
- Basic understanding of JSON stub mapping syntax
How to use wiremock-standalone-docker
- 1.Create a docker-compose.yml with WireMock 3.5.2 image and volume mounts for mappings and files
- 2.Create wiremock/mappings/ and wiremock/__files/ directories for stub definitions and response bodies
- 3.Define JSON stub files in wiremock/mappings/ for each API scenario (success, errors, timeouts, rate limits)
- 4.Start WireMock with docker compose up -d
- 5.Verify WireMock is running by calling curl http://localhost:8080/__admin/mappings
- 6.Point your application to http://localhost:8080 (or http://wiremock:8080 in Docker network)
- 7.Test all edge cases: 200, 400, 401, 403, 404, 429, 500, timeouts, and malformed responses
Use cases
- Mock external APIs during integration or end-to-end testing without real service dependencies
- Test error handling and retry logic by simulating 401, 403, 404, 429, 500 responses
- Simulate slow or timeout scenarios to validate client-side timeout handling
- Create reproducible test environments by version-controlling stub mappings
- Validate API contracts before implementing real backend services
- Backend developers testing HTTP clients and integration logic
- QA engineers building integration test suites
- DevOps engineers setting up portable test environments
- Teams needing reproducible mock API servers across environments
wiremock-standalone-docker FAQ
Run curl http://localhost:8080/__admin/mappings to see all loaded stub definitions. If stubs aren't loading, verify JSON files are in wiremock/mappings/ with correct permissions.
Add fixedDelayMilliseconds to the response object in your stub mapping. For example, fixedDelayMilliseconds: 5000 delays the response by 5 seconds.
Run curl http://localhost:8080/__admin/requests to see all requests WireMock received, including those that didn't match any stub. This shows the exact URL, method, and headers sent.
Yes, if your mappings are stored in wiremock/mappings/ and mounted as a volume. WireMock loads them on startup. Without volume mounts, mappings are lost on container restart.
Yes. Add WireMock as a service in docker-compose.yml, set depends_on to ensure it starts first, and configure your app service with API_BASE_URL=http://wiremock:8080 to use the internal Docker network.
Full instructions (SKILL.md)
Source of truth, from giuseppe-trisciuoglio/developer-kit.
name: wiremock-standalone-docker description: Provides patterns and configurations for running WireMock as a standalone Docker container. Generates mock HTTP endpoints, creates stub mappings for testing, validates integration scenarios, and simulates error conditions. Use when you need to mock APIs, create a mock server, stub external services, simulate third-party APIs, or fake API responses for integration testing. allowed-tools: Read, Write, Edit, Bash, Glob, Grep
WireMock Standalone Docker Skill
Overview
Provides patterns for running WireMock as a standalone Docker container to mock external APIs during integration and end-to-end testing. Runs WireMock as a separate service that simulates real API behavior for testing HTTP clients, retry logic, and error handling.
When to Use
Use when you need to:
- Mock external APIs during integration or end-to-end testing
- Simulate error conditions (timeouts, 5xx, rate limiting) without real services
- Test HTTP client configurations, retry logic, and error handling
- Create portable, reproducible test environments
- Validate API contracts before implementing the real service
Instructions
Step 1: Set Up Docker Compose
Create a docker-compose.yml with WireMock 3.5.2, port mapping, and volume mounts for mappings and files:
version: "3.8"
services:
wiremock:
image: wiremock/wiremock:3.5.2
ports:
- "8080:8080"
volumes:
- ./wiremock:/home/wiremock
command: ["--global-response-templating"]
Step 2: Create Directory Structure
Create the WireMock configuration directories:
wiremock/
├── mappings/ # JSON stub definitions
└── __files/ # Response body files
Step 3: Define API Mappings
Create JSON stub files in wiremock/mappings/ for each scenario:
- Success: Return 200 with JSON body
- Not Found: Return 404
- Server Error: Return 500
- Timeout: Use
fixedDelayMilliseconds - Rate Limit: Return 429 with Retry-After header
Step 4: Start WireMock
docker compose up -d
Step 5: Verify WireMock is Running
curl http://localhost:8080/__admin/mappings
Expected: Returns empty array {"mappings":[]} if no stubs loaded, or your stub definitions. If you get connection refused, check that the container is running: docker compose ps
Step 6: Configure HTTP Client
Point your application to http://localhost:8080 (or http://wiremock:8080 in Docker network) instead of the real API.
Step 7: Test Edge Cases
Always test: 200, 400, 401, 403, 404, 429, 500, timeouts, malformed responses.
Examples
Example 1: Mock Successful GET Request
{
"request": { "method": "GET", "url": "/api/users/123" },
"response": {
"status": 200,
"jsonBody": { "id": 123, "name": "Mario Rossi" }
}
}
Example 2: Mock Server Error
{
"request": { "method": "GET", "url": "/api/error" },
"response": { "status": 500, "body": "Internal Server Error" }
}
Example 3: Mock Timeout
{
"request": { "method": "GET", "url": "/api/slow" },
"response": {
"status": 200,
"fixedDelayMilliseconds": 5000,
"jsonBody": { "message": "delayed" }
}
}
Example 4: Docker Compose with Application
services:
wiremock:
image: wiremock/wiremock:3.5.2
ports:
- "8080:8080"
volumes:
- ./wiremock:/home/wiremock
app:
build: .
environment:
- API_BASE_URL=http://wiremock:8080
depends_on:
- wiremock
Best Practices
- Organize mappings by feature: Use subdirectories like
users/,products/ - Version control mappings: Keep mappings in git for reproducible tests
- Test all error scenarios: 401, 403, 404, 429, 500, timeouts
- Reset between test runs:
curl -X POST http://localhost:8080/__admin/reset - Use descriptive file names:
get-user-success.json,post-user-error.json
Constraints and Warnings
- Ensure port 8080 is available or map to a different port
- Configure Docker networking when running multiple containers
- Enable
--global-response-templatingfor dynamic responses - WireMock resets mappings on container restart
Troubleshooting
Requests don't match stubs?
Check what WireMock received: curl http://localhost:8080/__admin/requests — shows unmatched requests with details about what was actually sent.
Stub file not loading?
Verify file location: place JSON stubs in wiremock/mappings/ and response files in wiremock/__files/. Check file permissions.
Connection refused errors?
Run docker compose ps to verify the container is running. Check port conflicts with lsof -i :8080.
References
See references/ for complete examples:
docker-compose.yml- Full Docker Compose configurationwiremock/mappings/- Complete stub examples for all scenarios
Related skills
More from giuseppe-trisciuoglio/developer-kit and the wider catalog.

zod-validation-utilities
Type-safe validation schemas for APIs, forms, and config with Zod v4 and strong TypeScript inference.

adr-drafting
Create Architecture Decision Records (ADRs) with consistent templates and repository-aware naming.

aws-cdk
AWS CDK TypeScript patterns for defining, validating, and deploying infrastructure as code.

aws-lambda-java-integration
AWS Lambda integration patterns for Java with cold start optimization below 1 second.

api-review
Review Kubernetes API and CRD design quality for Kelos changes and proposals.

design-cleanup
Remove design-change leftovers and rewrite code as if the new design was always there.