FluxHive

Research teams often outgrow ad hoc SSH sessions before they are ready to operate a general-purpose cluster scheduler. Jobs compete for GPU memory, logs remain on individual machines, and nobody has a reliable view of what is running or waiting.

FluxHive is a self-hosted control plane for that middle ground. It coordinates training, inference, batch experiments, and evaluation across local, laboratory, and cloud GPU machines while keeping deployment and job submission approachable for a small team.

A three-part system

FluxHive separates the platform into three cooperating components:

• Agent runs beside the workload, observes the machine, starts and stops processes, and streams status and logs.
• Control Server owns Job definitions, dispatch, authorization, and the durable view of each Run.
• Web Client turns the control plane into a shared workspace for submission, monitoring, logs, and resource visibility.

The persistent Agent-to-server channel matters here. The server needs to push work without polling, while Agents continuously return runtime events and GPU observations. Keeping that protocol explicit also prevents the browser interface from becoming the system's real API.

Jobs before language-specific tasks

The central abstraction is a language-neutral Job protocol rather than a Python-only function wrapper. Python, TypeScript, Go, and Rust SDKs provide convenient declaration APIs, but the contract is intended to remain implementable by other runtimes.

This boundary lets the scheduler reason about a workload through its manifest, resource requirements, commands, environment, artifacts, and runtime events. Application code does not have to import the control server or become a distributed-systems framework merely to run on another machine.

Scheduling with honest resource information

The first useful scheduling policy is deliberately simple: respect bounded concurrency and maintain a stable queue. GPU observations then make richer placement possible, including memory-aware selection and per-device concurrency limits.

The important engineering distinction is between the working platform and the policy roadmap. The repository contains the three-part architecture, Job protocol, execution and observability paths; more advanced placement, recovery, and experiment-automation policies continue to evolve. FluxHive is not presented as a replacement for Slurm or Ray at every scale. It focuses on making a small research fleet legible and operable without requiring each workload to adopt a large runtime.

What the project clarified

FluxHive made a recurring systems lesson concrete: scheduling is less about choosing the next item than preserving truthful state while machines disconnect, processes fail, users reorder work, and resource snapshots become stale. A useful control plane must make those transitions inspectable and recoverable, not merely render a queue.