How Oloya HQ works
Oloya HQ has two parts: a small gateway you install on each Linux server, and the dashboard where you and your AI DevOps engineer work. The gateway connects outbound over HTTPS, so you open no inbound ports and share no SSH keys.
The AI never gets a shell. It can only propose named operations with typed arguments. Each one is checked, waits for approval when it is risky, runs on the server, and is verified and recorded in the audit log.
Connect your first server
- 1Create an account and your organization. Everything you add belongs to it.
- 2Open Servers, choose Add server, and copy the install command. It contains a single-use token that expires after a short time.
- 3Run it on your server as root or with sudo:
curl -fsSL https://oloyahq.cloud/install.sh | sudo bash -s -- --token=YOUR_TOKENThe installer detects the architecture, downloads the oloya-gateway binary, verifies its SHA-256 checksum and starts it as a systemd service. Your server appears as healthy within about 15 seconds. To check it from the server:
systemctl status oloya-gateway --no-pager
journalctl -u oloya-gateway -n 100 --no-pagerRequirements: a Linux server with systemd (amd64, arm64, armv7 or 386) and outbound HTTPS. Still showing “pending”? See troubleshooting.
Install modes
Choose how much Oloya HQ may do on a server by adding --mode to the install command.
| Mode | What it allows |
|---|---|
manage | The default. The gateway stays unprivileged and a small root helper carries out the operations you approve: package installs, service restarts, PM2 and Docker, reverse proxy and TLS. |
monitor | Read-only: metrics, logs and what is running. Add --with-docker to include container monitoring. |
full | Runs the whole gateway as root. Not recommended. |
Work with the AI DevOps engineer
Open AI DevOps in the dashboard and describe what you want, as you would to a colleague:
- “Why is the API returning 502?”
- “Deploy store-api from GitHub at api.mystore.com.”
- “Which server is running out of disk, and what is using it?”
It reads the server first (metrics, logs, containers, recent deployments and security findings), then explains what it found. When something needs changing, it proposes a plan of typed operations with a risk level for each step. Nothing that changes your server runs until it is allowed to.
Risk levels and approvals
Every operation has a risk level, which decides what happens before it runs.
| Level | Examples | Default |
|---|---|---|
| Read-only | Metrics, logs, process list, Docker status, disk usage | Runs automatically |
| Low | Restart an application, reload a service | Runs automatically, per workspace policy |
| Medium | Install a package, update an application, change proxy config | Needs approval |
| High | Remove a container, delete data, change the firewall or SSH config | Needs approval and explicit confirmation |
Each consequential action goes through the same steps: proposed → validated → approved → executed → verified → audited. The audit record is written before execution, so even an operation that fails halfway is on record. Approve or reject pending work under Operations, and adjust the defaults in Settings → Safety.
Deploy an application
Deploy from a Git repository with PM2, Docker, Docker Compose or as a static site. Ask the AI DevOps engineer, or start from Applications. The plan covers the runtime, the build, the process, the health check, the domain and the HTTPS certificate.
Every release is stored under Deployments with its commit and a rollback target. A rollback is proposed like any other operation, so it waits for approval too. Applications already running on the server (PM2, Docker and systemd) are discovered automatically.
Monitoring, logs and alerts
Each server reports CPU, memory, swap, disk and disk I/O, network, load, processes, containers and services in real time. Logs collects Docker, file and journald logs, and you can turn on continuous collection for any application.
Alerts fire on thresholds you set and are sent by email or webhook. Repeated alerts are grouped, and they resolve on their own when the condition clears. Related alerts become an incident with a timeline and a root-cause summary.
Security and backups
Security scans each server read-only: SSH configuration, firewall, user accounts, cron, publicly bound ports, Docker exposure and pending package updates. The result is a weighted score, and every finding comes with a plain-English reason and a recommended fix. A check that cannot run is shown as unavailable, never as passed.
Backups run on a schedule and keep a history of runs and restore points. A restore is high risk, so it waits for approval.
Teams, roles and audit
Invite your team from Settings → Invites and give each person a role. Roles decide who can view, who can operate and who can approve. Every action, by a person or by the AI, is written to the audit log. Group servers into Projects and environments to keep production separate from staging.
API
The dashboard uses the same HTTP API you can use. Once you are signed in, the full generated reference (every endpoint, request and response) is at /api/docs, and the OpenAPI document is at /api/v1/openapi.yaml.
Remove the gateway
Run the installer with --uninstall. Add --purge to also delete its configuration, state and system user:
curl -fsSL https://oloyahq.cloud/install.sh | sudo bash -s -- --uninstall --purgeThe server stays in your dashboard as offline until you delete it there.
Need a hand?
Look in the help centre or write to [email protected].