Learn

Cave Concepts

Understand Caveman's architecture and the key entities that power your infrastructure. Live connections, bidirectional communication, real-time visibility.

Sources · Git repos Services · What you deploy Hosts · Where it runs

What is Caveman?

Caveman gives you a live connection to every server. Not metrics collected and stored for later querying—an actual real-time, bidirectional connection. Like SSH meets htop, but for your whole fleet.

Traditional observability tools work like a postal service: your servers send data through pipelines into databases, and you query it later. Caveman is fundamentally different—one 2MB agent, always connected, always real-time. No pipelines, no log warehouses, no query languages.

Code to Live View
Code Push to Git
Deploy Talk to Caveman
Running Instances
Live Real-time

Bidirectional by default.

Traditional agents are fire-and-forget—they push what they're configured to push. Our probe can be interrogated. Ask "what's using all the memory?" and get an answer in real-time. Tail a log file on demand. Restart a service without SSH.

Workspaces

A workspace is your team's home. It contains services, dashboards, credentials, and members. Users can belong to multiple workspaces with different roles (owner, admin, member).

When you sign up, you get a personal workspace. Create additional workspaces for teams, projects, or clients—each with its own isolated resources.

Sources

Sources are credentials that connect Caveman to your code and container registries. They enable two key capabilities:

Git Capability

Clone repositories, read configs, trigger builds from source code. Providers: GitHub, GitLab

Registry Capability

Pull container images for deployment. Push built images to registries. Providers: Docker Hub, GitHub CR, GitLab CR

We insist on connecting a repository.

Your repo contains more than code. It has Dockerfiles, compose files, environment templates, and deployment scripts. When you connect a repo, we can use these configs directly—no manual re-entry, no drift.

Services

A service is a logical unit—your API, your database, your worker, your ML model. Services have types: web, database, worker, gpu_workload, and more.

All instances of a service run the same code with the same configuration.

Different config = different service. This isn't a limitation; it's clarity.

Correct

"api-production" and "api-staging" are separate services with different configs.

Incorrect

One "api" service where some machines have DEBUG=true and others don't.

Caveman is the source of truth for configuration.

Environment variables are stored here, encrypted at rest. We push to providers (Fly, RunPod, GCP), not pull from them. One source, multiple targets.

Hosts

Hosts are deployment targets—the infrastructure where your services run. Connect your cloud accounts and bare metal servers to deploy anywhere. Every host gets the same live connection—whether it's Fly.io, a RunPod GPU, or a bare metal server in your closet.

Fly.io
RunPod
DigitalOcean
AWS
GCP
Hetzner
Kubernetes
Bare Metal

Same service. Fly + GCP + bare metal. We don't care.

Your "api" service can span multiple clouds. Run your API on Fly for low-latency edge. Run ML inference on RunPod for GPUs. Run batch jobs on cheap bare metal. They're all instances of services in Caveman.

Probe Installation Guide

The Caveman probe is a 2MB binary that creates a bidirectional WebSocket connection to your infrastructure. Unlike traditional agents that only push data, the probe can be interrogated in real-time—tail logs on demand, ask "what's using memory?", restart services without SSH.

Without probe, you only get polling. With probe, you get a live connection.

Platform APIs (Fly, RunPod) only let us poll logs periodically. The probe enables real-time streaming, on-demand queries, and remote commands. It's the difference between checking email and having a phone call.

Choose your scenario

Deploy from Code (GitHub/GitLab)

Connect your repo and we handle the rest

When you connect GitHub/GitLab, we have access to:
Your source code
Your Dockerfile
Container registry (GHCR/GitLab CR)
Ability to create PRs
Two ways to add probe:
RECOMMENDED PR Automation

We analyze your Dockerfile and create a PR to add the probe. You review, approve, and merge. From then on, every build includes the probe automatically.

# We'll add to your Dockerfile:
RUN curl -sSL https://caveman.sh/probe | sh
LABEL io.caveman.probe.installed="true"
ENTRYPOINT ["/caveman-wrapper.sh"]
Manual Modification

Add these lines to your Dockerfile yourself, then push to trigger a new build.

# Add before your ENTRYPOINT/CMD
RUN curl -sSL https://caveman.sh/probe | sh
LABEL io.caveman.probe.installed="true"
# Wrap your entrypoint
ENTRYPOINT ["/caveman-wrapper.sh"]
CMD ["your-original-command"]
Connect repo PR or modify Build Deploy Live
What probe monitors
CPU

Usage, load average

Memory

Used, available, swap

Disk

Space, I/O, mounts

Network

Bandwidth, connections

Processes

Running, top consumers

Logs

stdout, stderr, files

Live View

Not dashboards you stare at—live views you glance at. Real-time visibility into every service, every instance. Mission Control shows your entire fleet at once. Drill into any server instantly.

Logs

Streaming, real-time

Metrics

CPU, memory, network

Processes

What's running, what's consuming

Health

Up/down, response times

Commands

Restart, exec, inspect

AI Insights

24/7 monitoring