How RemoteHangar works

A shared workspace on your server

RemoteHangar runs on company infrastructure. Your team uses a browser to work with shared agent configuration, connections and execution history. The service is built on Node.js under systemd with an SQLite database.

A bay is an agent workspace with a working directory, a HOME directory, connected repositories and a task queue. A person can have several bays for different projects and workflows.

Execution uses connected accounts with subscriptions or coding/token plans. The agent calls your chosen model provider and configured MCP tools. Requests and necessary context go to that provider: hosting RemoteHangar and hosting the model are separate decisions.

An optional Go connector enrolls another host over mutual TLS and provides file and shell tools there. Your process defines the permitted actions and access.

One shared harness for team workflows

A harness is the agent’s working configuration: instructions, skills, tools, connections and execution rules. Useful setups can be reused instead of rebuilt for every employee.

The agent wizard helps describe the assistant’s purpose, work requirements and tools. Review and edit the resulting draft before saving it.

Development, project questions and IT support can use different agents and toolsets. Central configuration does not mean giving everyone the same access to every system.

• Agents: purpose, instructions and expected output
• Skills and plugins: reusable working practices
• Bundles and MCP servers: tools for a selected process
• Working context: repositories, documentation and tasks

The sandbox around each agent

Every agent process runs under bubblewrap. The system is mounted read-only apart from the writable exceptions listed below. Privilege escalation is blocked with NoNewPrivileges, so there is no sudo inside a bay.

The service itself runs under a hardened systemd unit: ProtectSystem=strict, ProtectHome=read-only and NoNewPrivileges.

Writes outside /home and the bay’s own directories are blocked. Reads are not yet isolated between bays: an agent can read files the service user can read, and /home is writable from every bay. Treat one installation as one trust group, typically one team. Read isolation is planned.

• Writable: the bay’s working directory and HOME, the whole /home directory (shared by every bay), the attachment and plugin caches and the agent memory directory
• Read-only: the rest of the file system, including the release and the data root
• Private per process: /tmp
• Optional: Docker inside bays, off by default. Enabling it gives bays the host’s Docker socket, which is root-equivalent on that host.

The task queue

Each workspace has a queue. Add a request as text or a link to an issue in a connected tracker. Added tasks execute in sequence without manually starting each next one. Automatically feeding work from external systems is a separate part of configuring your process.

A task can require several messages and tool calls. A single prompt or answer does not itself mean the task is complete: an agent or a person marks completion. The agent can request input and pause further work.

The right panel shows the active task, waiting requests and finished work. Pause the queue, cancel a waiting task or stop execution when needed. Queue turns run as the workspace owner.

• queued: waiting for its turn
• running: the agent is working on it
• done: the agent or a person marked it complete
• blocked: the agent needs a person; the queue pauses
• error: the task or the bay failed; the queue pauses
• cancelled or skipped: a person moved past the task

Checks and human review

A development task can include reading requirements, changing code and running project tests or a linter. The team sees tool calls and their results in the workspace.

Agent instructions define expected checks, but a completion message does not replace inspection. Read the diff, command output and findings, then request changes or accept the result according to team rules.

Merges, deployments and other consequential operations need explicit permissions and approval rules. They should not follow merely from a successful model response.

Where your data lives

Configuration, execution history and workspaces live on your server. Standard locations are listed below; effective paths depend on installation settings. Workspaces use approved roots such as /opt/repos and /home. Your chosen model provider receives necessary request context.

An API for your products

An internal portal, help desk, bot or company product can use prepared assistants through the API. The application backend opens a session, sends messages and receives streamed answers and events. Keep the RemoteHangar token on that backend. OpenAPI and Swagger documentation are available in your installation when the API is enabled.

Responses stream as Server-Sent Events. Clients can work with sessions, interrupt requests and download produced files. The API also provides one-shot requests, structured output and idempotency keys; available execution options depend on your configuration.

The API token authorizes your application, not a model-provider purchase. Model execution uses the accounts and plans connected in RemoteHangar.

curl -N https://hangar.example.com/v1/oneshot \
  -H "Authorization: Bearer $HANGAR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Summarize why the tests in this log fail",
    "idempotency_key": "ci-run-4812",
    "effort": "low",
    "response_format": {
      "type": "json_schema",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": { "summary": { "type": "string" } },
        "required": ["summary"]
      }
    }
  }'

Updates and rollback

A systemd timer runs the updater. It installs a new release only inside your maintenance window and only after checking twice that no agent is busy. You can pin a version, choose the release channel or turn automatic updates off.

Each release manifest is signed with minisign; the signing key never sits on the distribution server. If the host cannot run the verifier, the installer only warns; --require-signature makes the check mandatory. Before an update the database is snapshotted. If the new version fails its health check, both code and database schema roll back automatically.

If a published release turns out to be bad, we move the channel pointer back to the previous version, so servers that have not updated yet never take it.

Requirements

RemoteHangar targets Ubuntu 22.04 on x86_64. The installer needs root; the service runs as its own unprivileged user.

• OS: Ubuntu 22.04 with systemd. Ubuntu 24.04 blocks the unprivileged user namespaces the sandbox needs.
• CPU: x86_64
• Memory and concurrent work: sized for the workload, tools and active agents, then checked against the agreed pilot use case.
• Disk: space for repositories, history, tools, installed releases and backups; the amount depends on your workspace.
• Network: outbound HTTPS to your model provider, directly or through your corporate proxy
• Optional: nginx with a Let’s Encrypt certificate, set up by the installer