Create and deploy a virtual service

Before you start

You’ll need a PDC to deploy to — either a shared system PDC (always available, zero setup) or a self-hosted PDC you’ve connected via an Outpost agent. You can create a virtual service and define its transactions without a PDC selected, but you cannot deploy until one is chosen.

Create a virtual service

1. Open Virtual services in the left navigation, and click New virtual service.
2. Give it a name and select or create the transaction group that becomes its home group (where transactions you build on the fly land by default — see Compose & transaction groups).
3. Save. The virtual service is created in a stopped, undeployed state — no workload is running yet, and it has no live endpoint.

📷 Screenshot to capture — vs-new

What to show:MaxoPerf New virtual service dialog with a name field and a transaction group selector

Create a virtual service: name it and choose its home transaction group.

Create it from a REST API request

curl -X POST https://app.maxoperf.com/v1/virtual-services \
  -H "Authorization: Bearer mpak_example_key" \
  -H "X-Account-Id: acn-1234567890" \
  -H "Content-Type: application/json" \
  -d '{
    "workspaceId": "ws_01J...",
    "serviceId": "vssvc_01J...",
    "name": "payments-sandbox-mock",
    "noMatch": { "policy": "notFound" },
    "idleShutdownMinutes": 30
  }'

The 201 response includes state:"stopped", placement:{"privateDatacenterId":null}, and a reserved (not-yet-live) hostname/endpointUrl on the generated *.vs.maxoperf.com domain.

Define transactions

Open the virtual service’s Transactions tab to add the request/response pairs it should answer. Each transaction matches on method + path (with parameter placeholders) and returns a templated response — status code, headers, and a body built from the request or from data variables. See Compose & transaction groups for how transactions, groups, and composition fit together on a single virtual service.

Pick a private datacenter and deploy

Open the Deployment tab.

📷 Screenshot to capture — vs-deploy-panel

What to show:MaxoPerf virtual service Deployment tab showing the status badge, Deploy button, PDC placement selector grouped into Shared (MaxoPerf) and Self-hosted, and the no-match fallback policy fields

Deployment tab: status + Deploy/Stop, the grouped PDC placement selector, and the no-match fallback configuration.

1. Under Configuration, open the Private datacenter selector. PDCs are grouped Shared (MaxoPerf) (the system catalog — no setup required) and Self-hosted (PDCs your workspace has connected). Pick one.

2. Set the no-match policy — what the virtual service does for a request that matches none of its transactions:

   Policy	Behavior
   404 Not Found (default)	Returns a plain 404.
   Respond with a fixed status	Returns a status code and body template you choose.
   Proxy to a real origin	Forwards the request to a real origin URL — mock the transactions you care about, pass everything else through untouched.
   Reject the connection	Drops the connection instead of returning an HTTP response.

3. Save the configuration.

4. Click Deploy. The virtual service moves to deploying while MaxoPerf provisions a dedicated runtime pod on the selected PDC and wires its route — this is a real spin-up, not a state flip, so it takes a few moments the first time. Once ready, the status flips to running and the endpoint at the top of the page becomes live.

Note

The Deploy button stays disabled until a PDC is selected and saved. Changing placement later requires the virtual service to be stopped first — you can’t move a running virtual service to a different PDC without stopping it.

Deploy and stop from the REST API

curl -X POST https://app.maxoperf.com/v1/virtual-services/<id>/deploy \
  -H "Authorization: Bearer mpak_example_key" -H "X-Account-Id: acn-1234567890"

curl -X POST https://app.maxoperf.com/v1/virtual-services/<id>/stop \
  -H "Authorization: Bearer mpak_example_key" -H "X-Account-Id: acn-1234567890"

Both return { "id": "...", "state": "running" | "stopped" } immediately — the transition itself is asynchronous; poll GET /v1/virtual-services/<id> (or watch the console) for the final running/stopped/error state.

Idle-shutdown

Set Idle-shutdown (minutes) on the virtual service’s Settings tab — the number of minutes of no traffic before MaxoPerf automatically stops the workload and frees its PDC resources. Default is 30 minutes; set it to 0 to disable idle-shutdown and let the virtual service run indefinitely once deployed. There’s no separate lifetime cap — a deployed virtual service runs until it goes idle, you stop it manually, or you redeploy it later.

Stop paying attention to a service you're done with

If you’re only using a virtual service for a one-off test run, leave the default idle-shutdown in place rather than raising it — an unattended virtual service with a long idle window keeps its workload running (and, on future metered tiers, keeps billing) until you remember to stop it.

Custom domain (optional)

By default a virtual service is reachable at its generated *.vs.maxoperf.com hostname. To front it with your own domain:

1. On the Deployment tab, upload a custom TLS certificate for your domain (private key is encrypted at rest and never returned by the API).
2. Set Custom domain on the Settings tab to your hostname.

Clear the custom domain by setting it back to empty — the virtual service falls back to its generated hostname.

Next steps

• Compose & transaction groups — build reusable groups and compose a virtual service from multiple sources.
• Private datacenters — connect a self-hosted PDC.
• Virtual services overview — the full model and when to use it.