# Environments and releases

Associate runtime evidence with the application version that produced it.


## Tag the runtime

Set `environment`, `release`, and `component` during SDK initialization. Keep the same release identifier in the deployed code and its uploaded source maps. Use a commit SHA or immutable build identifier.

```ts title="Release context"
import { init } from '@everock/sdk/node';
init({
  publicKey: process.env.EVEROCK_PUBLIC_KEY!,
  endpoint: process.env.EVEROCK_ENDPOINT!,
  environment: process.env.EVEROCK_ENVIRONMENT ?? 'production',
  release: process.env.EVEROCK_RELEASE,
  component: 'api',
});
```

## Report a deployment

After installing the SDK package, its release executable is available to your package manager:

```bash title="CI release report"
EVEROCK_RELEASE=$(git rev-parse HEAD) pnpm exec everock-release
```

Set `EVEROCK_PUBLIC_KEY`, `EVEROCK_ENDPOINT`, and optionally `EVEROCK_COMPONENT` and `EVEROCK_ENVIRONMENT` in the build environment. The reporter recognizes Vercel and Cloudflare Pages metadata; generic CI must supply a release identifier.

The Next.js and Vite build adapters can report releases as part of their build completion hooks when configured. Source-map upload additionally needs the secret upload key.

## Understand empty history

A release report describes a build/deployment. Runtime events describe actual usage. Reporting a release does not generate requests, replay, or user measurements. Environment and release views can be empty when the runtime has not delivered events for those labels.

See [source maps](/docs/features/source-maps) and [Home](/docs/platform/home).