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 655 stars 46 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 92/100

Stars 20%
94
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

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.

655 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.34`, 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.

655 Updated today
gotempsh
DevOps & Infrastructure Featured

temps-best-practices

Best-practices reference for preparing and instrumenting applications on Temps. Covers the app runtime contract (`.temps.yaml` health, HOST/PORT, readiness, SIGTERM, replicas, migrations) and production observability (errors, traces, metrics, logs, analytics, privacy, sampling, cardinality, credential boundaries). Use whenever building or reviewing an app for Temps, configuring health checks, adding telemetry, diagnosing missing/noisy signals, or checking OTLP/Sentry/analytics ingestion. Triggers include "temps best practices", "prepare this app for Temps", ".temps.yaml health", "temps health check", "ignore health checks in otel", "temps observability", "wire up telemetry", and "instrument this app for temps". Prefer focused setup skills for a single SDK. Use temps-cli for executing deploy and resource-management commands.

655 Updated today
gotempsh