start-temps-cluster
FeaturedStart (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.
Install
Quality Score: 92/100
Skill Content
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
start-temps
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.
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.
deploy-to-temps
Deploy applications to the Temps platform with automatic framework detection, Dockerfile generation, and container orchestration. Supports Next.js, Vite, React, Node.js, Python, Go, Rust, Java, and C# applications. Use when the user wants to: (1) Deploy their app to Temps, (2) Set up CI/CD with Temps, (3) Configure deployment settings, (4) Create a Dockerfile for Temps, (5) Deploy a containerized application, (6) Set up automatic deployments from Git. Triggers: "deploy to temps", "temps deployment", "push to temps", "containerize for temps", "temps ci/cd".