feat: Multi-node support for deployments and managed services

[dviejokfs]

Problem description

Currently, Temps runs as a single-node deployment platform. All containers, managed services (PostgreSQL, S3-compatible storage, Redis, MongoDB), and application workloads are bound to a single host. This creates several limitations:

• No horizontal scaling: As the number of deployed projects grows, a single node becomes a bottleneck for CPU, memory, and disk.
• No high availability: If the single node goes down, all deployments and managed services become unavailable.
• No geographic distribution: Users cannot deploy workloads closer to their end-users across multiple regions.
• Resource contention: Heavy database workloads compete with application containers on the same host, degrading performance for both.

For teams running production workloads on Temps, single-node architecture is a hard ceiling that forces migration to other platforms as they scale.

Proposed solution

Introduce multi-node support that allows Temps to orchestrate deployments and services across multiple machines:

Core architecture

• Agent binary (temps agent): A lightweight process that runs on worker nodes, connects back to the control plane via WireGuard VPN, and executes container operations locally.
• Node registry: A nodes table tracking each worker node's address, status, capacity, and health.
• Node scheduling: A scheduler service that decides which node should host a new deployment or service based on resource availability, affinity rules, or manual assignment.
• Secure networking: WireGuard-based mesh VPN between the control plane and all worker nodes for encrypted communication.

Managed services across nodes

• PostgreSQL, Redis, S3-compatible storage, and MongoDB services should be deployable on any registered node.
• deployment_containers and external_services tables gain a node_id column to track placement.
• The deployer layer routes container operations (create, start, stop, logs) to the correct node's agent.

Node lifecycle

• temps join <control-plane-url> to register a new worker node.
• Health checks and heartbeat monitoring to detect node failures.
• Graceful drain/remove workflow for decommissioning nodes.

UI/API

• A settings page to view and manage registered nodes.
• API endpoints for node CRUD, health status, and capacity metrics.
• Deployment creation allows optional node targeting.

Alternatives considered

• Kubernetes integration: Deploying to a K8s cluster instead of bare Docker nodes. Rejected because it adds massive complexity and contradicts Temps' single-binary simplicity philosophy.
• Docker Swarm: Using Swarm mode for multi-node orchestration. Rejected because Swarm is effectively unmaintained and lacks fine-grained control over service placement.
• External load balancers only: Keeping single-node but adding LB support. This doesn't solve resource contention or HA for managed services.

Additional context

This is a foundational feature for Temps Cloud (managed Hetzner offering) where customers will need workloads distributed across multiple servers. It also enables self-hosted users to scale beyond a single machine without leaving the Temps ecosystem.

Related work is already in progress on the feat/multinode branch, including:

• temps-agent crate (worker node agent)
• temps-wireguard crate (VPN mesh networking)
• Node entity, migrations, and scheduling service
• Remote deployer for routing operations to worker nodes

[joeblew999]

Is this going to a closed source feature ?

“

This is a foundational feature for Temps Cloud (managed Hetzner offering) where customers will need workloads distributed across multiple servers

“

[dviejokfs]

@joeblew999 No, most of it it's already in the open source. But it's not hardened yet