Temps: A Self-Hosted Rust Binary That Bundles Deployment, Error Tracking, Analytics and an AI Gateway
AI-native open-source alternative to Vercel + Sentry + PostHog + Pingdom + Resend + E2B. 440+ CLI operations with drop-in skills for Claude Code, Codex & OpenCode — deployments, analytics, session replay, error tracking, OpenTelemetry, email, sandboxes & AI gateway in one self-hosted Rust binary.
At a glance
- What is it?
- Temps is an Apache-2.0 Rust platform that folds deployment, Sentry-compatible error tracking, PostHog-style analytics, uptime checks, transactional email, OpenTelemetry and Firecracker sandboxes into one self-hosted service, with a CLI surface an agent can drive. The scope is the risk: it is nightly-only and each bundled tool is thinner than the product it replaces.
- Who is it for?
- Adopt Temps if you are already running your own infrastructure, want deployment plus telemetry in one place, and are willing to run nightly builds and read the source when the docs run out. Do not adopt it if you need a stable release channel, a compliance paper trail, or a managed SLA, because the only published releases are dated nightly tags.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Seven Subscriptions Temps Is Trying to Replace
The README frames the project with a single claim: stop paying for Vercel, Sentry, PostHog, Pingdom, Resend, E2B and Datadog, and run one self-hosted binary instead. That framing is the honest description of the problem it solves. A small team shipping a web product typically ends up with a deployment platform, an error tracker, a product analytics tool, an uptime checker, a transactional email provider, a sandbox service for running untrusted code, and an observability backend. Each has its own account, its own bill, its own API key rotation, and its own data residency story. Temps puts all of them behind one dashboard and one CLI.
The audience is narrower than that pitch suggests. This is for engineers who already run their own servers and are comfortable with Docker, TLS certificates and Postgres. Someone who wants a managed platform with a support contract is not the target, and the nightly-only release channel makes that explicit. The pitch is consolidation for people who were going to self-host anyway, not a migration path for teams that never wanted to run infrastructure.
One Binary, Many Subsystems, and a CLI That Mirrors the Dashboard
The architectural claim in the README is that every operation available in the dashboard is also a CLI command, and it puts the count at 440+ operations across 69 groups. The examples given are `bunx @temps-sdk/cli projects list`, `bunx @temps-sdk/cli deploy my-app --environment production`, and `bunx @temps-sdk/cli analytics ai-agents -p my-app --period 7d`. That third one is worth reading closely: it queries analytics for AI-agent traffic specifically, which implies the request log layer classifies crawler and agent traffic rather than just recording a user agent string.
The proxy layer is built on Cloudflare's Pingora with automatic TLS through Let's Encrypt using both HTTP-01 and DNS-01 challenges. Request logs capture method, path, status, response time and routing metadata. Error tracking is Sentry-compatible at the DSN level, which is the mechanism that matters: you point the official Sentry SDK at a Temps DSN rather than swapping to a Temps client library. OpenTelemetry ingestion accepts any OTLP exporter, so traces, metrics and structured logs arrive over the standard protocol. The README states that this removes the need to run Grafana, Prometheus, Jaeger or Loki alongside it.
Sandboxes use Firecracker microVMs, which the README contrasts against container-based isolation. The feature section describing this is truncated in the material available, so the specific host requirements and the networking model for those microVMs cannot be confirmed from what is published here.
Installing Temps and Wiring Your First Project
The documented install path is a single shell command: `curl -fsSL https://temps.sh/deploy.sh | bash`. Piping a remote script into bash is a decision you should make deliberately on a host that will hold your production traffic and your error data. The README does not describe what the script does beyond running it, so read it before executing if the host matters.
Project setup happens through the dashboard. The README shows importing a public repository, with framework presets auto-detected before deploy. The CLI equivalent is `bunx @temps-sdk/cli deploy my-app --environment production`, where the environment is passed as a flag rather than inferred. Day-to-day inspection uses commands like `bunx @temps-sdk/cli projects list` and the analytics query shown above with its `-p` project flag and `--period` window.
For agent integration, the repository ships a `skills/` directory intended to be dropped into harnesses that read `.claude/skills/`, which the README names as Claude Code, Codex and OpenCode. Email setup is UI-driven: you add a sender domain and the DKIM records through the dashboard, then send through `@temps-sdk/node-sdk`, or configure AWS SES, Scaleway, or any SMTP relay as the provider instead. AI gateway configuration is bring-your-own-key for OpenAI, Anthropic, xAI and Google Gemini, exposed behind an OpenAI-compatible endpoint so you change the base URL and keep your existing SDK. The README states those keys are encrypted on your server.
Where the Bundled Tools Are Thinner Than the Products They Replace
Consolidation always costs depth, and the README's own feature list makes the trade visible. Error tracking is described as error groups, stack traces with source context, and alerts. That is the core of Sentry. It is not the whole of Sentry: no mention of release health, performance monitoring tied to errors, or the wider integration surface. If your workflow depends on those, Temps will feel like a downgrade even though the SDK drop-in works.
The OpenTelemetry section is the one to scrutinize hardest. Ingesting OTLP traces, metrics and logs is the easy half. The hard half is retention, cardinality control, sampling strategy, and query performance over months of data. The README says alerts fire off metrics and land in one queue you can acknowledge or resolve. It does not describe retention policy, downsampling, or storage sizing. Running this instead of Prometheus and Loki moves the operational burden from operating those systems to operating Temps and trusting its storage decisions, and the material gives you no basis to judge those decisions.
The analytics claim is the boldest: web analytics with funnels, visitor tracking and rrweb session replay, described as something no other self-hosted PaaS has. Session replay is high-volume, privacy-sensitive data. The README does not describe masking controls, retention limits, or how replay data is stored. Treat that gap as something to verify before you enable it on real user traffic.
The nightly release channel is a limitation in itself. Every release listed is a `v0.1.0-nightly` tag with a date and commit hash. There is no stable version to pin to, which means upgrades are a continuous commitment rather than a scheduled event.
How Temps Differs From Coolify and From Running the Originals
Coolify is the closest comparison, and the topics list on the repository names it directly as an alternative. The difference is scope. Coolify is a deployment and server-management layer: it deploys your applications and manages the hosts they run on. Temps deploys applications and then also ingests the telemetry those applications produce. Error events, OTLP spans, analytics hits and proxy request logs all land in the same system that did the deploy. That correlation is the actual product. Being able to move from a failing deployment to the traces and error groups from that same window, in one dashboard, is a workflow Coolify does not attempt.
The other alternative is running the originals: Vercel or Coolify for deploys, Sentry for errors, PostHog for analytics, Prometheus and Grafana for metrics, Resend for email. Each of those is more mature in its own domain, and several offer managed hosting so you carry no operational load. The trade is seven bills, seven sets of credentials, and data spread across seven vendors. Temps wins on operational surface area and data locality. It loses on depth per tool and on the maturity that comes from a project having stable releases. Choose based on which of those two costs you feel more acutely.
AI Chat, Agent Sandboxes and the Read-Only Default
Two AI features are described, and they are different in kind. The AI gateway is infrastructure: provider keys behind one OpenAI-compatible endpoint, with per-request attribution of tokens, latency, error rate and estimated cost per model. That is a proxy with accounting, and the value is obvious if you call multiple providers and want one place to see spend.
AI chat is grounded in your own telemetry. The README says answers come from your traces, metrics, alarms, deployments and revenue rather than a model guess, and that the assistant is read-only by default with write actions opt-in. Even when writes are enabled, the README states the assistant proposes the change and waits for confirmation. That default is the right call for a tool holding production credentials, and it is worth noting because the opposite default is common.
Workflow sandboxes run Claude Code, Codex or OpenCode against your repository, with platform skills and MCP servers injected. Combined with the Firecracker isolation claim, this is the part of the project with the least published detail. Running an autonomous coding agent against a repository, on infrastructure that also holds your deployment credentials, is a trust decision the README does not give you enough information to make.
Licence, Upgrade Cadence and What Maintenance Actually Costs
Temps is Apache-2.0. That permits commercial use, modification and redistribution, and it includes an explicit patent grant. It does not impose copyleft obligations on your own code, and it does not restrict you from offering Temps as part of a hosted service. If you modify and redistribute the binary, the licence requires you to preserve notices and state changes. This is a summary of the licence text, not legal advice; read the LICENSE file in the repository for the terms that bind you.
The maintenance cost is the part the README understates. There is no stable release to track. Releases arrive nightly, tagged with a date and a commit hash, and the most recent three span consecutive days. That cadence means bug fixes land quickly but so do regressions, and there is no version you can sit on while you decide. If you deploy Temps, you are signing up to read changelogs and test upgrades on a schedule you set yourself, because the project does not set one for you. The upgrade path itself is not documented in the material available: whether database migrations run automatically, whether the deploy script handles upgrades or only fresh installs, and whether a rollback between two nightly tags is supported are all open questions. Answer those before you put production data in it.
Editorial conclusion
Adopt Temps if you are already running your own infrastructure, want deployment plus telemetry in one place, and are willing to run nightly builds and read the source when the docs run out. Do not adopt it if you need a stable release channel, a compliance paper trail, or a managed SLA, because the only published releases are dated nightly tags. Before committing, verify three things on a disposable host: that your Sentry SDK version actually delivers events to a Temps DSN, that the Firecracker sandbox path works on your hardware (the README's feature section is truncated mid-sentence, so the isolation requirements are not documented in the material available), and that your Postgres and object storage survive an upgrade between two nightly tags.
Community notes