Skip to main content

Closed-Loop Verification with Cursor and Signadot

Prerequisites
  • Signadot CLI v1.4.0+: Required for MCP support. Run signadot --version to check.
  • Go 1.21+: The demo application (HotROD) requires log/slog. Build will fail on older versions.
  • Kubernetes Cluster: You can use any cluster (EKS, GKE, Kind), but this tutorial uses Minikube.
  • Signadot Account: An active account at signadot.com.
  • Cursor IDE: Cursor installed with MCP support enabled.
  • Node.js with npx: Used to install Agent Skills (npx skills add …).

Overview​

Testing local microservice changes against a shared Kubernetes cluster often involves a mess of kubectl port-forward commands, brittle mocks, or waiting for CI/CD pipelines just to verify a one-line change.

In this tutorial, we will establish a workflow for local debugging using Signadot and Cursor (the AI IDE) with two complementary integrations: Signadot MCP, which lets the agent discover clusters, workloads, and sandboxes through the Signadot control plane, and the signadot-validate skill, which drives a repeatable validation loop against real cluster dependencies. You can instruct Cursor's agent to spin up a sandbox that routes traffic from a shared cluster to your local machine, all via natural language.

Read more in Introducing the signadot-validate Skill.

HOT R.O.D frontend application

Baseline Setup (HotROD)​

First, we establish the baseline environment. We will use the "HotROD" demo application.

Start the Cluster & Install Operator​

Start your local cluster and install the Signadot Operator.

Ensure your kubectl context is set to your target cluster:

kubectl config get-contexts  # List available contexts
kubectl config use-context <your-cluster-context>  # Switch to your cluster

Follow the install instructions found in your Signadot Dashboard under Clusters → Connect. The dashboard will show you the commands to run:

Signadot connecting cluster - commands to run

After running the commands, you should see success in your terminal:

Cluster connection commands executed successfully

Install the HotROD Baseline​

Deploy the demo microservices into the hotrod namespace.

kubectl create ns hotrod || true
kubectl -n hotrod apply -k 'https://github.com/signadot/hotrod/k8s/overlays/prod/devmesh'

Verify that the baseline pods are running. Application deployments should show the DevMesh sidecar (hotrod and sd-sidecar, ready 2/2):

kubectl -n hotrod get pods -o custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[*].ready,CONTAINERS:.spec.containers[*].name

If pods are only 1/1, ask Cursor to restart the affected deployments so the Signadot mutating webhook can inject sidecars. Without sd-sidecar, sandbox routing to your local machine will not work.

HotROD namespace and pods created

Step 1: Local Connect (Required)​

To route traffic from the cluster to your laptop, we use signadot local connect. This step must be completed and running before proceeding to Step 3.

Create or edit your config file at ~/.signadot/config.yaml:

~/.signadot/config.yaml
local:
  # Use a benchmarking CIDR to avoid conflicts with home/office Wi-Fi
  virtualIPNet: 198.18.0.1/16
  connections:
    - cluster: hotrod-test
      # Force PortForward for stability on Minikube
      type: PortForward
      kubeContext: minikube

Confirm your cluster is registered by running signadot cluster list and checking for hotrod-test. The cluster value in ~/.signadot/config.yaml and in --cluster flags must match the name shown there.

Authenticate your CLI:

signadot auth login

The CLI will open your browser for authentication. You'll see a waiting state in the terminal:

Waiting for authentication in CLI

Complete the authentication in your browser:

Authentication confirmation code in browser Authentication success in browser

Once authentication completes in the browser, the CLI receives the callback and shows success:

Authentication success in CLI

Connect to the Cluster​

Run this command as your normal user (do not use sudo):

signadot local connect --cluster hotrod-test

The process will run in the background. You'll be prompted for your password when it needs to update /etc/hosts.

Gate Check: Verify Routing​

Before proceeding to Step 3, we must prove the tunnel is working. If this check fails, the sandbox will not work.

Run this in your terminal:

curl -I http://frontend.hotrod.svc:8080

  • HTTP 200 OK: ✅ Proceed to Step 3.

  • Hang/Timeout: ❌ Stop. This may be due to a virtualIPNet CIDR conflict with your VPN or network configuration. See advanced configuration options to adjust your network settings.

Keep Local Connect Running

The signadot local connect process must remain running for the duration of your debugging session. Do not interrupt the process.

