Core · In-cluster execute

The fix runs where your workloads run — not in our VPC.

RemOps Agent installs with Helm, heartbeats to the API, pulls approved actions, executes them locally, and reports success or failure. That is the entire trust boundary in one sentence.

Install the agent See the agent loop

01 · Agent

Helm install. Heartbeat. Poll. Execute. Report.

Generate an agent install token in onboarding, install into your cluster, and confirm heartbeat. From then on, approved work leaves the SaaS as pending executions and returns as results — never as remote shell from our side.

  • POST /agent/register + periodic heartbeat
  • GET /agent/executions/pending pull model
  • POST /agent/executions/{id}/result closes the loop
helm · remops-agent
helm install remops-agent ./charts/remediation-agent \
  --namespace remops-system --create-namespace \
  --set platformUrl=https://api.remopsai.com \
  --set agentToken=••••••••
♥ heartbeat ok · polling pending executions
✓ action patch_configmap · success
✓ incident RESOLVED

02 · Action catalog

Kubernetes, cloud, and code actions your runbooks already name

Remediation plans map onto a catalog your agent can run locally — restarts, patches, rollbacks, scaling, and common cloud/code operations — without teaching RemOps your private SSH keys.

  • Kubernetes: restart, scale, patch, rollback, delete
  • AWS: targeted operational actions your packs support
  • GitHub: PR-oriented remediation paths
  • Chat / paging updates when you want humans notified
catalog · popular
k8s.rollout_restartdeployments · statefulsets
k8s.patch_configmapvalues · feature flags
k8s.scalereplicas · HPA nudge
k8s.rollbackrevision history
aws.ecs / rds opsscoped packs
github.revert_pathPR-oriented fixes

03 · Verify

Execution without verification is just hope

Plans include verification expectations — latency thresholds, error-rate windows, pod readiness. Results stream back onto the incident so “resolved” means measured, not assumed.

verification

Post-action checks

  • p99 payments.api < 300ms for 5m → pass
  • CrashLoop count == 0 → pass
  • Error rate < 0.5% → pass

RESOLVED 54s after approve

04 · Day-2 ops

Agent health is part of onboarding — not an afterthought

The onboarding checklist tracks agent registration and heartbeat so you know when full launch is real. Soft launch remains useful for intake → investigate → approve demos without cluster access.

  • Onboarding step for agent token + install
  • Heartbeat visibility in the checklist
  • Failed executions surface on the incident, not in a black hole
onboarding
✓ API keyintake ready
✓ Integrationsread-only connected
✓ Agent heartbeatonline 12s ago
✓ First executionfull launch unlocked

Shipping every week.

  • Helm agent chartInstall token → register → heartbeat.
  • Pending pull modelAgent fetches work; SaaS never pushes shell.
  • Result reportingSuccess/failure closes the incident loop.
  • Action catalogK8s-first packs with cloud/code extensions.

Frequently asked questions

In your Kubernetes cluster (or environment you control). It needs network access to api.remopsai.com for poll/report only.

No. Write access stays with the agent’s local identity and the packs you install beside it.

Soft: webhook → investigate → approve queues work. Full: agent connected and at least one real remediation executes and reports.

The incident can move to FAILED with the agent’s result payload. You keep the audit trail and can remediate manually or re-plan.

Yes for demos — agent can report simulated execution while you validate the control plane.

Finish the incident inside your network.

Install the agent when you are ready for full launch. Until then, soft launch still proves the loop.

Try RemOps free Talk to us →