AIdeas Finalist: MockNest Serverless
MockNest Serverless is an open-source, serverless, AI-assisted API mocking platform for AWS that helps teams test integrations faster when external APIs are unavailable, unstable, or hard to control. It uses a lightweight mock runtime in the customer’s own AWS account and AI-generated mocks from API specifications and natural-language instructions to cut setup time and reduce manual mock maintenance.
App Category
Workplace Efficiency
MockNest Serverless helps engineering and test teams spend less time waiting on unstable external APIs and maintaining manual mocks during integration testing.
My Vision
We were building a serverless pension administration system that integrated with Salesforce, financial services, and government APIs. In some environments, outbound internet access was blocked entirely. In others, sandbox APIs returned only static test data. Business scenarios spanning years of life events - retirement, disability, partner changes - were nearly impossible to reproduce. Integration testing became slow, fragile, and difficult to trust.
MockNest Serverless grew out of that experience. It deploys directly into the customer's own AWS account and is designed to make realistic mocks faster to create and easier to maintain as APIs evolve. The same pattern appears far beyond pension administration: teams depending on payment providers, product catalogs, delivery systems, or customer APIs face the same friction when those services are down, rate-limited, or return inconsistent test data.
Today, MockNest provides a WireMock-compatible mock runtime on AWS Lambda with API Gateway ingress and Amazon S3 persistence. Using Amazon Bedrock with Amazon Nova Pro, it generates validated WireMock-compatible mappings for REST/OpenAPI, GraphQL, and SOAP APIs, with automatic validation and bounded self-correction. It also supports webhook and callback simulation for testing asynchronous and event-driven integration flows. Teams can deploy it using AWS SAM or directly from the AWS Serverless Application Repository .
The longer-term vision is to move from mock generation to intelligent mock maintenance - detecting missing scenarios, keeping mocks aligned with evolving contracts, and reducing manual effort over time.
Why This Matters
Modern cloud-native systems depend on external services - payment gateways, CRM platforms, government APIs, and many others. Integration testing slows down when those services are unstable, unreachable from test environments, or expose only limited test data. The result is slower delivery, brittle workarounds, weaker feedback loops, and failures discovered only in production.
The systems that need this most are not trivial - pension platforms, payment systems, healthcare integrations. If a pension system doesn't correctly handle a partner change - a new cohabiting partner, a divorce mid-year - the survivor's pension may not be paid out when it should be. The partner is left without income they are entitled to, not because of a policy decision, but because the edge case was never tested. MockNest is a developer tool, but the people who benefit most never see it - the partner whose survivor's pension is calculated correctly because the edge case was tested.
In the pension administration context that inspired MockNest, engineering teams use it where outbound internet access is blocked. End-to-end test teams use it to simulate government APIs whose sandbox data is static, making it possible to test edge cases that are not covered by the datasets provided by the real API. One engineering team already uses MockNest directly, and two end-to-end test teams are evaluating it for scenarios that are impractical to test against the real dependencies.
Competitive landscape
MockNest is fully open-source, and its key differentiator is the operating model: it runs inside the customer's own AWS account as a serverless runtime, with no Kubernetes, containers, or vendor-hosted control plane. Alternatives are primarily hosted SaaS platforms. Some offer customer-hosted options, but those typically require Kubernetes, Docker, or a separate database that the customer must operate.
Solution | Delivery | Customer-hosted option | Serverless | AI mock generation | IAM auth | Pricing |
|---|---|---|---|---|---|---|
MockNest Serverless | Own AWS account | N/A (already customer-hosted) | ✅ | REST / GraphQL / SOAP | ✅ | Open source |
| WireMock Cloud | Hosted SaaS | Kubernetes + Postgres | ❌ | REST / GraphQL | ❌ | Free tier + paid |
| Mockoon Cloud | Hosted SaaS | CLI / Docker (self-assembly) | ❌ | HTTP / JSON templates | ❌ | Paid + trial |
| Beeceptor | Hosted SaaS | Docker / VMs / Kubernetes | ❌ | REST / GraphQL / SOAP / gRPC | ❌ | Free tier + paid |
| Postman Mock Servers | Hosted SaaS | Local desktop only | ❌ | HTTP example-based | ❌ | Free tier + paid |
Demo
How I Built This
AI-assisted development process
I built MockNest with Kiro[1] as a development partner. I created steering documents that provide long-lived context for requirements, design, and code generation: product direction, architecture and AWS design, and development practices. Kiro's structured workflow plans changes through requirements, design, and tasks before code generation, with checkpoints to verify acceptance criteria. Using this workflow, I built MockNest incrementally while keeping the implementation aligned with the intended architecture.
Architecture and AWS-native design
MockNest is built in Kotlin with Koog[2] for Kotlin-native AI orchestration with Amazon Bedrock. The code follows a simplified clean architecture for serverless[3]: domain for business rules, application for use cases and orchestration, and infrastructure for AWS-specific integrations.
The runtime is AWS-native: AWS Lambda for the mock runtime, AI generation, and asynchronous callback handling, Amazon API Gateway for HTTP ingress, Amazon S3 for persistent mock storage, Amazon SQS for decoupled webhook delivery, and Amazon Bedrock for AI generation. It deploys through AWS SAM or the AWS Serverless Application Repository, without Kubernetes, containers, or a customer-managed database.
Prompting, validation, and correction flow
MockNest parses and compresses the incoming API specification into a protocol-specific AI context, keeping the prompt focused while reducing token usage, latency, and cost. That context is assembled with the user's natural-language instructions, WireMock schema rules, and a prompt template before being sent to Amazon Bedrock. REST/OpenAPI, GraphQL, and SOAP each use their own prompt and validation path.
Amazon Nova Pro generates candidate WireMock-compatible mappings, which are validated against the parsed API contract. If some mappings fail validation, MockNest issues a bounded correction retry using only the invalid mocks and their errors. Only mappings that pass validation are returned.
Milestones
MockNest was built incrementally across seven milestones: serverless runtime, AI mock generation, SAR release readiness, quality and security improvements, performance tuning, IAM authentication, and webhook/callback support with optional IAM-secured targets.
Performance tuning
I added SnapStart with priming to all three AWS Lambdas and used AWS Lambda Power Tuning to guide memory selection. Tests were kept bounded under the AWS Free Tier Terms[4].
Performance tuning snapshot
Scenario | Best tested memory | Avg duration | Avg cost/invocation | Takeaway |
|---|---|---|---|---|
100 mocks | 1024 MB | 118.9 ms | $0.000001632 | Good fit for typical development-time usage |
1000 mocks | 1536 MB | 113.0 ms | $0.000002326 | Larger catalogs need more memory headroom |
Security considerations
MockNest supports either API key or IAM authentication for the API — the customer chooses during deployment. Webhook callbacks support no auth, mock-defined auth, or IAM signing. SAM templates follow least-privilege principles.
Quality, testing, and delivery
- 80% code coverage enforced with Kover[5], published through Codecov[6]
- Integration tests with Testcontainers[7] and LocalStack[8]
- GitHub Actions[9] for automated build, deployment, SAR publishing, and secure pipeline practices
- Prompt quality tested with manual, gated Bedrock evals using Dokimos[10], its Koog integration[11], and eval-driven development[12] in a remocal-style setup[13][14], kept bounded under the AWS Free Tier Terms[4]
Latest eval results
Protocol | Scenarios | Valid (no retries) | Valid (1 retry) | Valid (2 retries) | Semantic pass | Avg cost | Avg latency |
|---|---|---|---|---|---|---|---|
REST | 16 | 93% | 100% | 100% | 100% | $0.005 | 2.5s |
GraphQL | 15 | 81% | 93% | 100% | 100% | $0.007 | 2.3s |
SOAP | 15 | 100% | 100% | 100% | 93% | $0.006 | 3.2s |
These results come from a 46-scenario eval suite and show that bounded retries improve generation quality where needed, with the full methodology, cost, and latency details documented in the prompt eval guide .
Current limitations
Large mock catalogs can affect cold-start performance and require higher memory settings. SnapStart with priming helps significantly, and splitting usage across multiple deployments is a practical workaround. Future releases will implement shared cache storage to reduce startup loading. True server-driven streaming such as Server-Sent Events is not yet supported.
What I Learned
Which feedback resonated most and what I changed
I agreed with the judges’ feedback and used it to re-prioritize. I focused on the changes that most improved trust and usability within the time available: IAM authentication, webhook and callback support, SnapStart with priming, clearer performance guidance, and a more explicit competitive comparison.
The security feedback moved IAM support higher on the backlog, making the product more practical for stricter environments. The comparison feedback pushed me to clarify what MockNest adds that other tools do not. Performance was already in progress, so I followed it through with SnapStart, performance testing, and better tuning guidance.
Context and architecture matter more than prompts
The most important lesson was that AI works better with strong, unambiguous context than with clever prompts alone. I started by writing steering documents that describe the product vision, architecture, and development guidelines. These gave Kiro[1] persistent context, so the output stayed closer to the intended design. When results didn't match expectations, improving the steering improved the next iteration. Clear architecture boundaries - domain, application, infrastructure - also helped Kiro place code in the right layer, keeping business logic independent from AWS-specific code.
Smaller features and requirements-first work better with AI
Breaking work into smaller, clearly defined features made development smoother. Smaller deliverables were easier to review, adjust, and regenerate. When scope became too large, corrections increased. Reviewing requirements before code generation was often more effective than reviewing code after the fact - good requirements and clear guardrails prevented many problems before they appeared in code.
Eval-driven development improves prompt quality
Instead of testing prompts by intuition, I ran gated Bedrock evals in a remocal-style setup, comparing retry = 0 and retry = 1, and measuring scenario correctness, cost, and latency. That created a faster feedback loop for prompt work.
Test-first guardrails catch issues early
Bug fixing and refactoring worked well when changes started from tests. Integration tests with Testcontainers and LocalStack were especially useful because they validated real AWS interactions and exposed issues that unit tests alone would not catch.
What's Next
The roadmap continues toward intelligent mock maintenance: lenient mocks, traffic analysis, automated mock evolution, streaming support, MCP-related features, and reducing the in-memory mapping footprint.
References
[1] Kiro
[2] Koog
[3] Clean Architecture for Serverless
[4] AWS Free Tier Terms
[5] Kover
[6] Codecov
[7] Testcontainers
[8] LocalStack
[9] GitHub Actions
[10] Dokimos
[11] Dokimos Koog integration
[12] evaldriven.org
[13] Remocal development
[14] InfoQ: Efficient Serverless Development
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article