Step 2: signadot-validate and Cursor MCP​

Install the signadot-validate skill to enable repeatable validation against real cluster dependencies, and bridge Cursor to the Signadot CLI so the AI Agent can control Signadot.

Install the signadot-validate skill​

From any directory, install the skill into Cursor globally so it is available in any project you open:

Install signadot-validate skill
$npx skills add signadot/agent-skills --skill signadot-validate -g -a cursor -y
◇ Source: https://github.com/signadot/agent-skills.git
│
◇ Repository cloned
│
◇ Found 2 skills
│
● Selected 1 skill: signadot-validate
│
◇ Installation Summary ───────────────╮
│ │
│ ~/.agents/skills/signadot-validate │
│ copy → Cursor │
│ │
├──────────────────────────────────────╯
│
◇ Security Risk Assessments ───────────────────────────────────────╮
│ │
│ Gen Socket Snyk │
│ signadot-validate Safe 0 alerts Low Risk │
│ │
│ Details: https://skills.sh/signadot/agent-skills │
│ │
├───────────────────────────────────────────────────────────────────╯
│
◇ Installation complete
│
◇ Installed 1 skill ──────────────────────╮
│ │
│ ✓ signadot-validate (copied) │
│ → ~/.agents/skills/signadot-validate │
│ │
├──────────────────────────────────────────╯
│
└ Done! Review skills before use; they run with full agent permissions.

Confirm installation:

Verify skill installation
$npx skills list
Project Skills
signadot-validate ~/.agents/skills/signadot-validate
Agents: Cursor

You should see signadot-validate listed for Cursor.

Skill install path

The skill is stored at ~/.agents/skills/signadot-validate, which is the canonical location. The copy → Cursor step in the install output above makes it available to Cursor's agent from there.

Install Cursor MCP​

  1. Click the button below to automatically install the Signadot MCP server in Cursor:
Install in Cursor

Alternatively, you can visit the Signadot MCP Cursor documentation page.

  1. Fallback: If the link doesn't work, manually edit ~/.cursor/mcp.json:
~/.cursor/mcp.json
{
  "mcpServers": {
    "signadot": {
      "command": "signadot",
      "args": ["mcp"]
    }
  }
}

Verify the installation in Cursor Settings > Features > MCP.

MCP configuration in Cursor MCP server showing in Cursor settings

For detailed setup instructions, see the Signadot MCP Cursor guide.

Step 3: The Workflow​

Prerequisite

Ensure Step 1 (Local Connect) is running and healthy before starting this workflow. The signadot local connect process must be running in the background.

We will now use Cursor to drive the infrastructure.

  1. Open the HotROD repository in Cursor: git clone https://github.com/signadot/hotrod

  2. Open Cursor Chat (Cmd+L or Ctrl+L).

Prompt 1: Sanity & Cleanup​

We want a clean slate to avoid state conflicts from previous sessions.

Prompt:

Check my Signadot setup, load the signadot-validate skill, and clean up anything from earlier runs.

Paste the prompt into Cursor Chat and send it. Cursor will use Signadot MCP tools to inspect your cluster, sandboxes, and devbox state.

Cursor prompt for Signadot setup check with skill Cursor response showing Signadot setup status and skill loaded

Prompt 2: Run & Verify​

Use the signadot-validate skill to create the sandbox, start the route service locally, and validate the HotROD application end-to-end. The skill handles sandbox creation automatically, so no separate step is required.

Prompt:

Follow the signadot-validate skill to debug the route service: create or reuse a local-dev sandbox called local-route-dev that maps hotrod/route (Deployment) port 8083 to localhost:8083, start the route service locally with the sandbox environment, then verify the HotROD application works correctly by confirming the driver is dispatched as expected via the cluster mesh.

Paste the prompt into Cursor Chat and send it.

Cursor prompt to start route service and verify with signadot-validate skill signadot-validate skill showing validation passed with driver dispatched via local route

Cursor will coordinate with the signadot-validate skill to run the full validation. You will see:

  1. A sandbox spec generated and applied (the skill handles this automatically).

  2. eval $(signadot sandbox get-env ...) to inject the cluster context into your shell. This requires Step 1 (signadot local connect) to be running.

  3. go run ./cmd/hotrod/main.go route (or equivalent) to start your local service.

  4. A grpcurl command against route.hotrod.svc:8083 with baggage and tracestate routing headers to prove keyed traffic reaches your local process, not localhost.

