Mockdoor is primarily a mocking and debugging for developers but designed and optimised for large scale, Multi tenanted Microservice environments. What makes Mockdoor unique compared to other mocking systems, and what enables it to scale and be adopted by even large existing systems its its fundamental design. It can act as a normal mock but you can (and it is recommended you do) use it as a middle layer between your services, it transparently proxies requests but learns them while doing so. It can then learn entire systems behaviours for common and repetitive tasks, enabling the ability to train on test data (such as from Automated test runs).

Mockdoor can be run on single tenant and a single or only a few services but its power really shines when put to scale.

Unlike other mocking systems Mockdoors design enables far more than simple mocking. It has also been designed from the start to have minimal setup and configuration to your existing systems and a fundamental believe with Mockdoor is you should never have to change your code to work with Mockdoor and from your softwares perspective it should behave as it Mockdoor isnt even there.

Mockdoor has a huge amount of additional uses that are possible due to its design. Below we will list some examples but stay tuned to our https://www.mymockdoor.com/tutorial-demo-announcements/ for updates and demos on new use cases.

• Setting up “Test” environments: Using groups you can setup your Microservices into a known state for a particular set of tests. For example a “Azure AD customer test environment”. By organising them into groups or using the time travel feature at a group level you can set up all kinds of mocking templates across multiple services with a single click or url change
• Remove dependencies during testing or development: If you have a bunch of Microservices you are currently running in development or on test environments during testing or developing a particular Microservice you can remove this dependency without needing to manually code a mock for all data. Just point the service you are developing to Mockdoor instead, run your tests or development for a while with the real service active, and once you are done, turn off the real service and tell Mockdoor to mock it from now on. Even as changes happen on the dependencies, re-enable them briefly to get the update and you can continue to mock again right away.
• Debugging failed requests: Getting 401s or 403s? or a failed request? With Mockdoor you can view the request history or live feed and check the access tokens or body to see what actually happened. Or if you have a transience error that occurs but is hard to reproduce and its related to the brief state of your services? Run the system with Mockdoor until the error occurs. Enable the Time travel feature (Simulate Time) and your entire environment will replicate the bad state at the time of the error.
• Parallel development of UI and backend (APIs): With Mockdoor running in development environments you can have a hybrid of real and mock data from the same service (Mockdoor). What this enables is UI can use Mockdoor against the real service but when they need to develop an API call and UI for an endpoint that does not yet exist that can easily add this to Mockdoor as a custom mock response without changing any code or configuration at all. When the real service is completed by the API team then just toggle the endpoint to return live results (instead of mock) and it will be running with the real API.
• Multi tenant a single tenant API: Have an API that returns the same response for all tenants but you want to test it on a per tenant basis? Configure it in Mockdoor for each tenant pointing to the single tenant API. Then for the tenants you want custom/different responses override their response.

Yes — Mockdoor is completely free to use.
We’re committed to keeping it that way for the vast majority of users, including individuals, hobbyists, and small businesses. We believe in open source and have no plans to lock Mockdoor behind a paywall.

That said, to ensure we can keep improving and supporting the project long term, we may eventually explore paid options for large companies or heavy commercial users — for example, those with significant revenue or infrastructure needs. If we go that route, there will always be a generous free tier, and we’ll be transparent about any changes.

Our goal isn’t to get rich — it’s to keep Mockdoor sustainable and fair.

This is a common misconception, because developers don’t see how many use cases it has and because many of them seem niche or uncommon developers can think “if the issue comes up i can sort it myself”

But when you do need it, it can save huge amounts of time and solve issues that other tools either can’t solve or would take far longer to get setup and running.

Also it can be used to save huge amounts of money on running containers in larger and larger clusters. With Mockdoor you can reduce the size of clusters and therefor costs by huges amounts.

Ask yourself this, is “postman” a nice to have? Is seq a nice to have? or application insights? All of these tools solve problems you can solve yourself or do yourself if you wanted (curl expressions, raw log files and streams etc)

Yes, potentially. 

Heres how:

If you have many microservices running in you cluster that your not developing on regularly or at all. But you still need to to provide standard behaviour, maybe some configuration or documents need returning to the the service you use, maybe theres a service to handle feature flags or all sorts of over things you dont care about but if its missing your service wont work.

Well with Mockdoor you can almost instantly replace them, if you have say 20 services like this, each using 200 MB of ram on your VM thats 4GB of ram your wasting. And thats not taking into account all those other services might have complex business logic running and uses more resources (service bus, blob storage, key vault etc) running up secondary bills.

If you had Mockdoor running you have a single service with a pretty much fixed overhead for memory replacing that 4GB with more like 200mb. It has one dependency (and that on a small scale is optional) and that’s the database. So you save money on VM costs directly and potentially on all your downsteam services like Azure KeyVault or Storage or event hubs etc

Below you can try out the savings calculator which gives just the potential savings on VM alone