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 should respond to specific transactions (method + path, with templated responses), give it a policy for anything it doesn’t recognize, and deploy it to get a stable hostname your system under test can call exactly like the real thing.

Why not just stub it in code?

A code-level stub lives inside one test process and dies with it. A virtual service is a real, running, network-addressable endpoint — reachable by your app, your load test, your staging environment, or a teammate’s laptop, for as long as you keep it deployed. It behaves like a dependency because, from the network’s point of view, it is one.

What runs where — the current model

Every virtual service is its own workload — its own runtime pod, its own network route — deployed on a private datacenter (PDC) you select. There is no shared multi-tenant runtime and no managed-cloud placement: deploying a virtual service always means picking a PDC and spinning that service up on it.

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

2. Deploy. MaxoPerf spins up a dedicated runtime pod for that virtual service on the selected PDC, wires a Service + route, and gives you back a stable hostname — a real spin-up, not a state flip.

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. With no traffic for the configured idle window, the virtual service stops itself automatically and frees the workload — you only pay attention to it (and, on future metered tiers, only get billed) while it’s actually running.

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. Existing services created before this change were migrated onto the shared MaxoPerf system PDC automatically.

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 doesn’t match any transaction: return 404 Not Found (default), respond with a fixed status you choose, proxy through to a real origin (so you can mock some endpoints and pass everything else through untouched), or reject the connection outright.
• Transaction groups + composition. Reusable, named bundles of transactions you can share across multiple virtual services, composed together with individually-added transactions. See Compose & transaction groups.
• Think-scale. A percentage that scales response latency up or down, useful for rehearsing 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.

When to use a virtual service

• A real dependency is flaky, rate-limited, or expensive to hit repeatedly — a payment gateway sandbox with strict quotas, a partner API billed per call.
• The real dependency doesn’t exist yet — build and test your integration against a contract-accurate mock 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 ever 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.

Private datacenters Connect a self-hosted PDC via an Outpost agent — the placement target for a virtual service.