Shadow Backends and Keploy Qualification
Adapted from textbook chapters 10–11. Select the least expensive backend that executes the required runtime and event topology correctly. A familiar preview or a command that starts successfully is not evidence of complete isolation or replay fidelity.
Current Keploy adapter
BestBuds has k3s record/start/stop scripts, R2 archive/pull scripts and a local keploy-local-test.sh. The archived bundle and metadata make HTTP recordings portable. They do not yet establish equivalent Postgres/Memgraph/R2 pre-state, safe effects, graph attribution or a fully reconstructed distributed execution.
The archive schema is reaktor.keploy.r2.v1; it records capture/deployment/cluster/storage metadata but not the complete artifact vector and base identity proposed by this textbook. The local runner can be overridden with KEPLOY_COMMAND; its default image uses latest, so a recorded test cannot be assumed to execute the captured release. Pin the actual candidate artifact and runner distribution before making a verification claim. Source paths are in References.
Keploy's role
Keploy observes below graph semantics and complements Service-level capture. Qualify its exact distribution/edition, version, OS/architecture, application command, driver/protocol, TLS and artifact locality. Linux/eBPF and native proxy modes have different capabilities; neither attaches directly to a managed Worker isolate.
The current Keploy documentation describes mock record/mock replay for existing test commands, with miss policies fail, passthrough and record. Verification uses fail-on-miss. Refresh/recording is a separate authorized operation; a candidate cannot silently rewrite its own oracle. Where registry/locality behavior differs by edition, qualify the chosen local storage flags and destination. Mocking existing tests, installation.
Commands in upstream examples are not proof that the repository's installed binary implements that interface. Kubernetes proxy support is an optional separately qualified backend. Kubernetes quickstart.
JVM process recording and dependency replay
Shadow explicitly includes Keploy-style recording of a JVM process's incoming API cases and supported outgoing dependency interactions, followed by candidate execution against recorded responses. The application executes its own code during replay. This is distinct from JVM profiling, and it complements deeper in-process method/value/state recording through the Capture fabric. Keploy's execution model.
The checked-in integration uses Kubernetes recording plus the local keploy test runner. Dependency-only mock record/mock replay around existing tests is a separate upstream interface to qualify, rather than a description of what that script currently executes. Pin the exact process/container scope, JVM and agent configuration, candidate JAR/image digest, driver/protocol and TLS behavior. Prove recorded dependency substitution with the real dependency unavailable, and verify that a missing record cannot escape the declared effect policy.
Current recording defaults include static deduplication, a configured sampling value and health/status exclusions. These must appear in the coverage receipt; they do not establish exhaustive process recording. The install script pins a chart version, but that alone does not qualify the active capture mode or runner. Process recording also does not reconstruct arbitrary heap state, clocks, randomness or thread schedules. Stronger capabilities remain explicit runtime adapters with their own evidence.
Backend choice
| Backend | Useful scope | Qualification boundary |
|---|---|---|
| Local JVM/container + Keploy | Existing application tests and supported network dependencies | Protocol/TLS, process scoping, pre-state and real-effect denial |
| Local Worker test runtime | Fast workerd-compatible Worker/binding tests | Runtime/plugin version, storage/concurrency isolation and actual binding coverage |
| Worker Preview | Branch request/DO behavior with configured resources | Verify every binding and event source; no assumed fleet-wide isolation |
| Dedicated dev Worker fleet | Full service-binding/queue/workflow topology | Per-workspace destinations, credentials, routes, state and cleanup |
| Dynamic Worker | Capability-constrained candidate code under an owning host | Defined bindings/runtime; it does not clone an application's entire fleet |
| Database branch/restore | Isolated relational pre-state | Data content, sanitization, schema/sequence state, cost and source checkpoint |
Cloudflare's current Previews isolate DO namespaces and container instances, but KV/D1/R2 require separate resources. Service bindings call the bound Worker's production deployment; Workflow bindings use existing Workflows; Queue consumers cannot target a Preview; routes and Cron target production. Preview URLs are public by default. Therefore a Preview needs explicit topology and access qualification before it is a Shadow backend. Previews.
The current Worker testing package is @cloudflare/vitest-plugin; qualify storage isolation and concurrency against its installed version. Outbound HTTP mocking is not a general storage materializer. Vitest integration, migration guide, outbound mocks.
Supabase branches are data-less by default; copying production data through supported branch creation is a separate option, not continuous sanitization. Branching. Dynamic Workers provide an execution capability, not an implicit multi-store clone. Dynamic Workers.
Conformance receipt
For each backend retain: exact versions, image/artifact hash, runtime compatibility, destinations, supported protocols/bindings, test workload, assertion result and capture artifacts. Exercise success/error/TLS, identical parallel operations, missing/unused records, cancellation, partial streams, retries and cleanup.
Process-scoped recordings do not by themselves establish request causality for multiplexed clients. Select exactly one substitution owner at each boundary. If a required capability is unqualified, show it as unavailable and choose a backend with the required behavior. A release result identifies the backend actually used, not an interchangeable platform logo.