Releases & Source Maps

Releases identify the deployed version of a service. Moneat detects release versions from normalized telemetry and uses them to correlate errors, traces, sessions, users, and source map artifacts.

The Releases dashboard is source-neutral. A release can be reported by:

• Sentry-compatible SDKs using the release field
• OpenTelemetry SDKs or Collectors using the service.version resource attribute
• Datadog tracers and the Datadog Agent using the version tag, usually from DD_VERSION
• CI/CD automation using the release API

Use one stable version string for the same deployed artifact across all sources. Common values are semantic versions, build numbers, or commit SHAs.

How release detection works

For service-scoped release views, the telemetry service identity must map to a Moneat service:

• For OTLP, set service.name and map observed services from Settings -> OTLP API Keys when needed.
• For Datadog, set DD_SERVICE to the Moneat service slug or service name.
• For Sentry-compatible SDKs, use the project DSN for the service receiving the telemetry.

Create releases from CI/CD

You can create releases before or after telemetry arrives. This is useful for deployment tracking, source maps, and release automation.

Release API

curl -X POST https://api.moneat.io/api/0/organizations/{org_slug}/releases/ \
  -H "Authorization: Bearer <auth_token>" \
  -H "Content-Type: application/json" \
  -d '{
    "version": "1.2.3",
    "projects": ["checkout-api"]
  }'

The endpoint is Sentry-compatible so existing release automation can migrate without changing payload shape.

Compatible sentry-cli client

export SENTRY_URL=https://api.moneat.io
export SENTRY_AUTH_TOKEN=<your_auth_token>
export SENTRY_ORG=<your_org_slug>

sentry-cli releases new 1.2.3
sentry-cli releases set-commits 1.2.3 --auto
sentry-cli releases finalize 1.2.3

Configure Sentry-compatible SDKs

Set release in the SDK initialization so errors, transactions, sessions, and replays are tagged with the deployed version.

Sentry.init({
  dsn: "https://<key>@api.moneat.io/api/<project_id>",
  release: process.env.RELEASE_VERSION || "1.2.3",
  environment: "production",
});

Configure OpenTelemetry and OTLP

Set the OpenTelemetry resource attributes that identify the service and deployment. Moneat reads service.version as the release version and deployment.environment.name as the environment.

export OTEL_SERVICE_NAME=checkout-api
export OTEL_RESOURCE_ATTRIBUTES="service.version=${RELEASE_VERSION},deployment.environment.name=production"

Send OTLP traces to Moneat with an OTLP API key:

POST https://api.moneat.io/v1/traces
Authorization: Bearer <OTLP_API_KEY>
Content-Type: application/x-protobuf

For an OpenTelemetry Collector, configure a Moneat OTLP HTTP exporter:

exporters:
  otlphttp/moneat:
    endpoint: https://api.moneat.io
    headers:
      Authorization: Bearer ${MONEAT_OTLP_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/moneat]

Create OTLP API keys from Settings -> OTLP API Keys. If the observed service.name does not already match a Moneat service, map it from the observed services table so release views can apply service filters correctly.

See also:

• OpenTelemetry service semantic conventions
• OpenTelemetry deployment attributes
• OpenTelemetry SDK environment variables

Configure the Datadog Agent and tracers

Moneat reads Datadog APM span versions from the Datadog version tag. In most Datadog tracer setups, set unified service tagging variables on the application process:

export DD_ENV=production
export DD_SERVICE=checkout-api
export DD_VERSION=${RELEASE_VERSION}

Then run the Datadog Agent pointed at Moneat as described in Datadog Agent setup. The application tracer sends spans to the local Agent, and the Agent forwards those spans to Moneat.

For Docker workloads, put the same tags on the application container:

environment:
  DD_ENV: production
  DD_SERVICE: checkout-api
  DD_VERSION: ${RELEASE_VERSION}
labels:
  com.datadoghq.tags.env: production
  com.datadoghq.tags.service: checkout-api
  com.datadoghq.tags.version: ${RELEASE_VERSION}

For Kubernetes workloads, use pod labels plus downward API environment variables:

metadata:
  labels:
    tags.datadoghq.com/env: production
    tags.datadoghq.com/service: checkout-api
    tags.datadoghq.com/version: "1.2.3"
spec:
  containers:
    - name: checkout-api
      env:
        - name: DD_ENV
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/env']
        - name: DD_SERVICE
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/service']
        - name: DD_VERSION
          valueFrom:
            fieldRef:
              fieldPath: metadata.labels['tags.datadoghq.com/version']

Use a DD_SERVICE value that matches the Moneat service slug or name. When the service resolves, Datadog trace versions appear in the same Releases dashboard as OTLP and Sentry-compatible telemetry.

See also:

• Datadog unified service tagging
• Datadog Agent environment variables

Source maps

Source maps make minified JavaScript stack traces readable. Upload source maps as part of the same release process and use the exact same release version that your telemetry reports.

Upload with sentry-cli

sentry-cli releases files 1.2.3 upload-sourcemaps ./dist \
  --url-prefix '~/static/js'

Upload with the API

curl -X POST https://api.moneat.io/api/0/projects/{org_slug}/{project_slug}/releases/1.2.3/files/ \
  -H "Authorization: Bearer <auth_token>" \
  -F file=@./dist/app.js.map \
  -F name="~/static/js/app.js.map"

Release dashboard

The Releases dashboard shows:

• Version - The release identifier reported by telemetry or CI/CD
• Signals - Versioned errors, transactions, and APM traces
• New issues - Error issues first seen in the release
• Crash-free rate - Available when session telemetry is present
• Users - Users observed in versioned event/session telemetry

Auth token scopes

API tokens used for release management need the following scopes:

• releases:write - Create and update releases
• releases:read - List and view releases
• sourcemaps:write - Upload source maps and artifact bundles

See API Tokens for how to create tokens with the right scopes.