Data Ownership & Privacy

When you self-host Temps, every byte of your data — analytics events, error reports, session recordings, database backups, application logs — stays on your infrastructure. None of it is sent to Temps (the company), third-party analytics services, or any external server. The only thing the binary reports is anonymous product telemetry — event names, counts, and coarse internal labels under a random instance ID. Set TEMPS_TELEMETRY=0 and nothing is sent.

---

Your server, your data

Temps is a binary you run on your own server. It stores data in a PostgreSQL database (with TimescaleDB extension) running on that same server. There is no cloud backend, and none of your data — analytics, recordings, errors, logs, backups, credentials — ever leaves your infrastructure. The binary does send anonymous product telemetry (event names and counts under a random instance ID, disable with TEMPS_TELEMETRY=0), described in full below.

This means:

• You control the storage and deletion boundary — product-defined retention windows apply by data type, while the underlying data stays on infrastructure you control
• You control access — only people you grant access to can see your data
• You control location — host in the EU, the US, or anywhere that suits your compliance requirements
• You control deletion — delete data permanently at any time

If you stop using Temps, your data stays on your server. There is no export step, no data request process, and no 30-day deletion window.

---

What data Temps stores

All data lives in one PostgreSQL database:

Where data does NOT go

• None of your data (analytics events, recordings, error reports, logs, backups, user accounts, credentials) is ever sent to temps.sh or any Temps-operated server
• No data is sent to Google, Facebook, or any advertising network
• No data is shared with analytics aggregators
• The temps upgrade command checks GitHub for new releases (a public API call with no user data)
• The binary sends anonymous product telemetry to telemetry.temps.sh — event names, counts, and coarse labels only, detailed below. Set TEMPS_TELEMETRY=0 and nothing is sent.

---

Anonymous product telemetry

Temps reports anonymous usage events so the maintainers can tell whether the product actually works for self-hosters (e.g. "how many instances attempted a deploy vs. succeeded"). Every event carries only:

• A random instance ID generated on your server (~/.temps/anonymous_id) — not derived from your hardware, domain, or account
• The event name (e.g. deploy_succeeded, instance_heartbeat) and the Temps version
• A small bag of non-identifying properties: counts, enum labels (build preset, source type), and coarse buckets (RAM tier — never exact specs)

What is never sent: emails, IPs, repo names, domains, URLs, environment variables, error messages, stack traces, file paths from your projects, or any free-form user text.

Error summary

To find and fix bugs that only appear on self-hosted instances, Temps periodically (every 6 hours, only if something went wrong) sends one aggregated error_summary event containing counts of:

• ERROR-level log events, keyed by the Temps source module that logged them
• Console-API 5xx responses, keyed by route template (/api/projects/{id} — never the actual URL you requested)
• Panics, keyed by source file and line in the Temps codebase

Every key is a compile-time identifier of Temps's own code. The error messages themselves — which can contain your project names, paths, and IDs — are never transmitted.

Opting out

Set TEMPS_TELEMETRY=0 (also accepts false, off, no, disabled) in the server's environment and restart. Nothing is sent while opted out — no events, no error summaries. Two things still happen locally: the instance ID file is created (so re-enabling later doesn't churn identity), and error counts are tallied in a small fixed-size in-process buffer that is never read or transmitted while opted out.

---

Encryption at rest

Sensitive values are encrypted before being stored in the database:

• Managed service credentials (PostgreSQL passwords, Redis passwords, S3 keys) — encrypted with AES-256-GCM using a key stored at ~/.temps/encryption_key
• S3 backup credentials — encrypted with the same key
• Session cookies — encrypted with a separate cookie secret

The encryption key is generated during temps setup and stored on the filesystem. Anyone with access to both the database and the encryption key can decrypt credentials. Protect the ~/.temps/ directory accordingly.

API responses always mask sensitive values with ***. The dashboard never shows raw passwords or API keys after initial creation.

---

Privacy by design

Analytics

Temps analytics are designed to be useful without being invasive:

• First-party cookies only — The Temps proxy identifies visitors with two HttpOnly, SameSite=Lax cookies on your own domain: _temps_visitor_id (an encrypted random visitor ID, kept for 12 months) and _temps_sid (a session ID that expires after 30 minutes without activity). No third-party cookies are set, and the cookie values are never sent anywhere but your own server. Depending on your jurisdiction, these cookies may need visitor consent — see GDPR and compliance.
• No cross-site tracking — Each project's analytics are independent. There is no mechanism to track users across different projects or sites.
• No personal data collection by default — Analytics capture country (from IP via a local GeoLite2 database), browser, OS, referrer, and page path. No names, emails, or account IDs are collected unless your app attaches them to a visitor with the enrichment API.
• IP geolocation is local — The GeoLite2 database is downloaded during setup and runs entirely on your server. IP addresses are not sent to any external service for resolution.

Session replay

Session recordings capture DOM state, not raw user input:

• Password fields are always masked — regardless of configuration
• maskAllInputs option — when enabled, all form input values are replaced with asterisks
• blockClass option — add a CSS class to any element to hide it completely from recordings
• Sample rate — control what percentage of sessions are recorded (e.g. 10%)
• Recordings stay on your server — they are stored in your PostgreSQL database and never transmitted externally

Error tracking

Error reports capture stack traces and browser context. The Sentry-compatible client sends data to your Temps instance over your own domain (via the /api/_temps proxy path), so:

• No data goes to sentry.io or any external error tracking service
• Error reports are not shared with anyone
• Source maps are uploaded to your server for server-side symbolication

---

GDPR and compliance

Self-hosting Temps simplifies compliance because you are both the data controller and the data processor. There is no third-party processor to evaluate or sign a DPA with.

GDPR considerations:

• Lawful basis and consent — Temps analytics sets first-party cookies (_temps_visitor_id, _temps_sid). Under the ePrivacy Directive, storing a cookie that isn't strictly necessary generally requires consent in the EU, even when the data never leaves your server. Consult your legal advisor for your specific case.
• Data minimization — Temps collects minimal data by default (no names or emails, first-party cookies only, no cross-site tracking)
• Right to erasure — You have full database access. Delete any data at any time with SQL.
• Data location — Host in the EU to keep data within EU borders.
• Data portability — All data is in standard PostgreSQL. Export with pg_dump.
• No sub-processors — Self-hosted means no data flows to external services (except the S3 provider you choose for backups, which you control)

SOC 2, HIPAA, and other frameworks:

Self-hosting gives you full control over the security posture. You manage:

• Server hardening and access controls
• Network security and firewall rules
• Encryption at rest and in transit
• Audit logging (Temps includes a built-in audit log for all write operations)
• Backup and disaster recovery

---

What Temps does not do

To be explicit about what Temps does not handle for you:

• Server security — You are responsible for OS updates, firewall configuration, SSH hardening, and access controls on the server itself
• Database backups to a separate location — Temps can back up to S3, but you must configure the S3 storage. Without it, backups only exist on the same server as the data.
• Disk encryption — Temps encrypts sensitive fields in the database but does not encrypt the entire disk. Use your cloud provider's disk encryption or LUKS if you need full-disk encryption.
• DDoS protection — Temps does not include DDoS mitigation. Use Cloudflare, AWS Shield, or your provider's DDoS protection if needed.