temps bundles a PaaS into one Rust binary, and its install is a piped script

The install command pipes a remote script into a shell

The whole install is one line, given before anything else on the page:

curl -fsSL https://temps.sh/deploy.sh | bash

There is no package manager step, no checksum, and no way to read what will run before it runs. That makes the project's own build file worth reading next, because it takes the opposite position about the same class of action. The Dockerfile installs a pinned Bun archive and says so in a comment: it verifies the download before execution and avoids piping a mutable remote installer into a shell inside the release build. It goes further than most: `ARG BUN_VERSION=1.3.14` and a checksum variable whose value is a twelve character prefix, `BUN_LINUX_X64_MUSL_SHA256=14bd9aedeebf`. So the same repository that treats a fetched installer as a supply chain risk ships a user-facing install that fetches a script from a domain rather than from the repository. Reading the script before running it is the difference between the two positions.

Firecracker is the pitch, Docker is the default

The sandbox section leads with hardware-level isolation and Firecracker microVMs, the technology behind AWS Lambda, and states that untrusted agent-generated code never shares a kernel with the host because each microVM gets its own kernel. Two sentences later the default is named, and it is not Firecracker: sandboxes run on a Docker backend by default, and `temps firecracker setup` is the command that routes them to microVMs instead. Both statements can be true at once, since a container shares the host kernel and a microVM does not, but the order of the page puts the stronger claim first. The SDK mirrors an existing shape, `@temps-sdk/sandbox` is compatible with the `@vercel/sandbox` form, so switching providers is a change of import and base URL:

import { Sandbox } from '@temps-sdk/sandbox'

const sandbox = await Sandbox.create({
  source: { type: 'git', url: 'https://github.com/example/repo.git', revision: 'main' },
})

const { stdout } = await sandbox.exec(['npm', 'test'])
const url = sandbox.domain(3000) // live preview of a dev server inside the VM

Each sandbox also gets a shell, a preview URL template for any port it binds, and a timeline of what happened to it, and the page compares the cost to what E2B, Daytona or Vercel Sandbox would charge.

Preview URLs can be locked behind a generated password

Sharing a running branch without publishing it is handled by giving a sandbox port a password, and the two commands that do it are worth keeping straight:

bunx @temps-sdk/cli sandbox password sbx_abc123 --rotate --length 32
bunx @temps-sdk/cli sandbox password sbx_abc123 --clear   # open it back up

`--rotate` sets a new one at the requested length, and `--clear` removes the lock so the port is reachable again with no password at all. The same sandbox identifier appears in both, which is how you find your way back. This is a preview surface rather than an auth system: the URL still reaches a live process inside the sandbox, and the only thing between a stranger and that process is the generated string. The rest of the feature set leans the same way, with a shell, a per-port preview template and a timeline of what ran, so the intended workflow is to expose something for a moment and close it again.

Two passwords with no defaults, checked before anything boots

The environment template is unusually explicit about how to create the file, and why the obvious command is wrong:

#   install -m 600 .env.example .env

A plain copy commonly produces a world-readable file, so the file mode is set in the same breath. The template has no values on purpose, and the stated reason is that compose fails fast when they are unset so no known credential ever ships. Passwords are also embedded in connection URLs, so the character set is restricted, and startup rejects anything else before any database service starts. The mechanism is a throwaway service, an alpine container with `network_mode: none` and `restart: "no"`, whose only job is a shell case statement: a password containing any character outside that set prints a message about needing only URL-safe characters and exits 1. The suggested generator is `openssl rand -hex 32`. The same rule covers both secrets, `POSTGRES_PASSWORD` and `CLICKHOUSE_PASSWORD`, and the compose file marks both as required with an error message telling you to put them in a `.env` file next to `docker-compose.yml`.

The database is a project-built image, and auth is scram-sha-256

