Run inference on your own GPUs

Install a single binary or Docker container. Your prompts and completions stay on your hardware — routed through the same API, the same SDKs, the same console.

Why self-host

Installation

Install with the native package for your OS or run as a Docker container. On a Linux server the quickest path is curl -sSL https://get.pendra.ai/worker | sh, which auto-detects your GPU; you can instead add the Pendra apt or yum repository so apt upgrade / dnf upgrade keeps the worker current. On macOS and Windows, open the Pendra console → Workers → Add worker for an OS-aware download with checksums. Full per-OS instructions live in Workers → Install.

# Linux server — one command, auto-detects your GPU
curl -sSL https://get.pendra.ai/worker | sh

# …or install manually:
# macOS (Apple Silicon) — open the .dmg, drag Pendra into /Applications
open Pendra-<v>-arm64.dmg

# Windows — run the signed installer, no UAC needed
PendraSetup-<v>.exe

# Linux — pick CPU / CUDA / Vulkan to match your GPU
sudo apt install ./pendra_<v>_linux_amd64.deb
sudo pendra setup   # writes /var/lib/pendra/config.yaml and restarts pendra.service

# docker-compose.yml
services:
  pendra-worker:
    image: ghcr.io/pendra-ai/pendra-worker:latest
    restart: unless-stopped
    environment:
      - GPU_WORKER_PRIVATE_KEY=your_key_here
    volumes:
      - pendra-data:/root/.pendra

volumes:
  pendra-data:

# docker-compose.yml
services:
  pendra-worker:
    image: ghcr.io/pendra-ai/pendra-worker:cuda
    restart: unless-stopped
    environment:
      - GPU_WORKER_PRIVATE_KEY=your_key_here
    volumes:
      - pendra-data:/root/.pendra
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  pendra-data:

# docker-compose.yml
services:
  pendra-worker:
    image: ghcr.io/pendra-ai/pendra-worker:vulkan
    restart: unless-stopped
    environment:
      - GPU_WORKER_PRIVATE_KEY=your_key_here
    volumes:
      - pendra-data:/root/.pendra
    devices:
      - /dev/dri:/dev/dri

volumes:
  pendra-data:

CLI reference

The pendra CLI manages your worker. Config is stored in ~/.pendra/config.yaml. Full env-var reference at Workers → Configuration.

Workers in the console

The Pendra console → Workers page lists every worker you've connected and its live status. When a worker disconnects — you stop it, reboot the host, or it loses its network — it stays listed as Offline with the time it was last seen, rather than disappearing, so you can tell a worker went away from one that was never added. A worker that comes back online reappears on its own; you don't need to re-add it.

An offline worker is removed automatically 30 days after it last disconnected. To remove one sooner, open it and choose Delete (or use the delete action beside it on the Workers list) — you can only delete a worker while it's offline. If you revoked the worker key it connected with, the worker can't reconnect, and the console flags it so you know to delete it or issue a new key and reinstall.

Models

A worker serves models from Pendra's curated catalogue — vetted open-source models (Llama, Qwen, Mistral, gpt-oss, Phi, embeddings, and more). Install one with a single click in the console (Models → Install) or with pendra models install <model>; Pendra downloads a verified GGUF straight onto the worker, no SSH or shell required. If the worker drops offline mid-download, the install picks up where it left off when it reconnects — it doesn't restart from zero, and the console shows the download as interrupted until it resumes. Connection drops during a large download are retried automatically, and if an install does fail on a flaky network, installing it again continues from the bytes already downloaded. Image models, and chat models that accept images, are often made up of several files; one is listed as installed and starts taking requests only once every file has downloaded and been checked.

Installing from a script or an automation tool works the same way. pendra models install <model> --wait returns only once the worker is actually serving the model, and its exit code tells you what happened: 0 installed and serving, 1 failed (the reason is printed), 2 unknown model, 3 the download was handed to the worker and is still running (what --detach returns, and what you get if you press Ctrl-C or the session drops mid-download). When the output isn't a terminal — a log file, a pipe, docker exec — progress arrives as one JSON line per update with the bytes, part, rate and ETA, instead of a redrawn bar. A download you left running is easy to check on from another shell with pendra models jobs, and re-running the same install command joins it rather than starting a second copy; large models that ship as several files show which part is downloading, in the console as well as the terminal.

Out of the box a worker handles chat (with reasoning, tool calling, structured outputs, and vision), embeddings, image generation, and audio transcription — all in-process, with nothing else to install. See choosing a model size and choosing a quantization to pick the right variant for your hardware.

Requirements

Hybrid deployments

Route traffic based on sensitivity, cost, or performance. Your application code stays the same regardless of where inference runs.

Want us to handle it instead?