Remyral
●Self-hosted agent operationsremyral.com

Collective Intelligence Infrastructure

Many agents.One intelligence.

Remyral runs the agent CLIs your team already uses as one fleet on your own machines. You drive jobs, approvals, merges and deploys from a chat window, and every step lands on the audit log.

Talk to us about a pilotSee how it works
Supported agents
  • Claude Code
  • Codex
  • opencode
  • pi
Home: approvals waiting for you, decision deadlines and failed jobs.
Machines screen: machines with OS, version, ready runtimes and slot usage.
Ops chat: the assistant turned a request into two job drafts, one approved and one awaiting review.
Control plane
your Linux server
Worker connection
outbound only
Workers
Linux · macOS · Windows · Docker
Interface
English · Türkçe
—Where teams are today

Agents are powerful. Running them as a team is a mess.

The problem isn’t how good the agents are — it’s how they are operated.

  1. 01

    Tied to one machine

    Each agent runs on someone’s laptop; when the lid closes, the work stops.

  2. 02

    Invisible limits

    Which subscription ran out and how much was spent only shows up once a job is stuck.

  3. 03

    Scattered secrets

    API keys and git credentials get copied machine to machine; nobody records who approved what.

  4. 04

    Manual delivery

    Agent-written code still waits for a person at every branch, PR, merge and deploy.

From one chat window to your whole agent fleet.

  • Run it from chat

    Type “approve and merge the PRs” or “deploy it”; the platform does it directly.

  • On your infrastructure

    The control plane on your server; the jobs on your Linux, macOS and Windows machines.

  • Audit every step

    Adjustable autonomy, per-event authenticator codes and a tamper-evident audit log.

01Ops chatanimation · demo data

The chat becomes your control panel.

The assistant queries the fleet, projects, jobs and usage with your permissions. It carries out a clear command directly and asks you when it isn’t sure.

  1. 01

    Type

    A clear command (“approve and merge the PRs”) just runs; a request becomes a job draft.

  2. 02

    Draft

    Project, machine, runtime and branch on one card. Approve, edit or dismiss it.

  3. 03

    Approve

    Whatever your security setting says: one click, a person’s approval or an authenticator code.

  4. 04

    Result

    The finished job comes back to the chat with a summary; every step is on the audit log.

  • Question cards. When an agent can’t decide, a multiple-choice or free-text question lands in the chat.

  • Backup machines. If the machine running the assistant goes down, the next backup picks up the same conversation.

02Architecturecontrol plane + workers

One control plane, as many workers as you need.

The control plane runs on one Linux server: panel, API, queue, vault and audit log. The agents don’t run there — they run on your machines.

Workers connect outbound; no inbound ports are opened on your machines.

Connects to
  • GitHub
  • GitLab
  • Bitbucket
  • Coolify
  • Cloudflare
  • MCP
  1. 01

    Install

    The control plane comes up on one Linux server through an installer that verifies the release signature.

  2. 02

    Connect

    “Add machine” in the panel, two lines on the machine; confirm the pairing code and fingerprint.

  3. 03

    Run it from chat

    Type “deploy to preview”; the assistant drafts the job or simply does it.

03Fleetlinux · macos · windows · docker

Your machines, one pool.

The queue places each job on a suitable machine, taking capacity, disk state and the required runtime into account.

  • One command to connect. Linux, macOS, Windows or Docker; the install script is checked against the digest shown in the panel.

  • Capacity and health. Load, disk, sessions and runtime versions on one screen.

  • Central git identity. No logging into machines one by one; a short-lived token per push.

  • Signed updates. Worker releases are signed and roll out to the fleet gradually.

04Jobs and live logs

Watch every job live.

Each job runs on its own branch or workspace. You see what the agent does step by step — and can send the running agent an extra instruction.

  • Live log and timeline. Files read, commands run, tests — in order.

  • Short, readable titles. Job, PR and commit titles are generated for you.

  • Pick up where it stopped. Re-run, fix, or continue from the files that were kept.

Live job page: stage bar, step-by-step activity log and a box to instruct the running agent.
05Shared memoryrules · facts · decisions · lessons

