Repositories

Repositories give agents read access to your source code. Polylane indexes each repository for search, provisions a sandbox where agents can run the code, reviews pull requests for production impact, and places the repository on the topology next to the infrastructure it deploys to.

Connect a repository

Open Repositories in the console and choose one of two paths:

• Connect GitHub: installs the Polylane GitHub app on your organization. The install flow opens in your browser and lets you pick which repositories Polylane can read. Connected repositories stay in sync as code changes.
• Add repository: registers a public GitHub repository by URL, for example https://github.com/company/repo. Repositories added this way are not updated automatically when code changes, so prefer the GitHub app for anything you actively develop.

Use polylane to connect our GitHub organization and pick the repositories agents should be able to read. Walk me through the install flow.

See GitHub for app permissions and settings.

Indexing and search

Polylane splits each repository into chunks and indexes them twice: a full-text index for exact keyword matches, and vector embeddings for semantic search. Agents in threads, automations, and scans use both to find the code behind a symptom, for example searching "retry with exponential backoff" and landing on the right module even when those words never appear in the source.

The repository view

Each repository page has four tabs.

Sandbox

Agents run repository code inside a sandbox: a Docker image based on Ubuntu with common runtimes preinstalled, with the repository cloned to /workspace. The Sandbox tab configures it:

• Setup script: automatic dependency detection, or a manual bash script that runs after the clone. Network access is enabled during setup.
• Maintenance script: runs when a cached container resumes, after checking out the branch.
• Preinstalled packages: pin runtime versions available in the environment.
• Environment variables and secrets: variables are available during setup and agent execution. Secrets are encrypted, exposed only to the setup script, and removed before the agent runs.
• Container caching: caches the container state after setup so later runs start faster. A reset action clears the cached container.
• Agent internet access: off by default. When enabled, outbound requests are limited by a domain allowlist: none, a common dependencies preset covering package registries and language ecosystems, or all domains.

The Sandbox tab also controls pull request reviews for this repository: turn reviews on or off, add repository-specific review instructions, and post a "Polylane production impact" check that fails when the review finds a concern. Require that check in branch protection to block merging.

Observability

Polylane scans the repository for instrumentation gaps, such as route handlers that emit no logs or logging that relies on bare console calls. Each finding can be ignored, or handed to an agent to fix in a thread.

Changes

A history of pull request analyses for this repository. Polylane investigates every pull request against the production topology and comments with a pass or fail verdict. Failed analyses carry an impact level and are listed first; passed analyses sit in a collapsed list below. Dismiss an analysis to stop Polylane commenting on that pull request. See Change intelligence.

Properties

The raw repository record: identifiers, provider metadata, and sync state.

Repositories on the topology

Each repository appears on the topology as a node linked to the infrastructure it deploys to. Polylane reads deployment configuration in the repository, such as a Cloudflare Workers config, a Fly app config, a Vercel project config, or a Render blueprint, and draws deploys_to edges to the matching compute resources and defines edges to resources the configuration provisions. When an agent investigates an issue on a service, it follows these edges straight to the code that ships there.