The open-source control plane for agent operations.
Deploy, observe, and operate agent runtimes from one dashboard. Nora is self-hostable, commercially usable, and enterprise-capable. OpenClaw is the strongest supported runtime today, while Nora stays aimed at broader runtime integration over time.
Self-host Quick Start · Hosted eval / managed PaaS · Deployment / support / enterprise paths · Rollout help / paid support · Install script (bash) · Install script (PowerShell) · Open-source proof pack · Screenshots · Runtime direction · Deployment footprint
Nora is an open-source control plane for self-hosted agent operations.
Today, the best-supported path is OpenClaw. That is the clearest way to evaluate Nora right now. But the product direction should stay broader than a single runtime: Nora should become easier to integrate with additional agent runtimes over time.
It is designed to be credible for serious operator use: individual builders can run it, internal platform teams can standardize on it, and larger enterprise-capable environments can keep infrastructure control without giving up the open-source trust model.
Nora gives technical teams a single place to:
- deploy agent runtimes into isolated environments
- manage provider keys and sync them to running runtimes
- access chat, logs, and terminal workflows
- connect channels and integrations
- monitor operator activity and runtime workflows
The core value proposition is simple: if you care about infrastructure, observability, repeatable operations, and a trustworthy operator surface, Nora helps you get to a usable control plane faster.
Nora should be easy to describe in one pass:
- Security built in — the product should feel trustworthy for real operator environments, not like an afterthought wrapper around secrets and infrastructure.
- Easy to use — teams should be able to reach first proof quickly: install, create an operator account, add one provider, deploy one runtime, and validate the workflow.
- Expandable — the product should support a clean path from today's best-supported runtime to broader runtime adapters over time.
- Self-hostable — the repo, install scripts, and Docker Compose flow should remain a credible trust path.
- Enterprise-capable — Nora should make sense from single-host evaluation through Proxmox, private cloud / on-prem, and AWS/Azure/GCP rollout footprints.
That combination is the durable positioning: not a toy dashboard, not a vague AI shell, and not a permanently single-runtime wrapper.
Nora is licensed under Apache 2.0.
That means you can:
- self-host Nora on your own infrastructure
- modify the codebase for your own needs
- use Nora commercially inside your company
- host Nora for clients or customers on infrastructure you control
- build services, packaging, or integrations on top of Nora
The repo should not market a maintainer-commercial relationship as the center of the product. The center of the product is the fully open-source repo and self-hosted control-plane workflow.
That OSS-first story should still feel enterprise-capable: teams should be able to read the repo, inspect the install path, and conclude that Nora can support serious internal operations without a sales-led trust gap.
OpenClaw is the most mature and best-supported runtime path in Nora today. If you want the fastest proof of value, start there.
Nora should not be permanently framed as useful only for OpenClaw. The product, docs, and interface should stay friendly to future integration with other agent runtimes.
That means:
- avoid branding the whole product as permanently single-runtime
- describe OpenClaw as the strongest supported path today
- keep runtime abstractions clean enough that future adapters are realistic
- show examples with OpenClaw now without turning the platform story into “OpenClaw only, forever”
Nora should also be framed as a control plane that can grow with operator requirements.
It should make sense across this deployment range:
- single-host self-hosted installs for first proof and lean teams
- Proxmox-backed environments for stronger isolation and private fleet control
- private cloud / on-prem environments for security-conscious internal platforms
- AWS, Azure, and GCP deployments for larger cloud-native or enterprise rollouts
That footprint matters because Nora is not just trying to be a one-box dashboard. It should stay credible as an operator surface that starts small and expands into more serious infrastructure.
See Deployment footprints for the full positioning guide.
Nora is best for:
- internal AI platform teams
- technical product teams
- ops-minded operators running agent infrastructure
- service providers who want to host and operate agent control planes for others
Nora is not trying to be:
- a vague “AI workforce” shell
- a generic low-code automation toy
- a closed wrapper around an otherwise-open repo
Use this path to reach first proof of value quickly:
- Install Nora with the setup script or Docker Compose flow
- Create your operator account and save one LLM provider key
- Deploy one agent runtime and validate chat, logs, and terminal from the same surface
That path is still easiest with OpenClaw today, but the operator model should remain extensible.
The paid path should be clear without making unsupported claims.
Start with the repo, raw install scripts, and Docker Compose path if you want the cleanest proof and full infrastructure control.
Use GitHub Discussions if you want the same OSS product but a faster path to first value on infrastructure you control.
Use nora.solomontsao.com and signup when you want a less DIY first step or want to evaluate Nora through a hosted path.
Use deployment paths when you need scoped help around deployment footprint, infrastructure ownership, rollout depth, or larger-team requirements.
See Commercial paths for the full public-path positioning guide.
Nora should ask people to trust the product itself, the install path, and the operator workflow.
Use these resources when you need to prove that the repo is real and usable:
- Repo proof pack — the public proof map for installability, operator workflow, screenshot evidence, and paid-path credibility
- Open-source implementation proof — code-backed evidence for self-hosting, operator flows, proof assets, and runtime direction
- Adoption checklist — practical paths for self-hosting, Apache 2.0 commercial use, rollout help, hosted evaluation, and runtime expansion
- Open-source usage guide — Apache 2.0 usage rights and public repo framing
- Commercial paths — self-hosted OSS, rollout help / paid support, managed PaaS, and enterprise/custom entry points
- Deployment footprints — how Nora should scale from single-host through Proxmox, private cloud, and AWS/Azure/GCP
- Runtime direction guide — how to describe Nora as OpenClaw-first today while keeping the product future-runtime-friendly
- Operator screenshot capture script — regenerates the operator screenshots from a local self-hosted stack
The repo now includes real operator-side screenshots alongside the marketing and OSS-proof images. They show Nora as a working self-hosted control plane, with OpenClaw as the current best-supported runtime example rather than the forever-only frame.
| Proof asset | What it demonstrates |
|---|---|
proof-landing-open-source-funnel.png |
Nora leads with an OSS-first trust path rather than a sales-first gate |
proof-usage-rights-apache.png |
Apache 2.0 commercial-use rights and path clarity are visible publicly |
proof-signup-operator-account.png |
A real operator account entry flow exists |
proof-operator-dashboard.png |
Nora has a working operator overview beyond marketing copy |
proof-operator-fleet.png |
Operators can manage and validate multiple runtimes |
proof-operator-deploy-flow.png |
The first runtime deployment flow is concrete and inspectable |
proof-operator-agent-detail.png |
Ongoing operations include validation, logs, and terminal surfaces |
proof-operator-settings-provider-setup.png |
Provider setup is part of the current product path |
Nora should be described as:
- OpenClaw-first today
- runtime-friendly by direction
- self-hosted and commercially usable by anyone under Apache 2.0
- credible from single-host through Proxmox, private cloud, and AWS/Azure/GCP deployment footprints
That framing is more durable than treating Nora as a permanently single-runtime dashboard or centering the repo around sales packaging.
See Runtime direction guide for the durable wording and guardrails behind that positioning.
The setup script can install Docker, Docker Compose, and Git if they are missing.
- macOS 12+, Linux (Ubuntu 20.04+, Debian 11+, Fedora 38+), or Windows 10+ with WSL2
- Admin/sudo access for initial setup
macOS / Linux / WSL2
curl -fsSL https://storage.solomontsao.com/setup.sh | bashWindows (PowerShell)
iwr -useb https://storage.solomontsao.com/setup.ps1 | iexThe installer will:
- clone the repository
- verify Docker, Docker Compose, and OpenSSL
- generate platform secrets
- configure self-hosted or PaaS mode
- create the initial admin account
- collect an LLM provider key (optional but recommended)
- start the Nora stack
- take you to the dashboard so you can deploy the first agent
The public install links intentionally use storage.solomontsao.com as the canonical installer host while keeping the open-source repo and install docs as the primary trust anchor.
git clone https://github.com/solomon2773/nora.git
cd nora
bash setup.shOr configure by hand:
cp .env.example .envThen edit .env with your secrets:
# Required — generate with: openssl rand -hex 32
JWT_SECRET=your-64-char-hex-key
ENCRYPTION_KEY=your-64-char-hex-key
# Optional bootstrap admin (seeded only when both are set securely)
DEFAULT_ADMIN_EMAIL=<REPLACE_WITH_BOOTSTRAP_ADMIN_EMAIL>
DEFAULT_ADMIN_PASSWORD=<REPLACE_WITH_STRONG_BOOTSTRAP_PASSWORD>
# Optional — OAuth (leave blank to disable)
GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
NEXTAUTH_SECRET=your-64-char-hex-key
# Optional — Stripe billing (PaaS mode)
STRIPE_SECRET_KEY=
STRIPE_PRICE_PRO=
STRIPE_PRICE_ENTERPRISE=Start the stack:
docker compose up -d| URL | What |
|---|---|
| localhost:8080 | Marketing / entry page |
| localhost:8080/login | Login |
| localhost:8080/signup | Create operator account |
| localhost:8080/app/dashboard | System overview |
| localhost:8080/app/deploy | Deploy your first agent |
Go to Settings and save an API key for a supported provider such as Anthropic, OpenAI, Google, or another available provider.
- Go to Deploy
- enter an agent name
- choose a runtime mode
- size CPU, RAM, and disk
- click Confirm & Deploy Agent
After deployment:
- open the agent detail page
- verify the agent is running
- sync provider keys if needed
- test Chat
- inspect Logs
- open Terminal
If those steps work cleanly, Nora has already demonstrated its core value.
Create agents, choose the runtime backend, define resource limits, and manage their lifecycle from the dashboard.
Use OpenClaw chat workflows directly from the UI with streaming responses and session visibility.
Access persistent terminal sessions connected to agent runtimes.
Save provider credentials centrally and sync them to running agents when needed.
Configure communication channels and browse integration options from the same control plane.
Track agent health, queue state, logs, metrics, and runtime activity.
Nginx (:8080)
├── / → frontend-marketing (Next.js)
├── /app/* → frontend-dashboard (Next.js)
├── /admin/* → admin-dashboard (Next.js)
└── /api/* → backend-api (Express.js)
├── PostgreSQL 15
├── Redis 7 + BullMQ
└── OpenClaw Gateway today / broader runtime adapters later
frontend-marketing/— landing, login, signup, and deployment/support-path pagefrontend-dashboard/— operator dashboard for agents and settingsbackend-api/— APIs, auth, key management, provisioning, monitoringadmin-dashboard/— admin/operator surfacese2e/— Playwright end-to-end testsinfra/— backup and TLS helpers
| Layer | Technology |
|---|---|
| Reverse Proxy | Nginx |
| Frontend | Next.js 14, React 18, Tailwind CSS |
| Backend | Express.js 4, Node.js 20 |
| Auth | NextAuth.js, JWT, bcryptjs |
| Database | PostgreSQL 15 |
| Queue | BullMQ + Redis 7 |
| Agent Runtime | OpenClaw Gateway today; broader runtime integrations remain in scope |
| Encryption | AES-256-GCM |
| Provisioning | Docker, Proxmox, Kubernetes, NemoClaw |
| Variable | Required | Description |
|---|---|---|
JWT_SECRET |
Yes | Secret for signing JWTs |
ENCRYPTION_KEY |
Yes | 32-byte hex key (openssl rand -hex 32) |
PLATFORM_MODE |
No | selfhosted (default) or paas |
PROVISIONER_BACKEND |
No | docker (default), proxmox, k8s |
NEMOCLAW_ENABLED |
No | true to enable NemoClaw sandbox |
CORS_ORIGINS |
No | Comma-separated allowed origins |
# Docker (recommended)
docker compose up -d
docker compose logs -f backend-api
docker compose up -d --build backend-api
# Local dev
cd backend-api && npm install && npm run dev
cd frontend-dashboard && npm install && npm run dev
cd frontend-marketing && npm install && npm run dev
# Tests
cd backend-api && npx jest --no-watchman
# Database
docker compose exec postgres psql -U platform -d platformFor HTTPS/TLS setup, see docs/HTTPS_SETUP.md.
- improve activation UX and first-run operator flow
- tighten self-hosted positioning and documentation
- improve dashboard proof density and onboarding clarity
- continue hardening auth, key sync, and operator workflows
- public REST API and API keys
- agent templates and cloning
- richer alerting and cost controls
- multi-tenant teams with stronger RBAC
- agent versioning and rollback
- CLI workflows for deployment and sync
Nora is in active development.
Good contribution areas include:
- frontend UX for operator workflows
- backend provisioning and lifecycle management
- testing and CI hardening
- integrations and channel support
- self-hosted deployment ergonomics
- Fork the repository
- Create your feature branch (
git checkout -b feature/amazing-feature) - Commit your changes
- Open a Pull Request
This project is open source under the Apache License 2.0.