# Projects and components

Connect multiple applications and repositories to one shared project.


[Illustration: components]

## Choose the boundary

A project groups one product's evidence. Components identify the applications that produce it: for example, `web`, `api`, and `jobs`. Repositories can be separate GitHub repos or directories inside one monorepo.

| Concept | What it identifies |
| --- | --- |
| Project | The product and its shared investigation context |
| Component | One application or service in that product |
| Repository | The source location and branch |
| Environment | Production, staging, development, or another runtime label |
| Release | The deployed version that produced an event |

## Add an application

Reuse the existing project, register a component, and install the SDK in that component's actual runtime. Your agent can use `list_project_components`, `create_project_component`, and `get_component_setup` through MCP.

```ts title="API instrumentation"
import { init } from '@everock/sdk/node';
init({
  publicKey: process.env.EVEROCK_PUBLIC_KEY!,
  endpoint: process.env.EVEROCK_ENDPOINT!,
  component: 'api',
  serviceName: 'Public API',
  environment: 'production',
});
```

## Keep identities consistent

Use the same component slug in SDK initialization, release reporting, source-map uploads, and repository configuration. The display name can be friendly; the slug is the correlation identity.

An incident's component tells the agent which repository or monorepo directory to inspect. Connecting several repositories does not merge their source trees or automatically collect their runtime traffic.

See [GitHub](/docs/agents/github), [releases](/docs/features/releases), and [requests and endpoints](/docs/features/requests).