Replay a Speedscale Cloud Snapshot Locally
Use this path when the traffic is already in a Speedscale Cloud snapshot and you want to test a version of your app on your laptop. proxymock pulls the snapshot into your application repository, serves its dependency responses as mocks, and sends its recorded requests to your local app.
Before you begin
- Install proxymock CLI. If speedctl already uses your enterprise tenant's credentials, reuse the shared configuration; a second initialization is unnecessary.
- Have access to the tenant that owns the snapshot. Free local activation alone does not grant that access. If needed, initialize with your enterprise account. If you already activated proxymock with another account, follow the configuration replacement steps;
proxymock init --api-keyalone keeps an existing configuration. - Copy the snapshot ID from the Speedscale dashboard. Open the snapshot's actions menu to copy its ID.
- Prepare a local version of the app and know its listening port. The example below uses
8080; replace it with your port.
Run these commands from your application repository so the downloaded recordings and replay results stay with that app.
1. Pull the snapshot
In your first terminal, replace your-snapshot-id with the ID you copied:
SNAPSHOT_ID="your-snapshot-id"
proxymock cloud pull snapshot "$SNAPSHOT_ID"
The default output directory is ./proxymock/snapshot-<snapshot-id>. The pull converts the snapshot's traffic into local RRPair files for mocking and replaying. Keep that directory as the input for both commands below so you test this snapshot rather than another recording in the workspace.
To explore the imported requests, run proxymock web and select the snapshot run in the Requests tab. This is optional; you can continue entirely from the CLI.
2. Start mocks and your local app
In the same terminal, start the mock server with that snapshot and let proxymock launch your app. Replace ./your-app with your actual startup command, such as npm start or go run .:
proxymock mock --in "./proxymock/snapshot-$SNAPSHOT_ID" -- ./your-app
Leave this terminal running. proxymock serves recorded outbound dependency responses while your app handles inbound requests. Clients that need SOCKS or explicit port mapping need the setup described in language configuration.
Unmatched dependency requests pass through to the real destination by default. Add --no-passthrough to the mock command to return a failure instead. See proxy behavior and mock match-rate tuning if calls do not match the recording.
3. Replay the snapshot against the app
Open a second terminal in the same repository. Set the same snapshot ID again because terminal variables are separate, and replace 8080 with your app's port:
SNAPSHOT_ID="your-snapshot-id"
proxymock replay --in "./proxymock/snapshot-$SNAPSHOT_ID" \
--test-against http://localhost:8080
The target is your app's listening address. The replay sends recorded requests to that app, and the app's dependency calls go to the mock server from step 2. Check the replay summary for failures and compare responses to the recording. Stop the mock/app terminal with Ctrl-C when finished.
By default, inbound traffic becomes tests and outbound traffic becomes mocks. A snapshot can carry a saved replay selection that changes this split; see Choose What a Replay Tests. Downloading a snapshot and running these commands locally does not start a cloud-managed cluster replay.
Next steps
- Debug a replay when a request fails.
- Configure replay test configs and blueprints to adjust a run.
- Run in CI/CD to check recorded traffic after each build.
- Choose a cluster or cloud replay path when you want to run beyond your laptop.
For an existing script that calls speedctl replay <snapshot-id>, use the speedctl replay walkthrough. It remains a supported route for that workflow; the commands on this page use proxymock.