{"slug": "eva-manage-coding-agents-inside-cloud-connected-repos", "title": "Eva: Manage coding agents inside cloud connected repos", "summary": "Eva is an open-source platform that manages coding agents inside cloud development environments connected to GitHub repositories, allowing users to run tasks like fixing tests or building features in isolated sandboxes. The tool provisions full environments where agents can execute shell commands, install dependencies, and open pull requests, with support for persistent workspaces and real-time collaboration. Eva is self-hosted, giving users full control over their data and infrastructure.", "body_md": "Manage coding agents inside cloud development environments connected to your repositories\n\n**Fully open source** under the [MIT License](/vvedantb/eva/blob/main/LICENSE).\n\nInstead of editing code locally or inside restricted LLM sandboxes, Eva provisions full development environments where agents can:\n\n• run shell commands • install dependencies • execute tests • build and preview apps • open pull requests\n\n```\nGitHub Repository\n        ↓\n       Eva\n        ↓\nCloud Sandbox (Daytona)\n        ↓\nAI Agent (Claude, Codex, opencode, Cursor)\n        ↓\nCode Changes → Diff → Pull Request → Preview\n```\n\n- Connect your GitHub repository\n- Build a sandbox snapshot with your dependencies\n- Run a task (e.g. “fix failing tests”)\n- Review the diff and open a pull request\n\nDescribe a bug or change and Eva spins up an isolated sandbox to execute it. Tasks run independently so you can launch multiple in parallel.\n\nPersistent cloud development environments with live previews where you and the agent collaborate in real time.\n\nStructured workflows for larger changes. Agents can plan, implement, and verify features across your codebase.\n\nStore PRDs, specs, and context that the agent references during tasks. Keep your requirements close to the work.\n\nRun your test suite in sandboxes automatically. Validate changes before they land without tying up local resources.\n\nAccess your connected databases (Convex, Supabase) directly from Claude. Query, inspect, and debug your data without leaving your AI workflow.\n\n**Frontend**: Vite, TanStack Router, React, Tailwind CSS** Backend**: Convex** Sandboxes**: Daytona SDK** Auth**: Clerk\n\n| App | Description |\n|---|---|\n`apps/web` |\nMain dashboard for managing repos, tasks, and sessions |\n`apps/chrome-extension` |\nBrowser extension for quick task execution |\n\nEva is self-hosted - there is no managed cloud version. You create your own Convex deployment, set up your own Clerk project, and run the app yourself. This gives you full control over your data and infrastructure.\n\n- Node.js 20+\n- pnpm\n- Convex account\n- Clerk account\n- Daytona account\n- GitHub account (for GitHub App)\n\n```\ngit clone https://github.com/your-org/eva.git\ncd eva\npnpm install\nnpx convex dev\n```\n\nFollow the prompts to create or link a Convex project. Note your deployment URL (e.g. `https://your-deployment.convex.cloud`\n\n).\n\n- Create a Clerk application at\n[clerk.com](https://clerk.com) - Note your\n**Publishable Key**(starts with`pk_`\n\n) - Note your\n**JWT Issuer Domain** from Clerk Dashboard → JWT Templates (e.g.`https://your-app.clerk.accounts.dev`\n\n)\n\n-\nGo to\n\n**GitHub Settings → Developer settings → GitHub Apps → New GitHub App** -\nConfigure:\n\n**Name**:`Eva (your-org)`\n\n**Homepage URL**: your Eva instance URL** Webhook URL**:`https://your-deployment.convex.site/api/github/webhook`\n\n**Webhook secret**: generate a random string (save for`GITHUB_WEBHOOK_SECRET`\n\n)\n\n-\n**Repository permissions**:- Contents: Read & write\n- Pull requests: Read & write\n- Issues: Read & write\n- Metadata: Read-only\n\n-\n**Subscribe to events**: Push, Pull request, Installation -\nClick\n\n**Create GitHub App** -\nAfter creation, note:\n\n**App ID**→`GITHUB_APP_ID`\n\n**Client ID**→`GITHUB_CLIENT_ID`\n\n**App slug**(from the public URL`github.com/apps/<slug>`\n\n) →`GITHUB_APP_SLUG`\n\n-\nGenerate:\n\n**Client secret**→`GITHUB_CLIENT_SECRET`\n\n**Private key**(.pem file) →`GITHUB_PRIVATE_KEY`\n\n-\n**Install the app** on your account/org -\nLook up the App's bot user ID — this is used as the git commit author email so commits are attributed to the bot on GitHub (App IDs and bot user IDs live in different namespaces):\n\n```\ncurl -s https://api.github.com/users/<slug>\\[bot\\] | jq .id\n# → Use for GITHUB_BOT_USER_ID\n# Generate 32-byte encryption key (hex)\nopenssl rand -hex 32\n# → Use for ENCRYPTION_KEY\n\n# Generate deploy key\nopenssl rand -hex 32\n# → Use for EVA_DEPLOY_KEY\n\n# Generate ES256 key pair for sandbox JWT\nopenssl ecparam -genkey -name prime256v1 -noout -out private.pem\nopenssl ec -in private.pem -pubout -out public.pem\n# Convert to JWK format (use online tool or jose CLI)\n# → SANDBOX_JWT_PRIVATE_KEY (full JWK with \"d\" parameter)\n# → SANDBOX_JWT_JWKS (JWKS with public key only)\nVITE_CONVEX_URL=https://your-deployment.convex.cloud\nVITE_CLERK_PUBLISHABLE_KEY=pk_test_...\n```\n\n**Required:**\n\n| Variable | Value |\n|---|---|\n`CLERK_JWT_ISSUER_DOMAIN` |\n`https://your-app.clerk.accounts.dev` |\n`ENCRYPTION_KEY` |\n64-char hex string from Step 5 |\n`EVA_DEPLOY_KEY` |\n64-char hex string from Step 5 |\n`GITHUB_APP_ID` |\nApp ID from GitHub App |\n`GITHUB_APP_SLUG` |\nApp slug from `github.com/apps/<slug>` |\n`GITHUB_BOT_USER_ID` |\nNumeric bot user ID (from Step 4 lookup) |\n`GITHUB_CLIENT_ID` |\nClient ID from GitHub App |\n`GITHUB_CLIENT_SECRET` |\nClient secret from GitHub App |\n`GITHUB_PRIVATE_KEY` |\nFull contents of `.pem` file |\n`GITHUB_WEBHOOK_SECRET` |\nRandom string from Step 4 |\n\n**Optional:**\n\n| Variable | Purpose |\n|---|---|\n`SANDBOX_JWT_PRIVATE_KEY` |\nES256 JWK for sandbox auth (JSON) |\n`SANDBOX_JWT_JWKS` |\nPublic JWKS for sandbox auth (JSON) |\n`MCP_BOOTSTRAP_SECRET` |\nSecret for MCP bootstrap API |\n`MCP_JWT_SECRET` |\nSecret for MCP JWT signing |\n`CLERK_SECRET_KEY` |\nClerk secret key (for MCP server) |\n`CLERK_PUBLISHABLE_KEY` |\nClerk publishable key (for MCP server) |\n\n**Git default branch (not an env var):** When a task has no `baseBranch`\n\nand the repo has no **Default base branch** (Eva **Settings → Config**), sandboxes and PRs use `staging`\n\n(`FALLBACK_GIT_BASE_BRANCH`\n\nin `@conductor/shared`\n\n). Team/repo **env vars** apply inside sandboxes only; they do not set the PR merge base.\n\nThe Daytona API key is stored as a **team or repo env var** in the dashboard (not as a Convex deployment env var).\n\n- Get your API key from\n[Daytona](https://app.daytona.io) - In Eva dashboard, go to\n**Team Settings → Environment Variables** - Add\n`DAYTONA_API_KEY`\n\nwith your key\n\n```\n# Terminal 1: Convex dev server\nnpx convex dev\n\n# Terminal 2: Web app\npnpm dev\n```\n\nOpen `http://localhost:5173`\n\nEva supports Convex and Supabase MCP connections. To add these, add your Convex URL and Supabase URL to the repo or team environment variables in the dashboard.\n\nEva runs agents inside Daytona sandboxes that boot from pre-built snapshots. Snapshots bundle the OS, system tooling, agent CLIs, your dependencies, and a clone of your repo so sandboxes start fast.\n\nEva builds snapshots itself from the backend — no GitHub Actions workflow is involved. When a build is triggered, `packages/backend/convex/snapshotActions.ts`\n\n(`buildSnapshotImage`\n\n):\n\n- Defines a Daytona image with all required tooling (see the list below)\n- Clones your repo at the configured branch using a GitHub installation token, then runs\n`pnpm install`\n\n- Runs any custom build commands you have configured\n- Pushes the built image to Daytona as a named snapshot, then warms Daytona's cache so the first sandbox starts fast\n\n`DAYTONA_API_KEY`\n\nis read from your team or repo environment variables (see Step 7) — not from a GitHub Actions secret.\n\nIn the Eva dashboard, open your repo's **Settings → Snapshots**:\n\n**Configuration**— set the snapshot name, the branch to clone (** Workflow Branch**, defaults to`main`\n\n), a rebuild**Schedule**(a cron expression or`manual`\n\n), and**Build Commands** that run after`pnpm install`\n\n.**Status**— click** Rebuild Now**to trigger a build on demand.** Builds**— watch progress and read build logs.** Config Files**— upload files (e.g. database seeds) to bake into the image.\n\nIf a snapshot is missing or in an error state, sandbox creation falls back to a default Daytona snapshot plus a fresh `git clone`\n\n, so tasks still run (slower on first setup).\n\n- Node.js 20, pnpm, git, git-lfs, curl, jq, ripgrep, fd, gh CLI\n- Chrome + Xvfb + VNC (for browser automation and desktop/preview mode)\n- Docker Engine (for nested containers, e.g.\n`supabase start`\n\n) - Agent CLIs: Claude Code, Codex, opencode, Cursor\n- agent-browser, Convex CLI, Supabase CLI, code-server (VS Code in the browser)\n\nTo change the base tooling, edit `buildSnapshotImage()`\n\nin `packages/backend/convex/snapshotActions.ts`\n\n. For per-project needs, prefer **Build Commands** and **Config Files** in the Snapshots settings over editing the image definition.\n\nRebuild your snapshot when:\n\n- Dependencies change significantly (new major packages)\n- You update the base tooling (Node.js version, system packages)\n- You want sandboxes to start with a fresher copy of the codebase\n\nYour codebase needs the `agent-browser`\n\nskill installed for screenshots or video walkthroughs to be captured.\n\nYou may face authentication issues in the preview URL if your auth provider blocks frame ancestors (e.g. AuthKit does this for security). Options:\n\n**Open in a new tab**— simplest fix.** Add the Daytona domain**to your auth provider's allowlist and callback URLs, then use the preview URL directly.** Implement backend auth**— if you want the iframe to work, implement a separate login page that doesn't make network requests to your auth provider (e.g. AuthKit), so it renders inside the iframe. Add instructions to your`CLAUDE.md`\n\nso the agent knows how to use this flow with`agent-browser`\n\n.\n\nThis restriction is not unique to Eva — it's a standard iframe security limitation.\n\n- Testing arena for running and comparing agent strategies\n- Improved project interview UI/UX", "url": "https://wpnews.pro/news/eva-manage-coding-agents-inside-cloud-connected-repos", "canonical_source": "https://github.com/vvedantb/eva", "published_at": "2026-07-11 20:02:31+00:00", "updated_at": "2026-07-11 20:35:28.390704+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Eva", "GitHub", "Daytona", "Convex", "Clerk", "Claude", "Codex", "Cursor"], "alternates": {"html": "https://wpnews.pro/news/eva-manage-coding-agents-inside-cloud-connected-repos", "markdown": "https://wpnews.pro/news/eva-manage-coding-agents-inside-cloud-connected-repos.md", "text": "https://wpnews.pro/news/eva-manage-coding-agents-inside-cloud-connected-repos.txt", "jsonld": "https://wpnews.pro/news/eva-manage-coding-agents-inside-cloud-connected-repos.jsonld"}}