Step 4: Verification​

To prove the setup works, change the route service logic and see a different result on the next keyed request.

  1. Modify code: Open services/route/server.go and change the ETA calculation in FindRoute (for example, return a fixed short duration instead of the random minute-scale value). Save the file.

  2. Restart the local route process so the change is picked up (stop the previous go run or binary, then start it again with the same sandbox env).

  3. Verify: Send a keyed request through the cluster URL and confirm the response reflects your change.

Option A: The Header Method (Programmatic)​

Since the route service uses gRPC, use grpcurl (not curl) against the cluster service URL. Inject the sandbox routing key in both baggage and tracestate. That is what Signadot and the HotROD mesh expect.

Replace <YOUR_KEY> with the routing key from signadot sandbox get local-route-dev -o yaml:

grpcurl -plaintext \
  -H 'baggage: sd-routing-key=<YOUR_KEY>' \
  -H 'tracestate: sd-routing-key=<YOUR_KEY>' \
  -d '{"from": "37.7749,-122.4194", "to": "37.7849,-122.4094"}' \
  route.hotrod.svc:8083 \
  route.RoutesService/FindRoute

You should see a response that matches your local code change (for example, a much smaller etaSeconds value), proving keyed traffic hit your laptop, not the in-cluster baseline pod.

Quick debug shortcut

To confirm routing before editing code, you can start the local route with FAST_ROUTE=1 in the environment. Keyed grpcurl calls should then return "etaSeconds": 1 while unkeyed calls still return longer baseline ETAs.

Option B: Browser Extension (Visual)​

If you prefer a UI flow:

  1. Install the Signadot Chrome Extension.

  2. Log in and select your sandbox (local-route-dev) from the dropdown.

  3. Visit http://frontend.hotrod.svc:8080. The extension will automatically inject the routing headers.

Troubleshooting​

If you get stuck, check these common issues we identified during testing:

Connection Timed Out on .svc addresses

If curl http://frontend.hotrod.svc:8080 hangs or .svc resolves to an IP but times out, your machine is likely routing the default virtual IP range to your internet gateway. This is more common with Minikube when using VPNs or office Wi-Fi.

Fix: Edit ~/.signadot/config.yaml and change virtualIPNet to 198.18.0.1/16, then restart local connect.

Authentication Failed / Keyring Errors

If you see "Failed to unlock correct collection" or "No authentication found", you likely ran sudo signadot local connect.

Fix: Run signadot local connect as your normal user. Only provide the sudo password when the CLI prompts you for it.

Go Build Failures

If go run fails with package log/slog is not in GOROOT, your Go version is too old.

Fix: Install Go 1.21 or higher and ensure your $PATH lists the new Go version first.

Local connect is healthy but my local service gets no traffic

signadot local status shows the sandbox mapped, but your local process logs stay empty and grpcurl returns baseline-like results.

Check:

  1. signadot local status lists your sandbox with connection ready.

  2. signadot sandbox get <name> -o yaml shows tunnel.health.connected: true. If you see RoutingNotReady or DevMesh Sidecar absent, sidecars are missing on the baseline workload.

  3. HotROD app pods are 2/2 with containers hotrod,sd-sidecar. If they are 1/1, prompt Cursor:

    DevMesh sidecars are not injected on hotrod deployments. Fix routing readiness for my local sandbox.

  4. Your local service is listening on the mapped port (for this tutorial, 8083).

  5. You are calling the cluster URL (route.hotrod.svc:8083) with both routing headers, not localhost.

Conclusion​

In this tutorial, you have successfully replaced a complex workflow of YAML editing, port-forwarding, and manual config injection with a streamlined setup and natural language prompts. You learned how to:

  1. Configure and connect to the cluster with stable PortForwarding configuration.

  2. Install the signadot-validate skill to give Cursor's agent a repeatable validation loop against real cluster dependencies.

  3. Clean the environment using Cursor's AI agent.

  4. Create a routing sandbox that maps cluster services to your local machine.

  5. Inject cluster context into your local process and validate via the cluster mesh.

This workflow enables rapid iteration on microservice changes without the overhead of traditional port-forwarding or waiting for CI/CD pipelines.

See Also​