/temps-best-practices

name: temps-best-practices
description: |
  Best-practices reference for preparing and instrumenting applications on Temps. Covers the app runtime contract (`.temps.yaml` health, HOST/PORT, readiness, SIGTERM, replicas, migrations) and production observability (errors, traces, metrics, logs, analytics, privacy, sampling, cardinality, credential boundaries). Use whenever building or reviewing an app for Temps, configuring health checks, adding telemetry, diagnosing missing/noisy signals, or checking OTLP/Sentry/analytics ingestion. Triggers include "temps best practices", "prepare this app for Temps", ".temps.yaml health", "temps health check", "ignore health checks in otel", "temps observability", "wire up telemetry", and "instrument this app for temps". Prefer focused setup skills for a single SDK. Use temps-cli for executing deploy and resource-management commands.

Temps Best Practices

Best practices for application code that runs on Temps. This skill owns the **runtime contract** and **production observability**; use `temps-cli` for platform operations.

Required workflow

1. For any deployable application, read [references/runtime-contract.md](references/runtime-contract.md). 2. When any telemetry or replay is enabled, read [references/telemetry-hygiene.md](references/telemetry-hygiene.md). 3. Read only the reference for each observability pillar in scope. 4. Determine the deployment source. For repository builds, inspect and merge `.temps.yaml`; for image/static deployments, inspect the deployment health-path override because no repository config is available. 5. Run the runtime and telemetry verification checklists before considering the work complete.

Runtime contract summary

Every web application should expose a dedicated health endpoint. Repository builds configure it in `.temps.yaml` under the project's effective Temps Root Directory / Docker build context:

health:
  path: /healthz

Use `health.path`; do not rely on the currently parsed-but-unapplied `status`, `interval`, `timeout`, or `retries` fields. If OpenTelemetry server tracing is enabled, exclude the exact health path from incoming spans and routine access-log/request-metric noise. Keep the route, `.temps.yaml`, and filters synchronized.

Image and static deployments cannot read `.temps.yaml`; set the same route through their deployment `health_check_path` / CLI `--health-check-path` override instead.

Also require the app to read `PORT`, bind to `HOST`/`0.0.0.0`, align a custom image's `EXPOSE`, handle `SIGTERM`, flush telemetry, and exit inside Temps' 10-second shutdown window. See the runtime reference for readiness semantics, scale-to-zero caveats, replicas, migrations, stdout/stderr, and cron authentication.

Observability

Temps replaces Sentry + Datadog/Honeycomb + PostHog with one ingestion surface. This section is the map across all five pillars — use it to decide *which* pillar a signal belongs in, and to find the concrete endpoint/auth/gotcha details for each. It complements, not replaces, the narrower setup skills:

• **add-error-tracking** — step-by-step Sentry SDK init per language/framework
• **add-react-analytics** — step-by-step `@temps-sdk/react-analytics` hook usage

Quickstart: wire up any app end to end

Goal: an app in any language gets runtime health, error tracking, and traces working safely.

**Temps auto-injects exporter destinations and credentials; it does not install or initialize an SDK.** Apps deployed through Temps receive these variables at Docker build time and container runtime, but application instrumentation still has to be installed, initialized, filtered, and verified:

| Env var | What it's for | Client-safe? | |---|---|---:| | `SENTRY_DSN` | Server-side/generic error-tracking DSN | Server by default | | `NEXT_PUBLIC_SENTRY_DSN` / `NUXT_PUBLIC_SENTRY_DSN` / `VITE_SENTRY_DSN` / `PUBLIC_SENTRY_DSN` / `REACT_APP_SENTRY_DSN` | Framework-specific public Sentry write key | Yes | | `SENTRY_RELEASE` | Commit SHA; leave `release` unset in `Sentry.init()` so the SDK reads it | Server/build metadata | | `OTEL_EXPORTER_OTLP_ENDPOINT`, `OTEL_EXPORTER_OTLP_PROTOCOL` | OTLP destination and `http/protobuf` protocol | Endpoint is non-secret | | `OTEL_EXPORTER_OTLP_HEADERS` | Deployment-token authorization for OTLP | **No — server only** | | `OTEL_SERVICE_NAME`, `OTEL_SERVICE_VERSION` | Stable service and release metadata | Non-secret |

Build-time availability does not make a server credential browser-safe. Never expose `OTEL_EXPORTER_OTLP_HEADERS`, `TEMPS_API_TOKEN`, `dt_`, or `tk_` through a public-prefixed variable or client bundle. Browser/mobile OTLP must use an authenticated backend or collector; see [references/telemetry-hygiene.md](references/telemetry-hygiene.md).

**This auto-injection is scoped to apps deployed *through* Temps.** It does not apply to: an app running elsewhere and only sending telemetry to a self-hosted Temps instance, or to Temps' own console/dashboard (which is built by its own CI, not through this deploy pipeline — self-referential, since Temps doesn't deploy itself as a project on itself). For those cases, get the real credential from the dashboard and wire it through whatever env var / build-arg / secrets mechanism that project's *own* build system already uses:

• Error tracking DSN: **Error Tracking → DSN & Setup** (`https://<public_key>@<temps-host>/<project_id>`)
• A server-side deployment token (`dt_...`) or API key (`tk_...`) for OTLP: **Project Settings → API Keys**

Never hardcode a token or endpoint into source, a Dockerfile, or CI config. Do not ask the user for a token so it can be committed. A Sentry DSN public key is designed for client writes, but should still come from the platform's supported configuration path.

Either way, the app-side steps are the same:

1. **Runtime**: apply [references/runtime-contract.md](references/runtime-contract.md). 2. **Hygiene**: establish credential boundaries, redaction, cardinali