Every agent works from the same memory.

Your team’s rules, known facts, decisions and lessons live in one shared memory. The same memory reaches Claude Code, Codex, pi and opencode in one rendering.

  • Typed and scoped. Every entry is a rule, a fact, a decision or a lesson, scoped globally, per runtime, to a person or to a project.

  • One memory, four runtimes. Claude Code, Codex, pi and opencode read the same memory from the same rendering.

  • A person accepts lessons. Agents propose lessons; a proposal doesn’t enter memory until a person accepts it.

  • History stays. Superseded or expired knowledge stops steering agents, but its history stays browsable.

  • Reproducible jobs. Every job pins the memory versions it used, so you can tell later what it worked from.

06Workflow enginecondition · loop · HTTP · code · approval

Combine AI steps with real automation.

Workflows aren’t just AI steps: conditions, loops, HTTP requests, code and approval nodes run on the same canvas.

  • On the worker, within the rules. HTTP and code nodes run on a worker under the project’s network rules.

  • Applied once. Side effects carry an idempotency key and are applied exactly once.

  • Ready-made templates. Marketing, content and video production; let the AI design in the editor, review the diff, approve.

07Autonomy and control

You decide how autonomous it is.

The same product works at both ends: closed teams get the CLI’s “auto mode” feel, regulated teams tie every sensitive step to a person’s approval and an authenticator code.

  1. Serbest · flow

    Approvals, merges and deploys pass without asking. For closed teams.

  2. Dengeli · rules

    Risky actions are asked according to rules; a code is required for the events you pick.

  3. Sıkı · approval

    Every sensitive action needs a person’s approval and a code. For regulated teams.

Asked in every mode: machine management, force-push and security-setting changes. Automatic decisions are logged as “approved by policy”.

Security settings: the Serbest (free), Dengeli (balanced) and Sıkı (strict) presets.
08Securityvault · sandbox · egress · ed25519 · hash

Secrets stay on the machine. Boundaries are enforced.

  • A vault sealed with the worker’s key

    The master cannot open a secret; only the machine that uses it can. A key pasted into the chat goes into the vault.

  • Sandbox and network policy

    Per project: off, allow-list or web. Local network and metadata addresses are always blocked.

  • Signed releases, chained audit

    Worker updates are signed; every privileged action is on a hash-chained log.

The full security architecture
09From code to liverepo → agent → verify → release

From a new repo to a deploy, without touching a machine.

Agent work doesn’t stop at a PR. Verification, the merge decision and the release are one flow; long-running dev servers and tunnels run as services that don’t hold a job slot.

  1. Repo

    A private GitHub repo is created and linked to the project.

  2. Agent

    The job runs on its own branch; the platform does the commit and push.

  3. Verify

    The branch is verified; a PR and a merge decision are opened.

  4. Release

    Coolify, Cloudflare Pages and DNS — domains, environment variables, watched paths.

Repositories: GitHub, GitLab (gitlab.com or self-managed) and Bitbucket Cloud. Keys stay encrypted on the server and never reach the model.

Merge decision: changed files, platform verification, CI checks and the approval card.
10Resilience

A failure doesn’t wait for a person.

Overnight jobs don’t sit there “failed” in the morning. Transient errors are retried with growing intervals, on another machine if needed.

  1. 02:14

    A job stops on a transient error.

  2. +1 min

    Automatic retry.

  3. +5 min

    If needed, on another machine with another account.

  4. done

    The result arrives as one notification.

Self-healing
Missing branches, diverged history and permanent failures open a fix job on their own.
Limit awareness
A subscription at its limit is known fleet-wide; the job waits or moves to a ready account or a fallback runtime. Paid fallbacks only if you allow them.
Queue safety
No jobs go to a machine whose disk is full; malformed messages don’t stall the queue.
Outage-tolerant
If the panel is unreachable for up to 15 minutes, running jobs carry on; results and approval requests wait on the machine.
11Visibilitystatus · logs · cost

What happened and what it cost — on one screen.

The one question a manager has: what happened, and what did it cost? You see problems without SSH, and can ask about most of them in chat.

