OpenNest keeps sensitive logic on the server while lightweight clients run anywhere you need them.
Architecture
A simple three-layer design that separates what the user sees, what the cloud orchestrates, and what runs locally.
Developer → OpenNest UI → OpenNest Server → Local Connectors → Your Tools
The UI is where you chat, approve, and monitor. The Server routes agents, models, memory, and workflows. Connectors expose your local environment as tools.
Universal Client
The connector adapts to the host. It only executes what the server asks and reports results back.
Full connector for files, terminal, Docker, browser automation, and local AI models on macOS, Windows, and Linux.
Headless daemon for Linux servers, CI runners, and cloud VMs with SSH, Git, and container access.
Docker and Kubernetes sidecar for ephemeral environments that spins up and down with your workloads.
Minimal clients in PHP, Python, Node, or other languages. A single file is enough for shared hosting or restricted environments.
Example
For a cPanel-hosted PHP site, upload one client file. No daemon. No SSH. No container.
<?php
require 'opennest_client.php';
$client = new OpenNestClient([
'project_key' => 'opn_...',
'server' => 'wss://api.opennest.dev',
]);
$client->registerTool('file_read', function($path) {
return file_get_contents(__DIR__ . '/' . $path);
});
$client->registerTool('file_write', function($path, $content) {
return file_put_contents(__DIR__ . '/' . $path, $content);
});
$client->run();
?>
The PHP client is intentionally thin. It does not route agents, parse tool output, or choose models. All orchestration stays on OpenNest Server.
Security
Your connector never holds the intelligence. It only handles secure execution.
Agent orchestration, model routing, memory, context gathering, and tool-output parsing run server-side.
Each project gets its own key. Compromising a connector does not expose your whole account.
Every action, approval, and tool call is logged. Review what agents did and when.