Sidekicks

Agent runtimes,
deployed like apps.

A control plane for starting, watching and stopping agent runtimes such as nanobot and nanoclaw. A working prototype, not a finished product.

Prototype Zero automated tests

See how it works Honest status

Illustrative mock. Names and numbers are made up; it shows the kinds of things the real pages list.

What it is, and how it works

Sidekicks treats an agent runtime the way a platform treats an app. You pick a template, give it a name, a model and some settings, and press deploy. The web app records that request and puts a job on a queue. A separate deployer process picks it up, starts a Docker container from the template’s image and waits until it answers a health check. The dashboard then shows the status and logs.

Web app + APINext.js, Auth.js RedisBullMQ deploy queue Postgresstate, logs, settings Deployernode, dockerode Run workerBullMQ consumer Runtime containernanobot, nanoclaw, ... Docker socket Artifact storageS3-compatible (MinIO)
Simplified from the repository README and docker-compose.yml. The arrows show control flow, not every call.
  1. Request. The dashboard sends a deploy request: template, agent name, model, tools, memory type and environment variables.
  2. Queue. The API stores it in Postgres and enqueues a job on the sidekicks-deployments queue.
  3. Provision. The deployer creates a container on the same Docker network, writes deployment log lines to Postgres as it goes, and probes /health until the runtime answers.
  4. Run. Later jobs go to the run worker, which calls the runtime and uploads any artifacts to S3-compatible storage.

What is in the repository

  • Runtime templates

    The seed data defines templates for OpenClaw upstream, nanobot, NanoClaw and NemoClaw, each with an image, default model, supported tools and required environment keys.

  • Deploy and watch

    A deploy dialog, an agents list with detail pages, and deployment statuses: provisioning, healthy, degraded, stopped, failed.

  • Runs and artifacts

    Jobs become runs with steps, logs and output, and files they produce are stored as artifacts you can open from a storage page.

  • LLM profiles

    Provider keys are kept as workspace profiles. The README says they are encrypted at rest in Postgres with a key you supply.

  • Accounts

    Auth.js sessions backed by Postgres, with email and password sign-up and optional GitHub sign-in. Data is scoped to a workspace.

  • Two node layout

    The repo includes notes for a Hetzner-style split: a control node for web, Postgres and Redis, and a worker node with Docker for the runtimes.

A look at the dashboard

Illustrative mock Built from the repository’s real statuses, deployment fields and page list. Every name, number and log line below is invented. It is not a screenshot and shows no real data.

Statuses (provisioning, healthy, degraded, stopped, failed) are the real ones from the code; everything else is made up.

The data model

The domain types in lib/domain/types.ts are a good map of the product. Its main nouns:

Agent instance

name, template, model, tools, memory, region, and a status of idle, running, paused or error.

Deployment

image, container id, endpoint, runtime adapter, status and last health time.

Job and run

queued, running, completed or failed, with steps, logs, output and artifacts.

Runtime adapters named in the code are sidekicks-native, openclaw-upstream and nemoclaw.

Status, honestly

Last commit is dated 22 March 2026. There are no automated tests in the repository, and we have not started the stack for this page.

  • In the code

    Dashboard pages, API route handlers, a Postgres store, queues, the run worker, the Docker deployer, seed templates and a Compose file for the whole stack.

  • Prototype

    Version 0.1.0, private package. Treat it as a design you can run, not a hardened service. The README says production templates should use real upstream images and configured provider keys.

  • Thin runtimes

    The bundled nanoclaw runtime is a small stand-in that replies that Claude Code setup is needed before automated runs work. The nanobot runtime is a small wrapper that writes its config from environment keys.

  • Zero tests

    No unit, integration or end-to-end tests exist. The only automated check mentioned is a build flag for CI that skips environment validation.

  • Unverified

    We did not run Compose, deploy a runtime or test sign-in. Everything on this page comes from reading the source and docs.

  • Needs you

    You must supply a database, Redis, an auth secret, an encryption key and storage settings before it does anything real. The deployer needs access to a Docker socket, which is powerful; read the code before exposing it.

Get started

Run it locally

Docker Compose builds and starts the web app, worker, deployer, Postgres, Redis and MinIO. Copy the example env file first and set the secrets it lists.

docker compose up --build

The app is then on port 3000. Not run by us for this page.

Signing in

Create an account from the Sign up page. The Compose file can also seed a development account for local use; its details are in the README and can be overridden in your own .env. Change them for anything beyond your own machine.