Usage screen: five-hour and weekly limit windows per machine and subscription.
Audit log: every privileged action, with chain verification and export.

  • System status

    Server, database, queue, machines and disks; the last hour’s errors and integration checks.

  • Log search and traces

    Seven days of logs, searchable by job, request and trace id; tokens and passwords are masked.

  • Usage and cost

    Per runtime and account; limit windows refresh live, so you see which subscription reopens when.

  • Key and certificate expiry

    Tokens, certificates and signing keys in one list; reminders 30, 14, 7 and 1 day before expiry.

  • Rollout circuit breaker

    If updated machines start failing, the new worker release stops rolling out on its own.

  • Cost brake

    Daily and monthly caps on API-billed spend; it warns first and, if you choose, holds non-urgent jobs.

12ExtensibilityMCP · skills · API · webhooks

Need a new tool? Have the chat install it.

Installs don’t need hand-signed files or per-machine configuration. You preview and approve; it is tried on one machine first, then rolled out to the fleet.

  • MCP servers. Remote, or local npm/PyPI packages; version lock, a trial on one machine first, per-tool permissions.

  • Skill catalogues. Search with “Discover”, preview, install with an approval; pinned to a commit.

  • Requests with @credential. A key from the vault is used in requests without its value ever being shown.

  • API tokens and OpenAPI. Scoped, expiring tokens; every endpoint is in the public API document.

  • Outgoing webhooks. Job, approval, deploy and workflow events go signed (HMAC) to n8n, Zapier or your CI.

Capabilities → Discover: skill catalogues from GitHub repositories, pinned to a commit.
13Install and upgrade

Your server, your schedule.

One installation for one company. The control plane runs on your Linux server, and you decide when to upgrade.

  • Verified install. The script checks the release signature and every file; if anything is off, it stops before changing a thing.
  • Setup wizard. Organisation, security preset, first machine, git connection and a sample job — every step can be skipped.
  • Safe upgrades. A mandatory backup first, then migration and a health check; if it fails, the way back is ready.
  • Diagnostics. One-click server and machine checks; preview a masked support report, then download it or send it by email.
Installation details
# download the signed installer
$ curl -fsSLO https://<release-url>/<version>/install.sh
$ sudo bash install.sh --domain ops.example.com \
    --tls letsencrypt --email [email protected]

# verify → pull → migrate → start → health check
# then: https://ops.example.com/setup
14Why Remyral

More than a single agent tool.

NeedAgent CLI on one machineRemyral
Your own server and machinesPartlyFully self-hosted
Many machines, one queueNoYes
Several runtimes and accounts, automatic fallbackNoYes
Adjustable autonomy, per-event verificationPartlyYes
Audit chain and team rolesNoYes
End-to-end flow from code to deployManualYes

Remyral doesn’t replace the agent CLIs; it runs them as a fleet. Your existing subscriptions and machines stay in use.

—The nameRE · MYR · AL

Collective intelligence, built into the name.

A single ant knows very little. The colony, through local communication and division of labour, solves complex tasks. In Remyral, each agent does what it is good at, on another computer if need be. Work goes to the right agent, knowledge and experience are shared through a common memory, and independent work moves as one.

  1. RE

    Remana

    Where the brand comes from. Remyral is a product of remana.tech.

  2. MYR

    Myrmex

    Ancient Greek for ant: the intelligence of the colony, of the whole rather than of one.

  3. AL

    Agent Layer

    The shared management and coordination layer the agents run on.

Many agents. One intelligence.

Intelligence doesn’t have to stay in one model, compute on one computer, or knowledge in one session.

The RE · MYR · AL expansion is a brand-specific meaning, not a dictionary definition.

→Next step

Let’s start with a four-week pilot.

  1. Week 1

    Install

    The control plane and 2–3 worker machines.

  2. Weeks 2–3

    Real work

    A real team’s jobs and one deploy pipeline.

  3. Week 4

    Review

    Usage, cost and audit report.

Talk to us about a pilot

or write to us directly: [email protected]

Scope and price of the pilot are agreed in a call.