# Projects

A project is one application you monitor. Errors, logs, traces, metrics and releases are all scoped to a project, and each project has its own keys.

## When to create a separate project

Create one project per deployable application, not per environment. Your staging and production builds should report into the same project and separate themselves with the `environment` field. That way an error you see in staging is recognised as the same issue when it reaches production.

- One project per app: web frontend, API, mobile app, worker.
- Environments (production, staging) are a field on each event, not a separate project.
- Quotas, members and alert rules apply per project.

## Creating one

Dashboard, then Org, then BugWatch, then **New project**. Two things matter:

- **Name**: use the name your team already calls the application. It appears in alerts, issue titles and deployment records, so it should be recognisable at a glance in a notification.
- **Environments**: list the environments this application runs in, typically production and staging. Events tag themselves with an environment, which is what lets you filter issues and hold alerts to production only.

Creating the project does not start collecting anything. You still need to install an SDK and paste in the project key. See [Install an SDK](/install-an-sdk) for servers and web, or [Mobile](/mobile) for Android, iOS, React Native and Flutter.

## Getting data in

A new project stays empty until an SDK sends its first event. The guided wizard in the dashboard generates a setup recipe for your exact language and framework, including the key to paste in. The same material, in full, is on the per-platform pages under [Install an SDK](/install-an-sdk) and [Mobile](/mobile).