start-temps

Featured

Start (or restart) a local Temps control plane built from this checkout, and the web dev server (`bun dev`) in `<checkout>/web`. Invoke when the user says "start temps", "restart temps", "launch the server", "kill and restart temps", or asks to bring the local server up after backend changes. Ports, database and data dir are allocated PER CHECKOUT (a "slot") so several worktrees/branches run side by side without killing each other or corrupting each other's schema — the first checkout you start in claims slot 0 (the familiar `:8080` / `:3000`); every other worktree gets its own slot and its own `temps_s<N>` database. Uses the `fast` cargo profile (release semantics, no debug symbols, parallel codegen) for quick rebuilds. Pass `split` (e.g. "start temps split", "/start-temps split") to launch the two-process proxy/console topology for testing that feature.

DevOps & Infrastructure 742 stars 56 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 92/100

Stars 20%
96
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Start a local Temps server Boots the `temps` binary from source (`cargo run --bin temps --package temps-cli -- serve ...`) for quick local iteration, no debugger required. See `CONTRIBUTING.md` for the one-shot manual version of this; this skill adds port isolation across worktrees and a repeatable restart flow. ## Prerequisites - The database container from `CONTRIBUTING.md` ("Database" section) running and reachable, e.g.: ```bash docker run -d --name temps-db --restart unless-stopped \ -p 127.0.0.1:5432:5432 \ -v temps-db-data:/home/postgres/pgdata/data \ -e POSTGRES_USER=temps -e POSTGRES_PASSWORD=temps -e POSTGRES_DB=temps \ timescale/timescaledb-ha:pg18 ``` If your container has a different name, user, password, or port, set `TEMPS_DEV_DB_CONTAINER` / `TEMPS_DEV_DB_URL_BASE` before running step 0, or just edit the generated slot env file afterwards. - `bun install` already run in `<checkout>/web`. - Docker running, if you'll exercise features that shell out to it (container deploys, agent sandboxes, etc.) — see the Docker precheck below. ## Port slots — read this first If you keep multiple worktrees of this repo around (one per branch/PR), the naive approach — hardcode `:8080` / `:3000` and kill whatever's listening — means starting temps in worktree B kills the server another session was using in worktree A. This skill instead assigns each checkout a *slot* (0–29) and derives every port from it: | Thing | Port | Slot 0 | |---|-...

Details

Author
gotempsh
Repository
gotempsh/temps
Created
10 months ago
Last Updated
today
Language
Rust
License
Apache-2.0

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

DevOps & Infrastructure Featured

start-temps-cluster

Start (or restart) a local multi-node Temps cluster using Docker-in-Docker — one control plane + 3 worker nodes, each a privileged DinD container running its own dockerd + `temps agent`, wired with the real multi-host overlay (VXLAN, compute_cidr allocation) via `tools/dev-cluster/` in whichever checkout/worktree you run it from. Invoke when the user says "start the temps cluster", "spin up a multi-node dev cluster", "test this with multiple workers", "bring up worker nodes locally", "docker in dind cluster", or wants to verify cross-node behavior (node targeting, cluster DNS, overlay networking, node join/mTLS) that a single-node `start-temps` server cannot exercise. Distinct from `start-temps` (single-node, native binary, port-slot based) and `start-temps-ee` (single-node EE binary) — this is the only path that actually has more than one node.

742 Updated today
gotempsh
DevOps & Infrastructure Featured

temps-cli

Operate Temps through the pinned `@temps-sdk/cli` package with bunx or npx. Use when the user mentions Temps CLI, `@temps-sdk/cli`, a CLI command, or asks to deploy, configure, inspect, automate, or administer Temps from a terminal. Covers contexts, projects, deployments, environments, services, domains, monitoring, backups, telemetry, browser Performance Insights/Core Web Vitals, Cloud, platform administration, and read-only managed-data browsing. Apply the target-context, secret-handling, confirmation, and verification rules for every agentic CLI operation.

742 Updated today
gotempsh
DevOps & Infrastructure Featured

temps

Manage, deploy, operate, and instrument applications with Temps. Use this skill whenever the user mentions Temps, `@temps-sdk/cli@0.1.36`, deploying or migrating an app to Temps, projects, environments, services, domains, backups, logs, monitoring, analytics, browser Performance Insights/Core Web Vitals, observability, error tracking, OpenTelemetry, tracing, session replay, or Temps Cloud. Also use it when preparing an application for production on Temps even if the user does not explicitly ask for the CLI. Route to focused references, proactively detect missing observability during create/link/deploy journeys, and use pinned `bunx` or `npx` CLI invocations with explicit target contexts.

742 Updated today
gotempsh