Temps v0.1.0: Unified Observe, Database Monitoring, Postgres HA, OIDC SSO, and AI Autofixer

Temps v0.1.0 ships the self-hosted observability stack that makes a six-tool SaaS bundle redundant: a unified timeline that merges request logs, OTel traces, errors, and revenue events; full metrics monitoring for your Postgres, Redis, MongoDB, and S3 services; Postgres HA clusters with pg_auto_failover and WAL-G physical backups; an optional ClickHouse backend that keeps traces and logs fast at millions of rows; OIDC single sign-on for the console; Vercel-style sticky PR preview comments; an AI Autofixer that turns an error group into a pull request; and a decoupled temps migrate step for zero-surprise upgrades — all in the same single Rust binary, all free to self-host.

TL;DR: v0.1.0 ships the Unified Observe page (requests, traces, errors, and revenue events on one timeline), full database monitoring for Postgres/Redis/MongoDB/S3 with alert rules, production-ready Postgres HA with pg_auto_failover and WAL-G physical backups, an opt-in ClickHouse backend for traces/metrics/logs at scale, OIDC single sign-on with any standards-compliant identity provider, Vercel-style sticky PR/MR preview comments, build concurrency limits, scale-to-zero preview environments, self-service password reset, an AI crawler analytics view (who's training on your site), an AI Autofixer that turns error groups into pull requests, password-based CLI login with multi-context support, a safe decoupled temps migrate upgrade flow, and five fixed Critical security issues. None of it requires a paid tier.

What's new in v0.1.0:

• Unified Observe page — requests, traces, errors, and revenue on one timeline
• Postgres HA clusters — pg_auto_failover + WAL-G, with one-click failover and restore
• AI Autofixer — turn an error group into a pull request
• OIDC single sign-on — log in with Keycloak, Okta, Auth0, Entra, or Google Workspace
• Vercel-style PR preview comments — sticky preview URL on every pull request
• Database monitoring for every service — Postgres, Redis, MongoDB, and S3 metrics with alerts
• ClickHouse backend (opt-in) — keep traces and logs fast at millions of rows
• AI crawler analytics — see who's training on your site
• Scale-to-zero preview environments — feature-branch previews that idle to zero
• Build limits — cap concurrent builds so deploys don't pin the host
• Self-service password reset + SMTP — forgot-password flow and any SMTP relay
• Better GitLab support — first-class GitLab alongside GitHub
• CLI password login + multi-context — log in once, switch between servers
• Internal DNS for HA databases — resolve *.temps.local inside containers
• Safer upgrades with temps migrate — decoupled, no-timeout migration step
• Security: five Critical issues fixed — and a longer hardening tail

What is Temps v0.1.0?

Temps is a self-hosted PaaS that replaces Vercel, PostHog/Plausible, FullStory, Sentry, Pingdom, managed databases, and transactional email with a single Rust binary. It is free to self-host (Apache 2.0), or available as Temps Cloud at approximately $6/mo (Hetzner cost + 30% margin, no per-seat fees, no bandwidth bills).

v0.1.0 is the release where the observability story — what happens after your code is in production — becomes complete enough for production use.

If you're new to the project, start with what Temps is and why we built it. Otherwise, here's an honest tour of what shipped — including what we're explicitly not trying to be.

What v0.1.0 is — and what it is not

Before the feature tour, the honest framing: Temps is a self-hosted PaaS with built-in observability for the apps you deploy on it. v0.1.0 makes that observability easier to use and adds first-class HA for managed databases.

It is not a Datadog replacement. We don't have a code-level profiler, k8s-fleet metrics, log analytics with anomaly detection, RUM at Datadog's depth, or a 700-integration catalog. If you run thousands of services across multiple clouds and need an APM, keep your APM.

But if you're an indie hacker, a 2-50 person team, or an enterprise group that wants the deploy → request → trace → error → revenue loop in one tool — without 6 SaaS bills — v0.1.0 is the version where that story starts feeling complete.

How v0.1.0 stacks up against Coolify and Dokploy

The other self-hosted PaaS options are the more interesting comparison, since they're free too. The short version: Temps and the others all do git-push deploys, automatic HTTPS, and one-click databases. Where v0.1.0 pulls ahead is the observability and database depth in the same binary.

Coolify has a wider service-template catalog and a larger, older community — if you want dozens of one-click templates, it leads there. But "built-in error tracking, analytics, session replay, and OTel traces, plus Postgres HA with automatic failover" is a combination neither Coolify nor Dokploy ships natively today. That's the v0.1.0 wedge. (Full head-to-head: Temps vs Coolify.)

The Unified Observe page

The flagship feature. Every project now has a /projects/:slug/observe route that merges four event streams into one time-ordered timeline:

• Requests (proxy logs) — sky gutter
• Traces (OTel spans) — violet gutter
• Errors (error events) — rose gutter
• Revenue (revenue events) — emerald gutter

The header is a row of sparklines, one per kind, over your selected time range. Click a sparkline to toggle that kind on or off. Below it is a console-style monospace stream with HH:mm:ss timestamps and a one-line summary per row. Clicking a row opens a side panel that renders entirely from the row payload — no follow-up fetch in the common case.

Three deliberate choices worth calling out:

1. Traces default OFF. They're a high-volume hypertable. Forcing them on by default would dominate the merged view for anyone with non-trivial OTel ingest. Opt in via the cockpit card.
2. Runtime logs are not in this view. Container logs would drown out business signal. They live on the dedicated Logs page.
3. Filter state lives in URL search params. Send a teammate a link to "errors + revenue, last 6 hours" and they see exactly what you see.

The whole thing is backed by a new temps-observability crate (verified at crates/temps-observability/) that runs four parallel queries and merges them by ts DESC. Heavy fields (stack frames, span attributes, headers) get truncated server-side with *_truncated flags so the panel can offer a "Show full" un-truncate fetch when needed.

Citation Capsule: Temps v0.1.0's Unified Observe page merges request logs, OTel traces, error events, and revenue events into a single time-ordered timeline backed by the temps-observability crate. Per-kind sparklines double as filter toggles, side panels render from row payloads (no follow-up fetch in the common case), and filter state lives in URL search params for shareable views.

Postgres HA clusters

The biggest piece of plumbing in this release. Temps already shipped clustered Postgres in 0.0.6, but 0.1.0 makes it operable from the UI: scale up, scale down, fail over, back up, restore.

What's new:

• Add Replica — a dedicated /storage/:id/members/add page (not a modal) with a 4-step provisioning timeline that polls every second until the new replica reaches done or failed.
• Remove — per-row trash button. Refuses to remove the monitor, the current primary, or anything that would drop the cluster below the 2-data-member quorum.
• Promote ↑ — runs pg_autoctl perform promotion inside the chosen container. The role reconciler refreshes role-aliased VIP DNS records on its next tick (≤30s), so app connections to <cluster>.temps.local follow the new primary without a restart.
• WAL-G physical backups — the gotempsh/postgres-ha:18-bookworm-walg image bakes WAL-G alongside pg_auto_failover. Backups go to S3, WAL streaming is continuous, and archive_command lives in postgresql.auto.conf so it survives failover.
• In-place restore — tears down every member, pre-seeds the new primary's pgdata via wal-g backup-fetch in a one-shot helper container, then re-runs cluster initialization. Same names, same ordinals, same FQDNs — connections via <cluster>.temps.local reconnect transparently. Single-host clusters only in this MVP.

Coolify and Dokploy don't ship this. Self-hosted Postgres HA with point-in-time recovery and a one-click failover button is the kind of feature most teams pay AWS RDS or Crunchy Bridge for.

The cluster uses pg_auto_failover for automatic failover: the monitor container runs pg_autoctl create monitor, each data node runs pg_autoctl create postgres and connects to the monitor FSM. Role-aliased VIP DNS records (primary.<svc>.temps.local, replica.<svc>.temps.local) update within the 30-second role-reconciler tick on every promotion, so app containers using standard Postgres client libraries reconnect without code changes.

Citation Capsule: Temps v0.1.0 HA clusters use the gotempsh/postgres-ha:18-bookworm-walg Docker image with pg_auto_failover for automatic failover and WAL-G for continuous WAL streaming to S3. The temps-dns-resolver crate serves *.temps.local DNS records so app containers reach primary.<svc>.temps.local without configuration changes after a promotion.

AI Autofixer

Open an error group. Click "Fix with AI." A sandboxed agent run kicks off, reads the stack trace, checks out your repo, makes a fix, opens a pull request.

That's the loop. The framework underneath it (temps-agents crate) supports two modes:

1. Autonomous — agents run on cron schedules. Configure once with a system prompt, max turns, and a provider (Claude CLI or OpenAI Codex). The AgentCronScheduler service (at crates/temps-agents/src/services/cron_scheduler.rs) fires runs without manual intervention.
2. Interactive (Autofixer) — two-phase flow: analyze → review → fix → review → PR. The UI is a split layout (error detail on the left, AI conversation on the right) with a workflow timeline and SSE streaming.

The same agent_runs table powers both cron-driven agents and one-shot Autofixer runs, so run history, log streaming, and PR creation all share one pipeline.

Honest caveat: this is a flagship feature and the framework is young. We've tested it heavily against github.com/dviejokfs/sandbox-test-nextjs (a deliberate-bug Next.js app), and the autonomous path is on a 38-commit branch we've been iterating on. Expect rough edges. Expect to want a human review on every PR. But the floor is "AI takes a first pass and surfaces a diff" rather than "you read a stack trace at 2am from scratch."

A standalone post on the Autofixer is in the queue.

OIDC single sign-on for the console

Teams asked for this for a year. v0.1.0 lets you log in to the Temps console with any standards-compliant OpenID Connect provider — Keycloak, Auth0, Okta, Authentik, Zitadel, Microsoft Entra (Azure AD), or Google Workspace. Configure the provider once in Settings → Auth, and a "Continue with [provider]" button appears on the login form.

The mechanics: a new temps-auth OIDC module (built on the openidconnect 4.x crate) handles discovery, PKCE code flow, nonce/state validation, userinfo, and just-in-time user provisioning. Role mappings let groups or claims from the IdP map straight onto Temps roles, so an Okta group can become a Temps admin without per-user setup. Local dev tooling ships under tools/keycloak-dev/ — a one-command Keycloak realm to test against.

Security was the hard part, and we took it seriously: Temps refuses to link or auto-provision an SSO account unless the IdP asserts email_verified: true, because an attacker who registers [email protected] at the IdP without verifying it could otherwise take over the victim's existing account on first SSO login. For corporate IdPs that simply don't emit the claim (Okta's Org Authorization Server is the canonical example), there's a per-provider trust_idp_email opt-out — and every bypass is logged so an auditor can see who enabled it and when.

This is the feature that takes Temps from "fine for a solo dev" to "deployable inside a company that mandates SSO." It's in the free, self-hosted binary — not gated behind a paid tier.

Citation Capsule: Temps v0.1.0 supports OpenID Connect single sign-on for the admin console with any standards-compliant IdP (Keycloak, Auth0, Okta, Authentik, Zitadel, Microsoft Entra, Google Workspace), built on the openidconnect 4.x crate with PKCE, just-in-time provisioning, and IdP-group-to-role mapping. The email_verified claim is required before account linking to prevent SSO account-takeover, with a per-provider opt-out for IdPs that omit the claim.

Vercel-style PR and MR preview comments

When a deployment for a branch with an open pull request (GitHub) or merge request (GitLab) moves through created → succeeded/failed → cancelled, Temps posts and updates a single sticky comment with the preview URL — exactly the workflow you'd expect from Vercel or Netlify.

The comment is keyed by a hidden HTML marker scoped per (project, environment), so subsequent deploys edit the same comment in place rather than spamming the PR with a new one each push. It updates on cancel too: a cancelled deployment flips the comment to "⛔ Preview deployment cancelled" instead of leaving it stuck on "🚧 Deploying."

It degrades gracefully — a missing git connection, no open PR, an unsupported provider, or a 403 from the provider all log quietly and never block the deploy. Works identically on GitHub (via the GitHub App's pull_requests:write scope) and GitLab (token with api scope).

This is table stakes for the git-push workflow, and now Temps has it on the same footing as a managed PaaS — self-hosted, on your own infrastructure.

CLI: password login and multi-context

bunx @temps-sdk/cli login <url> now authenticates with email + password (and TOTP MFA when enabled). No more minting an API key in the dashboard and pasting it into a terminal.

Under the hood, it hits a new POST /auth/cli/login endpoint that mints a 90-day API key scoped to your role. The previous /auth/login + cookie-scrape + /api/tokens flow is replaced — --api-key and --magic modes still work for CI and one-off setups.

temps context list | use | remove | current lets one workstation stay logged into multiple self-hosted Temps servers at once. Each context stores {name, url, apiKey, email, keyPrefix, expiresAt} in ~/.temps/.contexts.json (mode 0600). Environment variables (TEMPS_API_URL, TEMPS_API_TOKEN) still take precedence for CI.

temps logout calls POST /auth/cli/logout to revoke the API key on the server before clearing local credentials. --local-only skips the network call when the server is unreachable.

Internal DNS for HA databases

Cluster containers used to use Docker's embedded resolver (127.0.0.11), which doesn't know about the Temps registry. So *.temps.local always returned NXDOMAIN inside containers, breaking any HA Postgres app that wanted to reach primary.<svc>.temps.local.

v0.1.0 ships a new temps-dns-resolver crate (verified at crates/temps-dns-resolver/) that runs a per-node Hickory DNS resolver on the bridge gateway. The agent now sets HostConfig.dns = [<bridge>] on every container it creates, so containers resolve cluster FQDNs natively. Three tiers of records:

• Per-member A records — pg-1.<svc>.temps.local, pg-2.<svc>.temps.local
• Role-aliased VIPs — primary.<svc>.temps.local, replica.<svc>.temps.local, <svc>.temps.local (round-robin)
• Underlay fallback — when no overlay IP exists, points to the node's underlay address + host port

Public domains still resolve normally — the resolver forwards non-temps.local queries to Cloudflare and Google.

Database monitoring for every service

Deploying a database is easy. Knowing whether it's healthy at 3am is the hard part. v0.1.0 adds full metrics observability to every external service you run on Temps — Postgres, Redis, MongoDB, and RustFS/S3.

A new temps-metrics crate scrapes each enabled service into a TimescaleDB hypertable with hourly and daily continuous aggregates. Every service gets a monitoring page at /storage/:id/monitoring with hero stats, time-series charts (1h / 6h / 24h / 7d), categorized metric groups, and threshold-based alert rules.

What's collected per engine:

• PostgreSQL — 31 metrics, including a per-database breakdown (size, cache-hit, deadlocks, commits/rollbacks, temp files, tuple DML) plus instance-wide connections, locks, WAL, and replication. Connection counts now exclude engine background processes, so an idle pool reads "N connected" instead of a misleading 8-10 phantom backends.
• MongoDB — 32 metrics (uptime, page faults, asserts, queued reads/writes, WiredTiger cache pressure, replication-buffer pressure, cursor timeouts).
• Redis — 17 metrics (ops/sec, commands, network, evictions, keyspace hits/misses charted as a rate, not a raw counter).
• RustFS/S3 — cluster capacity, object counts, operations, and process stats, pushed over OTLP via a service-scoped si_ ingest key.

Sensible default alert rules are seeded per engine (MongoDB connection saturation, WiredTiger pressure, replication lag; RustFS offline nodes and low free capacity), and the evaluator back-seeds them on startup so a service enabled before its defaults existed self-heals. When an alarm fires, it now records which service breached, so the notification email says "Postgres orders-db" instead of just "Project 12".

Citation Capsule: Temps v0.1.0 monitors Postgres, Redis, MongoDB, and RustFS/S3 services natively via the temps-metrics crate — 31 Postgres metrics (with per-database breakdown), 32 for MongoDB, 17 for Redis, plus S3 cluster stats — scraped into TimescaleDB with continuous aggregates, per-service charts, and threshold alert rules. No separate Datadog or PMM agent required.

ClickHouse backend for traces, metrics, and logs (opt-in)

If you ingest serious OTel volume, the traces list eventually feels the weight of a GROUP BY trace_id over a hypertable with millions of spans. v0.1.0 adds an optional ClickHouse backend (ADR-016) for four observability domains: traces, resource metrics, proxy/request logs, and analytics events.

Set the TEMPS_CLICKHOUSE_* env vars and those domains route their reads and writes to ClickHouse ReplacingMergeTree tables instead of TimescaleDB. ClickHouse becomes the system of record for them; the Postgres-only path stays byte-identical when it's off (which is the default).

The numbers that matter: trace summaries via a query-time GROUP BY run in about 23ms at 400k traces. On the TimescaleDB path, a new otel_trace_summaries rollup table turns sort-by-duration from a sort-after-aggregate into an index scan — roughly 46x faster. Compression CODECs on the ClickHouse telemetry tables (Delta/DoubleDelta on timestamps, Gorilla on metric values, ZSTD on JSON) measured -52% on service_metrics and -34% on proxy_logs on real data.

Already have months of history in Postgres? temps backfill clickhouse --domain traces|proxy-logs|metrics|events|all copies it across — idempotent (re-runs dedup via ReplacingMergeTree), with keyset paging, a resume checkpoint, and a rate-limit throttle so you can backfill a live server without melting the primary.

This is genuinely optional. Most installs never need it. But "self-hosted observability that stays fast at millions of rows" is now a switch you can flip, not a migration to a different product.

AI crawler analytics: who's training on your site

ChatGPT, Claude, Perplexity, and Gemini crawlers hit your sites whether you invited them or not. v0.1.0 makes that traffic visible.

The AI Agents page (/analytics/ai-agents) is now a full overview, not two tables. An "AI agents over time" stacked bar chart plots crawler request volume per time bucket, split by provider or agent. Below it: Top Agents, Top Providers, Crawl Purpose (model training vs search indexing vs user fetch, from the AI taxonomy), Response Status (are crawlers getting 2xx, or hammering your 404s?), and Top Pages crawled.

There's also a per-project AI Crawlers feed under each project's Observe sidebar — a chronological stream of ClaudeBot / GPTBot / PerplexityBot requests hitting that project, newest first. It all reads from request logs flagged is_bot = true, so there's nothing to instrument.

If you care about how AI models see your product (we do, a lot), this is the first step: see who's actually reading you.

Scale-to-zero preview environments

Feature-branch previews are great until you're running twenty of them 24/7 on a single VPS. v0.1.0 adds a project-level setting that puts every newly auto-created preview environment into on-demand mode — it idles to zero when no traffic arrives and wakes on the next request.

Turn it on per project and set the idle timeout (default 5 minutes, 60s–24h) and wake timeout (default 30s, 5–120s). The first request after idle wakes the container in-process; subsequent requests are served normally. It only affects previews created after you flip the switch, so existing environments keep their current behavior. The result: feature-branch previews cost you nothing while nobody's looking at them — the kind of efficiency you'd otherwise pay a managed PaaS's per-deployment fees for.

Build limits: stop deploys from pinning the host

docker build used to run unbounded and could grab half the host's CPU and RAM per build — so three simultaneous deploys could effectively pin a busy box. v0.1.0 adds a process-wide build semaphore.

A new Settings → Infrastructure → Build Limits page exposes three knobs: max concurrent builds (default 2), per-build CPU cores, and per-build memory. When the limit is reached, additional builds queue with a [BUILD QUEUED] line in the build log rather than failing. Worker nodes skip the limit by design — each worker is dedicated hardware. Existing installs see no behavior change until an operator sets the caps, so it's safe on upgrade.

Self-service password reset and generic SMTP

Two friction-killers for self-hosted setups.

Self-service password reset now actually works end-to-end. There's a /forgot-password page (enumeration-safe — it always says "check your inbox") and an /auth/reset-password page that mirrors the backend's complexity rules with inline validation. The "Forgot password?" link only appears when an email provider is actually configured to deliver it. (As a bonus, we fixed a real bug here: reset links used to fan out to every notification channel — Slack, admin inboxes — instead of going to the user. They now route through a recipient-respecting transactional path.)

Generic SMTP provider joins AWS SES and Scaleway as a third email backend, for the very common "I only have SMTP credentials" case — AWS SES SMTP creds, Sendgrid, Mailgun, Postmark, self-hosted Postfix, or local Mailpit. STARTTLS, implicit TLS, and plain modes are supported, and loopback hosts auto-loosen TLS verification so local testing just works. You can now run the whole transactional-email story without an upstream provider's admin API.

Better GitLab support

Temps has supported GitLab for a while, but v0.1.0 polishes the edges: the project Git card shows the orange GitLab tanuki logo (not the GitHub Octocat) when a project is connected via GitLab, and the upstream-repo link is provider-aware so GitLab projects land on gitlab.com/<owner>/<repo> instead of GitHub. The sticky PR/MR preview comments described above work identically on GitLab merge requests. If you're on a self-hosted GitLab, Temps treats you as a first-class citizen.

Safer upgrades with temps migrate

Auto-applying migrations on boot is fine until a big migration on a large database blows past the startup window and wedges the whole server. v0.1.0 decouples it.

temps migrate applies pending migrations as an explicit step with the server stopped and no timeout. It prints the plan up front, applies each migration one at a time with a ✓/✗ line and timing, and stops cleanly on failure with a list of what didn't run. There's a --dry-run to preview and a --yes to skip the prompt in CI.

The recommended production upgrade flow is now: download the new binary, run temps migrate, restart the server. temps serve still auto-migrates on boot for simple installs, so nothing breaks for small setups. temps doctor reports pending migrations explicitly, and migrations now tolerate unknown applied rows (from a newer build or the Enterprise Edition) instead of refusing to start.

Security: five Critical issues fixed

We ran a hard security pass over the new surfaces this cycle and fixed five Critical-severity issues. Worth naming them plainly, because "trust us" isn't a security model:

• AI Gateway BYOK SSRF via a X-Provider-Base-URL header that could point the gateway at internal addresses.
• Agent run deployment tokens had wildcard scope and no revocation path.
• Git remote URL SSRF through libgit2 on clone.
• OIDC account-takeover via unverified-email account linking.
• pg_notify SQL injection in the deployment fan-out path.

Plus a longer tail: the metrics write path now validates metric names against an allowlist (not just the read path, which left attacker-controllable OTLP names as the weak link), si_ ingest tokens are rate-limited, IDOR gaps in the metrics handlers were closed (ownership checks return 404, not 403, so other tenants' resources aren't enumerable), container exec verifies tenant ownership, and filesystem path-traversal is rejected. Standard CVE dependency bumps too (aws-lc-sys, rustls-webpki, openssl, next, and others).

Full detail is in the changelog. If you run Temps in production, this is the release to be on.

Smaller things worth knowing

• Cross-source correlation columns — proxy_logs now carry trace_id and error_group_id, revenue_events carry deployment_id and trace_id, and error_events have a denormalized trace_id_indexed column for index speed. The Observe view uses these to jump from any event to its peers in the same trace.
• W3C traceparent extraction — the proxy parses inbound traceparent headers and stamps the trace_id onto proxy_logs.trace_id at write time.
• Faster console API startup — sandbox runtime image, RustFS, Redis, workspace adoption, and external plugin handshake all moved off the boot hot path. Ready time is now plugin DI + listener bind, regardless of how many external services or plugins you have.
• Email tracking analytics UI — event timeline on the email detail page with per-event IP, user-agent, and metadata. Aggregate dashboard at /emails/events/stats.
• Database pool tuning — TEMPS_DB_MAX_CONNECTIONS, TEMPS_DB_MIN_CONNECTIONS, TEMPS_DB_ACQUIRE_TIMEOUT, TEMPS_DB_IDLE_TIMEOUT for resource-constrained boxes.
• Container exec tenant isolation — the exec_command and container_terminal handlers now verify the container belongs to the requested project/environment before allowing access. Closes a cross-tenant exec gap.
• Path traversal protection — FilesystemStorage::resolve_path rejects keys containing .. components.
• CVE bumps — aws-lc-sys, rustls-webpki, tar, rkyv, openssl, aiohttp, next, protobufjs, and others. Full list in the changelog.

What v0.1.0 doesn't do

In the spirit of being honest:

• No APM-style code profiler. OTel traces, yes. Continuous profiling, no.
• No log query language. Logs are searchable by level + timeframe + free text. No DSL, no anomaly detection.
• No multi-region active-active database. HA is single-cluster, single-region.
• PITR is Postgres-only. The generic restore framework supports Redis, MongoDB, and S3, but point-in-time recovery is Postgres-specific in this release.
• Multi-host Postgres restore is refused with a clear message. The MVP is single-host. Multi-host needs an agent-side helper-container RPC that didn't make this cut.

Try it

# Self-hosted (Hetzner CPX22 or any 4GB+ box)
curl -sSL https://temps.sh/install.sh | bash

# Or sign up for Temps Cloud (~$6/mo, no per-seat fees)
# https://temps.sh

Upgrading from an earlier version on a large database? Use the new decoupled flow so a long migration can't wedge startup:

# 1. download the new binary, 2. apply migrations with no timeout, 3. restart
temps migrate --database-url="$DATABASE_URL" --dry-run   # preview first
temps migrate --database-url="$DATABASE_URL"
temps serve

The full changelog lives in CHANGELOG.md. If you hit anything weird, file an issue or join the Discord. We read everything.

FAQ

Is Temps v0.1.0 production-ready?

Yes for the deployment platform, request logging, error tracking, analytics, and now Postgres HA. The Autofixer is flagged as "production-ready UI across 8 surfaces, tests for 19/19 core services" but treat AI-generated PRs the same way you'd treat any junior contributor's PR.

How does Postgres HA on Temps compare to AWS RDS?

RDS handles more failure modes (multi-AZ, automated minor version upgrades, Performance Insights). Temps gives you pg_auto_failover + WAL-G + the management UI on infrastructure you own, at Hetzner prices. If you're regulated and need AWS, stay on RDS — but for most teams self-hosting on Hetzner, Temps closes most of the operational gap without the RDS bill.

Can the Unified Observe page replace Datadog?

For apps deployed on Temps, it covers the request-trace-error-revenue loop in one timeline — which is most of what small and mid-sized teams use Datadog for. It does not cover code profiling, k8s fleet metrics, log analytics at Datadog's depth, RUM, synthetic monitoring, or a large integration catalog. If those matter, keep Datadog.

Do I need ClickHouse to run Temps v0.1.0?

No. ClickHouse is opt-in. With TEMPS_CLICKHOUSE_* unset (the default), traces, metrics, and logs live in TimescaleDB exactly as before, and the new otel_trace_summaries rollup already makes the traces list fast on Postgres. Turn ClickHouse on only when you're storing millions of spans and want columnar query speed.

What can Temps database monitoring do that I'd otherwise pay for?

It scrapes Postgres, Redis, MongoDB, and RustFS/S3 into time-series charts with per-service alert rules and default thresholds, all on infrastructure you own. It covers the "is my database healthy, and tell me before it isn't" job that teams usually buy Datadog DB monitoring or Percona PMM for. It is not a query-plan analyzer or a full APM.

Does Temps support SSO?

Yes, as of v0.1.0. The console accepts login from any standards-compliant OpenID Connect identity provider — Keycloak, Auth0, Okta, Authentik, Zitadel, Microsoft Entra (Azure AD), and Google Workspace — with PKCE, just-in-time provisioning, and IdP-group-to-Temps-role mapping. It's in the free self-hosted binary, not a paid add-on. Configure it in Settings → Auth. Temps requires the IdP's email_verified claim before linking an account (to prevent SSO account-takeover), with a per-provider opt-out for IdPs that don't emit the claim.

Does Temps post preview URLs on pull requests like Vercel?

Yes. When a deployment runs for a branch with an open GitHub pull request or GitLab merge request, Temps posts a single sticky comment with the preview URL and updates it in place as the deployment succeeds, fails, or is cancelled — the same workflow as Vercel and Netlify, on your own infrastructure.

Do I have to upgrade to use the new features?

The Observe page, database monitoring, Postgres HA UI, OIDC SSO, sticky PR/MR preview comments, scale-to-zero previews, build limits, self-service password reset, AI crawler analytics, Autofixer, and CLI password login are all new in v0.1.0. On a large database, run temps migrate before restarting (see "Try it") so a long migration applies with no startup timeout. temps serve still auto-migrates for small installs.

Related: Read the v0.0.7 release recap | Unified observability timeline: requests, traces, errors, revenue | Postgres high availability with pg_auto_failover and WAL-G