Skip to main content

Managed vs Self-Hosted Agents

DevOps Genie's agent powers Terraform generation, Kubernetes deployment, CI/CD authoring, and cloud analysis. You choose how it runs when you set it up in Integrations → Deploy DevOps Genie Agent.

Two deployment modes​

Self-hosted (Helm)Managed by DevOps Genie
Where it runsYour Kubernetes clusterDevOps Genie's AWS infrastructure
SetupInstall our Helm chartClick "Managed", connect VCS, acknowledge data handling
Kubernetes requiredYesNo
Capability surfaceFullVCS / Terraform / cloud-read focused (see matrix below)
Best forTeams already on K8s; private-cluster workflowsPOCs, teams without K8s, VCS/IaC workflows

Data handling differences​

The most important difference is where your credentials live.

Self-hosted: your VCS and cloud credentials are mounted into the agent pod by your own Helm values and never leave your environment. DevOps Genie stores only agent registration, heartbeat, and readiness state.

Managed: DevOps Genie holds your credentials under audited controls:

  • Each conversation runs in its own isolated microVM (one Firecracker VM per conversation, own kernel, own network interface) that is destroyed when the conversation ends.
  • Credentials are stored per tenant with a dedicated encryption key and are readable only by your tenant's agent.
  • Durable output lives only in your own repositories — the agent commits to dg-agent/* branches and opens pull requests (GitOps). Your CI/CD pipeline applies the merge.
  • Managed mode stores read-only cloud credentials and git-write only. It never holds mutating cloud credentials, so it cannot run terraform apply or terraform destroy — your own pipeline applies merged changes.
  • On switching back to self-hosted (or churn), secrets are scheduled for deletion with a 7-day recovery window.

Managed mode currently runs in us-east-1 only. Teams with data-residency requirements outside us-east-1 should use self-hosted until a managed region in their geography is available.

Capability matrix​

CapabilityManaged runtime
Cloud Resource ScanningSupported
Compliance and Security AuditSupported
Terraform Code GenerationSupported
CI/CD Pipeline GenerationSupported
Cost Analysis and OptimizationSupported
Kubernetes Application DeploymentRequires self-hosted agent
Live cluster investigation (Prometheus / Loki)Requires self-hosted agent
Live infrastructure mutation (apply / destroy)Not offered

Cloud read/analysis works in managed mode against public cloud management-plane APIs using stored read-only credentials. It shows "requires self-hosted agent" only if you restrict your cloud API to private networks or IP ranges.

Live Kubernetes investigation (Prometheus, Loki, in-cluster kubectl) targets private in-cluster endpoints the managed runtime cannot reach, so it always requires a self-hosted agent.

Live infrastructure mutation (terraform apply / terraform destroy) is not offered in managed mode by design — the agent opens pull requests and your own pipeline applies the changes.

Usage and billing​

Managed agents are metered per tenant:

  • Compute — vCPU-hours consumed by your conversations.
  • LLM tokens — input and output tokens across your conversations.

Your current period's usage and estimated cost are shown in Settings → Agent runtime.

Managing your agent​

Settings → Agent runtime is the single place to see and manage your agent in either mode. It always shows the current state up front:

  • Managed — whether the agent is live, provisioning, tearing down, or failed, along with its region, tier, agent ID, and the repositories it's configured to work on. "Live" means the row is ready and the controller has sent a recent heartbeat — if it's provisioned but not connected, the page says so rather than claiming it's ready.
  • Self-hosted — how many agents are registered, how many are live, and the most recent heartbeat from your cluster.

Switching modes​

  • Self-hosted → Managed — connect your VCS, optionally add a read-only cloud role, acknowledge data handling, and provision. Setup completes when the controller connects (usually under a minute).
  • Managed → Self-hosted — reset the managed agent (see below) and follow the Helm install instructions to run the agent in your own cluster.

Editing your configuration​

For a managed agent, use Edit configuration to change what you submitted at setup without tearing anything down:

  • GitHub credential — rotate your PAT or GitHub App installation. Leave the field blank to keep the current credential.
  • Repositories — update your infrastructure and deployment repo URLs and subpaths. The change is re-applied to your running agent automatically, so new conversations pick up the new repos.

Resetting​

Reset & set up new agent stops the current managed agent, deletes its resources, and schedules secret deletion with a 7-day recovery window. Once teardown finishes, the setup form returns so you can provision a fresh agent.

Troubleshooting a session​

When a conversation does something unexpected, its telemetry — each task assignment and result, the capability used, the status, and how long each step took — is captured so the session can be reconstructed end-to-end.

Managed agents: because the agent runs on DevOps Genie's managed runtime, its logs and traces stream into our observability backend, keyed to the conversation. Credentials are never written to logs. If you need a session investigated, contact support with the conversation ID and the shared debug key lets us reconstruct it end-to-end. (An in-product session-debug view is on the roadmap.)

Self-hosted agents: because the agent runs in your cluster, DevOps Genie cannot read its logs. The session debug view instead shows kubectl logs guidance — run it against the agent pod in your namespace to inspect the session:

kubectl logs -l app=dg-platform-agent -n <your-namespace>

Every log line and event for a session carries a shared debug key (tenant_id, conversation_id, task_id, agent_id) so a single session can be reconstructed end-to-end across both managed and self-hosted deployments.