Install on your server. Start with your team’s work.
Your IT team prepares the management server and the machines that run the work. Your team can then start with a research, content, file-based or software workflow. The management side (console, API, database, queue and backups) runs on one Linux server; agents run on your own machines, which connect outbound to the server.
A git connection is only needed for software projects. Research, reports, content and file work run in workspaces that need no code repository; you can skip the git step in the wizard.
System requirements
| Minimum | Recommended | |
|---|---|---|
| OS | Linux, x86_64 or aarch64 (Ubuntu 22.04+, Debian 12+, RHEL / Rocky / Alma 9+) | Ubuntu 24.04 LTS |
| CPU / memory | 2 vCPU, 4 GiB | 4 vCPU, 8 GiB |
| Disk | 10 GiB free | 20 GiB+ (backups grow with the database) |
| Software | Docker Engine ≥ 24 with the compose plugin ≥ 2.24, OpenSSL ≥ 3, curl | — |
| Network | A DNS name for the console; ports 80 + 443, or one HTTPS port behind your proxy | Outbound HTTPS to the release URL and registry |
Windows and macOS are not supported for the control plane (nor Docker Desktop on them). Both are fully supported as worker machines.
Install
- 01
Point the DNS name
Point the console’s DNS name (e.g. ops.example.com) at the server.
- 02
Download and check the installer
Download the installer from the release URL and compare the key id in the release announcement with the trusted key in the script.
- 03
Pick a TLS mode and run it
Run the script as root with one of three TLS modes (below).
- 04
Create the owner account
The script ends by printing a one-time setup token. Enter it at /setup and create the owner; the first sign-in connects your authenticator app and shows 10 recovery codes.
- 05
Finish the setup wizard
Organisation name, security preset, the first machine, git connection (for software projects only), optional integrations, the first project and a sample job. Every step can be skipped and resumed from the home page.
# download the script and check the trusted key
$ curl -fsSLO https://<release-url>/<version>/install.sh
$ grep -n "TRUSTED_KEYS=" install.sh
# A) Let’s Encrypt
$ sudo bash install.sh --domain ops.example.com \
--tls letsencrypt --email ops@example.com
# B) Cloudflare
$ sudo bash install.sh --domain ops.example.com \
--tls cloudflare [--tls-cert origin.pem --tls-key origin.key]
# C) your own reverse proxy
$ sudo bash install.sh --domain ops.example.com \
--tls proxy --https-port 8443 --http-port 8080 \
--bind 10.0.0.5 --trusted-proxy 10.0.0.2/32Three TLS modes
- Let’s Encrypt
- The server answers on 80/443 itself; Let’s Encrypt issues the certificate.
- Cloudflare
- DNS proxied by Cloudflare; SSL “Full”, or “Full (strict)” with an origin certificate.
- Your own proxy
- Your reverse proxy terminates TLS; you set the ports, bind address and trusted proxy.
What the installer does
- Checks the prerequisites.
- Downloads the release and verifies its signature and every file. If that fails, it stops before changing anything.
- Creates the data directory; generates passwords and key files once and never prints them.
- Writes the proxy configuration, pulls the images by digest, migrates the database and starts the stack.
- Waits for the health check and prints a one-time setup token.
Useful flags
--dry-run- Checks, verifies and prints every step; changes nothing.
--version- Installs a specific release (default: the newest).
--registry- Uses your own image mirror; digests are kept.
--bundle- Installs from an offline copy of a release directory.
--backup-recipient- Your age public key: backups then also carry the key files, encrypted.
--data-dir- Where the data directory lives.
Re-running the installer is safe: it keeps the secrets and choices of the first run. To change the TLS mode or ports, re-run it with the new flags.
Connect machines
Workers run on Linux (x64, arm64 / 64-bit Raspberry Pi), macOS (Apple silicon and Intel) and Windows x64; a Docker worker is supported too.
“Add machine” in the panel
Machines → Add machine → pick the operating system.
Run two lines
The first line downloads the install script and stops if its SHA-256 digest differs from the panel’s. The second downloads the kit, checks it against the signed index and installs the service.
Pair it
Compare the pairing code and fingerprint shown on the machine with the panel, enter the code and approve with an authenticator code.
Configure from the panel
Projects, runtimes, parallel job count and sandbox profiles are set in the panel — no need to go back to the machine.
- If the machine lacks a suitable Node.js, a pinned release is installed — after digest and signature checks — into a private folder for the worker only; the system Node and PATH are left alone.
- If you’d rather not download from the internet, download the installer bundle from the panel and copy it to the machine.
- The commands in the panel carry no secrets or tokens; no machine is trusted until you approve it.
Worker requirements
A worker is the machine that runs the jobs. It runs as an OS service under its own low-privilege account, starts at boot and restarts after a crash.
| System | Service | Notes |
|---|---|---|
| Linux · x64, arm64 | systemd service with its own system account | 64-bit Raspberry Pi OS on a Raspberry Pi. Optional rootless Docker or Podman for the container profile. |
| macOS · Apple silicon, Intel | LaunchDaemon; starts without a login | The worker account cannot read your home folder or your keychain. |
| Windows 10 / 11 · x64 | Windows service with a virtual service account | Installed from an elevated PowerShell. Per-job accounts for parallel jobs are prepared from the Sandbox card. |
| Docker worker | A container on a Linux machine running Docker | Connects through the same pairing flow as the other workers. |
Node.js 24: a system-wide installation is used if present. Installations a normal user could replace (nvm, a per-user Homebrew, a user folder on Windows) are refused. Without a suitable Node, the panel installer puts a pinned release — after digest and signature checks — into a private folder for the worker only.
Network: the worker only needs outbound HTTPS/WSS to the control plane’s address; no inbound ports.
Agent CLIs
Installed and managed by the worker. Pinned releases of Claude Code, Codex, opencode and pi are installed, upgraded, rolled back or removed from Machines → machine → Runtimes; every release is checksum-verified. No need to log into the machine and install them by hand.
With a subscription. The runtime’s own login is started from the panel and done on that machine, as the worker account. Jobs that share one subscription login run one at a time.
With an API key. Add the key to the vault under Settings → Credentials and choose which machines it goes to; it is sealed separately for each machine.
Your accounts. Remyral provides the system; you use the models with your own accounts — by subscription (e.g. Claude, ChatGPT) or with an API key. Subscription and API use are subject to the provider’s terms.
Example topology
A typical start for a small team. The names are examples.
Control plane · Ubuntu 24.04 LTS, 4 vCPU, 8 GiB · only 80/443 open
- build-01Linux x64 · container profile · Claude Code, Codex
- mac-studiomacOS arm64 · runtime-sandbox · Claude Code, opencode
- win-ops-02Windows 11 x64 · per-job accounts · Codex, pi
All three machines connect to the control plane outbound; none of them opens an inbound port. A pilot covers up to 3 machines.
Upgrade
When a newer signed release exists, owners see an “update available” banner in the console with the release notes, breaking changes and the command. The upgrade always runs on the server, started by you.
verify
pull
stop master
backup
migrate
start
health check
Check first. Ask whether a newer release exists, and preview every step with a dry run.
Mandatory backup. If the pre-upgrade backup fails, nothing changes and the system starts again as it was.
Confirmation for breaking changes. A release with breaking changes asks for explicit confirmation.
A way back. If the health check fails and the database schema didn’t change, the old release comes back on its own. If the schema advanced, the command prints the rollback that restores the pre-upgrade backup.
Machines update themselves. Release notes name the minimum worker version; worker releases are signed and roll out gradually.
Backups, diagnostics and removal
Nightly backup
A backup service dumps the database every night and runs a restore drill; status is in Settings → Backups. Manual backups are available too.
Keep the keys off the server
Store the settings file and the key directory in a password manager; without the authenticator key everyone has to re-enrol their app.
Diagnostics
Settings → Diagnostics checks the control plane and connected machines in one click; findings come with a suggestion and a link to the right page. The same checks run from the server too.
Support report
Describe the problem, pick the sections, preview every file in the zip; download it or send it by email. Passwords, tokens and keys never go into the report.
Ports
Only the reverse proxy’s ports (80/443, or the ones you choose) are published on the server.
Removal
Uninstalling removes the containers and keeps the data directory. Deleting the database, backups and keys as well is a separate, irreversible option.
Troubleshooting
The most common situations and what to do first. If that doesn’t solve it, prepare a masked support report under Settings → Diagnostics and send it to us.
The install script stops with a digest mismatch
The downloaded script doesn’t match the SHA-256 digest shown in the panel. Copy the commands from the panel again; if it persists, don’t run the script and write to us.
The machine doesn’t appear under “waiting to pair”
Check that the machine reaches the control plane’s address outbound over HTTPS/WSS. The pairing code and fingerprint are printed at the end of the install and in the service log. Re-running the install is safe.
The service starts, then stops and doesn’t restart
That is a configuration, file permission or keystore problem (exit code 78); the service deliberately doesn’t restart then. The service log says what to fix; fix it and start the service. macOS can’t tell this apart from a crash and retries every 10 seconds.
The installer refuses Node.js
The worker refuses a Node installation a normal user could replace (nvm, a per-user Homebrew, a user folder on Windows). Install Node 24 system-wide, or let the panel installer put a private Node in place for the worker.
A Raspberry Pi doesn’t connect
It needs the 64-bit Raspberry Pi OS; 32-bit systems are not supported.
A sandbox profile shows as “not ready”
The Sandbox card says why and who can fix it. On Linux the container profile needs rootless Docker or Podman; the card’s “Prepare” button can install Podman through the privileged helper. Steps marked “needs the owner” can only be done by the machine’s administrator.
Jobs on Windows don’t run in parallel
Per-job accounts are switched on after a cross-access test passes on the machine: run “Prepare” on the Sandbox card with the privileged helper. If the test fails, jobs run one at a time and the card says why. Jobs that share one subscription login always run one at a time.
A job waits in the queue
The job page shows why: the key may not have reached that machine yet, the chosen model may not be defined for that runtime, or no suitable sandbox profile is ready. A link on the job page opens the right machine’s Sandbox card.
Let’s do the installation together in a pilot.
Week one of the four-week pilot is discovery and setup: the control plane on your server, 1–3 workers on your machines.