The Postgres service is not the stock image. It pulls `gotempsh/timescaledb-walg:pg18` from the same namespace as the project, described in the file as PostgreSQL with TimescaleDB and WAL-G for backups, on PostgreSQL 18. The container is named `temps-postgres`, restarts always, and creates a database and a role both named `temps`. Telemetry is switched off with `TIMESCALEDB_TELEMETRY: off`, and authentication is pinned twice: `POSTGRES_HOST_AUTH_METHOD: scram-sha-256` and `POSTGRES_INITDB_ARGS: "--auth-host=scram-sha-256"`, with a comment noting the choice is SCRAM rather than md5 for both password hashing and host authentication. A comment above the password line repeats the no-default policy and says compose fails fast when the variable is unset. One dependency is worth naming out loud: a self-hosted install pulls a database image that the project itself publishes, so the version of your data store is coupled to that image rather than to a vendor you chose.

Two subnets, a bridge for the admin proxy, and the Docker group id

The network layout is spelled out with defaults you are meant to change. The workload network is `temps-docker-workloads` on `198.20.255.0/24` with a public ingress at `198.20.255.10`, and the control plane is a separate private network on `198.18.255.0/24` with its own internal address plus fixed addresses for Postgres at `198.18.255.11` and ClickHouse at `198.18.255.12`. Both subnets come out of the range reserved for network benchmarking, which is why they are safe to ship as defaults without colliding with a real network, and the comments still tell you to change the subnet and the public ingress together, and all four control-plane values together, if they overlap an existing Docker, LAN or VPN route. A third network is introduced for the loopback admin proxy alone. The last setting is the one to read carefully: `DOCKER_GID=`, the group that owns the Docker socket, with the note that Docker access is root-equivalent and is required for deployment management, and a one-liner to find the container-visible value.

440 operations across 69 groups, each one a CLI command

The pitch is that every operation in the dashboard is also a command, 440 of them across 69 groups, and the examples are three lines long:

bunx @temps-sdk/cli projects list
bunx @temps-sdk/cli deploy my-app --environment production
bunx @temps-sdk/cli analytics ai-agents -p my-app --period 7d

The repository ships skills that teach an agent those commands, drop-in for Claude Code, Codex, OpenCode or any harness reading `.claude/skills/`, and the platform runs the same agents for you inside workflow sandboxes against your repository with platform-wide skills and MCP servers injected automatically. Two of the subsystems keep a tight leash on writes: the AI chat is read-only by default, answers from your own telemetry rather than a generic guess, and any write action is opt-in and still requires confirmation of a proposed change. The AI gateway is the opposite shape, since it holds your provider keys for OpenAI, Anthropic, xAI and Gemini behind one OpenAI-compatible endpoint, keeps them encrypted on your server, and attributes tokens, latency, error rate and estimated cost per model. Around those sit Sentry-compatible error tracking through a DSN, request logs on Cloudflare's Pingora with Let's Encrypt certificates over HTTP-01 and DNS-01, transactional email through DKIM or an SMTP relay, and OpenTelemetry ingestion so traces, metrics, logs and alerts share one queue instead of four tools. The workspace lists at least 52 crates before the visible list of members cuts off mid-name, and the newest three releases are all `v0.1.0-nightly` with a date and a commit hash, the most recent `v0.1.0-nightly.20261002.2d6c7780`.

Editorial conclusion

temps fits a team that wants hosting, observability and error tracking in one self-hosted install and is willing to own the database, the certificate renewal and the Docker socket. It does not fit a small project that wants a hosted platform with someone else on call, because the deployment asks for two database passwords, a Docker group id and a set of subnets before anything starts. Five things to check first: that the piped install script is one you have read, since the documented command runs a remote script through bash while the project's own release build goes out of its way to pin a Bun version and verify it; whether Docker or Firecracker is your isolation boundary, since the default backend is Docker and only `temps firecracker setup` changes that; that ClickHouse and the TimescaleDB image are acceptable dependencies, because the database is a project-built image on PostgreSQL 18; that the version you run is a nightly, since the three newest tags are all 0.1.0-nightly with a date and a commit hash; and what leaves your servers through the AI gateway and the read-only-by-default chat. The tree carries both a LICENSE and a LICENSE-MIT plus a NOTICE, and the workspace declares MIT OR Apache-2.0. The last commit is dated October 2, 2026.

Frequently asked questions

Official sources

1. gotempsh/temps on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases