olace

[ get started ]

Headless & cloud hosts

A home server, a box you reach only by SSH, a GPU instance you rent by the hour: the daemon and CLI run happily with no desktop app and no display. Everything works from the shell, and the machine becomes a host for every device you carry.

Nothing is reduced by the missing screen. A headless host pairs, serves models, runs the Bridge, and is managed remotely exactly like a computer with the app on it.

Install

# Linux and macOS
curl -fsSL https://olace.app/install.sh | sh

# Windows (PowerShell)
irm https://olace.app/install.ps1 | iex

This installs the daemon and the olace command, registers the background service so the machine stays reachable across reboots, adds olace to your PATH (asking first on Linux and macOS), then continues straight into setup in the same terminal. No GUI, no runtime requirements beyond your local AI runtime of choice.

Set up

A fresh install walks through four steps, asking before each one installs anything:

  1. A runtime. Ollama, llama.cpp, or llmster, LM Studio's headless daemon. Every one runs without a display.
  2. A starter model sized to the GPU Olace detects.
  3. The Python sandbox, so models can run code on this machine for calculations, data files, and charts. Offered when the GPU runs models large enough to use it, and on a machine with no local runtime, because cloud models you chat with in its terminal run their code here too. On a machine that cannot run the sandbox, the step says why and names the fix.
  4. Sign-in, which adds Olace cloud models and lets your other devices use this machine. Local models work without it.

Every step is skipped when it is already done, and each can be run again on its own:

olace setup                       # the whole flow; finished steps are skipped
olace setup --provider llamacpp   # add a specific runtime
olace setup --sandbox             # the Python sandbox only
olace pull qwen3.6:27b            # a different model
olace signin                      # one-time code by email

Set OLACE_NONINTERACTIVE=1 before the install script to skip the handoff, for a Dockerfile or a config-management run. Run olace setup yourself afterwards: without a terminal on stdin it prints what each step would do instead of asking, and exits 2 when a step still needs one.

If the background service is not installed (you removed it, or copied the binary by hand), olace signin offers to install it. Say yes.

Make it a host

Pair your other devices to this machine so they can use its models from anywhere:

olace pair --code

Scan the QR from your phone, or type the code into another computer (olace pair claim <CODE> works too). That is the whole network setup. Nothing needs opening in your firewall or router: the relay needs only outbound connections, and if a firewall blocks the direct LAN connection, devices use the relay instead.

Serve other apps

olace bridge on --require-key

Now any OpenAI-compatible or Anthropic-compatible tool on this machine (Claude Code and Codex CLI included) can use its models, and every paired host's models, through 127.0.0.1:5578. See Olace Bridge.

On a machine you rent

A rented instance hosts like any other computer. Two things are worth knowing.

The machine is not yours. The pairing is still end-to-end encrypted and Olace still cannot read your conversations, but the turn runs in that machine's memory and anything stored on it sits on the provider's disk. See Hosting on a machine you rent.

A rebuilt instance is a new device. The daemon's identity lives in ~/.olace/identity.enc and is not meant to be copied between machines, so a replacement instance arrives as a new device: install, olace signin, and pair again. Remove the pairing the old one held, or it counts against your plan's cap:

olace pair list
olace pair remove old-instance

Models live in the runtime's own store, so a fresh instance pulls them again, and the per-machine context calibration is measured again over the first few loads.

Linux servers and VMs

Installed as root, the daemon runs as a system service: it starts at boot with nobody logged in, and code that models run executes as the unprivileged nobody user, never as root.

Installed as a regular user, it runs as that user's systemd service, which Linux stops at logout unless lingering is on. Olace turns lingering on where it is allowed to; over SSH without admin rights it usually is not, and olace setup offers to run the command that does, which needs sudo:

sudo loginctl enable-linger $USER

Until then, olace status notes under Service that Olace stops when you log out.

The Python sandbox runs on current distributions, including Ubuntu 22.04 and newer, Debian 12 and newer, RHEL 9 and newer, Alpine, and WSL2. On Linux 6.7 and newer it uses the kernel's Landlock sandbox. On older kernels, and on VM kernels built without Landlock, it builds an equivalent sandbox from Linux namespaces instead, which needs user namespaces (allowed by default on those distributions). Either way the code sees only its own files and the Python runtime, and reaches the internet only to install packages from PyPI. Inside a Docker container it normally uses the host's Landlock, so the host needs Linux 6.7 or newer and Docker 20.10.18 or newer. When a machine can run neither, olace status and olace setup say why and name the fix.

Keep an eye on it

olace status           # everything at a glance
olace logs -f          # follow the daemon log
olace update --check   # stay current

And from your other machines, most of them work remotely: olace status --device server, olace pull <tag> --device server, olace service restart --device server. Logs are the exception: read them on the host itself.