SimhiveSimhive · docs · pool page

Docker and headless machines

Lend a Linux server, a NAS or any box without a desktop to the pool with one container, with or without the sim interface. SimulationCraft is fetched at the pool's exact build.

For a Linux server, a NAS or any box without a desktop: the same engine as a container, from github.com/rbardtke/simhive-docker. Nothing to compile. SimulationCraft is fetched at the pool's exact build (35 MB) and follows the pool from then on.

You need Docker with the Compose plugin on x86-64 Linux, and your token (the same one as everywhere).

git clone https://github.com/rbardtke/simhive-docker.git && cd simhive-docker
cp .env.example .env      # put your token in it
docker compose up -d

With or without the interface #

The one switch in .env:

  • SIMHIVE_INTERFACE=true gives you your own Simhive page on port 4747 (sims go to the pool) and lends the machine's cores.
  • SIMHIVE_INTERFACE=false lends the cores and serves nothing. The machine just works for the pool.

Either way it appears under your name, and threads, schedule and pause for it are set like for any other machine of yours, from the app on your PC or from the container's own page if it has one.

Updating #

docker compose pull && docker compose up -d

The image is rebuilt on every engine change; Settings → Pool says "behind" when a machine should do this.

Good to know #

  • The interface has no login: keep port 4747 on your LAN.
  • On Unraid, Synology or Portainer, paste compose.yml into the stack editor and set SIMHIVE_TOKEN as an environment variable instead of the .env file.
  • The image is x86-64 only. On ARM, Docker answers "manifest unknown".
  • docker compose logs says why a container restarts in a loop: usually the token is missing from .env, or the pool could not be reached to ask which SimulationCraft build to fetch. It retries by itself.