start-temps-cluster

Featured

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.

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 multi-node Temps cluster (Docker-in-Docker) Wraps `tools/dev-cluster/` — a docker-compose harness that runs a real Temps control plane plus 3 worker nodes, each a privileged DinD container, with the actual overlay network (VXLAN, `compute_cidr` allocation, cluster DNS) wired up exactly as it would be on real hardware. Use this whenever a fix or feature needs *more than one node* to prove anything — single-node `start-temps` cannot exercise cross-node scheduling, the overlay, or cluster DNS at all. ## Topology ``` ┌──── temps-underlay (10.42.0.0/24, docker bridge, the "VPC") ────┐ │ │ │ postgres 10.42.0.5 (TimescaleDB pg18, internal) │ │ control-plane 10.42.0.10 DinD + `temps serve` │ │ host ports 80 → 80, 443 → 443 (NOT 8080 — see Gotcha below) │ │ │ │ worker-1 10.42.0.21 worker-2 10.42.0.22 worker-3 10.42.0.23│ │ each: privileged DinD + `temps agent`, own dockerd │ └──────────────────────────────────────────────────────────────────┘ Allocator carves /24s from 172.20.0.0/16, one per worker: worker-1 → 172.20.0.0/24 worker-2 → 172.20.1.0/24 worker-3 → 172.20.2.0/24 Cross-node container traffic flows over a VXLAN tunnel pinned to the underlay IPs above. Within-node traffic uses the unchanged `temps-app-network` Docker bridge (same as single-node temps). ``` The te...

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

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.

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

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".

742 Updated today
gotempsh