Virtual services — mock any dependency, on infrastructure you choose

A virtual service is a live, addressable mock of a real dependency: a payment gateway, a rate-limited partner API, a downstream microservice that doesn’t exist yet. You define how it responds to specific transactions (method + path, with templated responses) and give it a policy for anything it doesn’t recognize. When you deploy it, you get a stable hostname that your system under test calls exactly like the real thing.

Why not stub it in code?

A code-level stub lives inside one test process and dies with it. A virtual service is a running endpoint on the network. Your app, your load test, your staging environment, or a teammate’s laptop can reach it for as long as you keep it deployed. It behaves like a dependency because, to the network, it is one.

Get started with service virtualization.

What runs where: the current model

Every virtual service is its own workload, with its own runtime pod and its own network route, deployed on a private datacenter (PDC) you select. There is no shared multi-tenant runtime and no managed-cloud placement. To deploy a virtual service, you always pick a PDC, and MaxoPerf starts the service on it.

1. Pick a PDC. Choose a shared, MaxoPerf-published system PDC (zero setup; good for getting started or for anything that doesn’t need to sit inside your network). Or choose a self-hosted PDC you’ve already connected with an Outpost agent. A self-hosted PDC fits when the virtual service must be reachable from inside your own network, next to the real system it replaces.

2. Deploy. MaxoPerf starts a dedicated runtime pod for that virtual service on the selected PDC, wires a Service + route, and returns a stable hostname. The deploy starts a real workload; it does not only change a status.

3. Call it. Point your system under test, or a load test, at the returned endpoint. It answers exactly like the real dependency for every transaction you’ve defined.

4. Idle-shutdown. After the configured idle window with no traffic, the virtual service stops itself and frees the workload. You only need to think about it (and, on future metered tiers, only pay for it) while it runs.

Note

Earlier revisions of this feature ran a single shared runtime that answered for every customer, plus a “managed cloud” placement option. Both are retired. Every virtual service you deploy today gets its own workload on a PDC you choose. MaxoPerf moved services created before this change onto the shared MaxoPerf system PDC automatically.

Virtual services list. Each row shows where the service is deployed and whether its workload is running right now.

What you define

• Transactions. Each transaction matches a request (method + path, with parameter placeholders) and returns a templated response: status, headers, and body, all built from the request or from data variables.
• No-match policy. What happens when a request matches no transaction. Return 404 Not Found (default), respond with a fixed status you choose, proxy through to a real origin (so you mock some endpoints and pass everything else through unchanged), or reject the connection.
• Transaction groups + composition. Reusable, named bundles of transactions that you share across multiple virtual services and combine with transactions you add one by one. See Compose & transaction groups.
• Think-scale. A percentage that scales response latency up or down. Use it to see how your system behaves against a slower (or faster) version of a dependency.
• Custom domain. Bring your own hostname and TLS certificate instead of the generated *.vs.maxoperf.com endpoint.
• State. Remember values per caller or for everyone in MaxoPerf’s own durable, shared database — so a value survives a restart, a redeploy, or an idle auto-shutdown. Transform captured values, serve them back in responses, branch with cases and flows, count, generate a full CRUD resource in one click, try it safely before you save, and back up or restore. See State & scenarios.

What you get back

Every deployed virtual service records what it served. The Analytics tab breaks traffic down over time by outcome (matched, passthrough, failover, unmatched, fault), next to served-latency percentiles and a per-transaction table. You see which transactions carry the load and which requests still fall through with no match.

Analytics for a deployed virtual service: match rate, the outcome mix over time, and a per-transaction breakdown. Unmatched paths appear as their own line item, and that is usually where the next transaction to write comes from.

When to use a virtual service

• A real dependency is flaky, rate-limited, or expensive to call repeatedly, such as a payment gateway sandbox with strict quotas or a partner API billed per call.
• The real dependency doesn’t exist yet. Build and test your integration against a mock that matches the contract while the other team builds the real thing.
• You need to load-test a system whose downstream can’t take production-scale traffic. Deploy a virtual service in place of the fragile dependency and drive load at your system without touching the real one.
• You want deterministic, repeatable responses for a scenario a live system can’t reliably reproduce (specific error codes, edge-case payloads, latency profiles).

Next steps

Create and deploy Create a virtual service, pick a PDC, deploy it, and configure idle-shutdown and the no-match fallback.

Compose & transaction groups Build reusable transaction groups and compose a virtual service from groups plus individual transactions.

State & scenarios Remember values durably per caller or for everyone, transform them, serve them back, branch with cases and flows, try it safely, and back up or restore.

Private datacenters Connect a self-hosted PDC with an Outpost agent. It is the placement target for a virtual service.