Nuwax: a self-hosted Agent OS that ships as Docker services and a CLI
Nuwax Agent OS - An enterprise-grade AI Agent Development and Operation Platform - Providing a complete solution for agent creation and distribution, knowledge base management, model proxy, memory system, and plugin ecosystem.
At a glance
- What is it?
- Nuwax bundles agent creation, knowledge base management, model proxying, memory and plugins into one deployable stack. The repository is TypeScript under Apache-2.0, the deployment path is Docker Compose driven by a nuwax-cli binary, and the sandbox tier is optional and separately hosted.
- Who is it for?
- Adopt Nuwax if you need an agent platform you host yourself, your team already runs Docker Compose on Ubuntu 22.04 or macOS, and you want the sandbox tier on separate machines. Do not adopt it if you need Windows deployment today, since the README marks Windows 10/11 support as coming soon, or if you want a single binary with no Docker dependency.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Nuwax targets: agent infrastructure you host yourself
Most agent frameworks hand you a library and leave the operational surface to you. Nuwax takes the opposite position. The repository describes it as an Agent OS, and the README frames the goal as building and deploying private agentic AI solutions. The word private carries the weight here. The platform is designed to be run on your own hardware, with the model proxy, knowledge base and memory system living inside the same deployment rather than being called out to a vendor endpoint.
The intended user is a platform or infrastructure team inside an organisation that has already decided agents need to run behind its own network boundary. The README lists four frontend surfaces: PC web, H5, mini app, and IM clients including Feishu, DingTalk, WeCom and Slack. That list tells you the project expects to be embedded into existing internal chat tools rather than used as a standalone chat product. The topics on the repository add a2a, mcp, agent-sandbox, agentic-rag and skills, which map to the components the README names: agent creation and distribution, knowledge base management, model proxy, memory system, plugin ecosystem.
What it is not is a hosted service with a free tier you can try in a browser. There is a demo URL, but the deployment path documented in the README is local or server-side Docker. If your team has no one who can run a Compose stack, the rest of this article will read as a list of obstacles rather than features.
Two services, one optional: how the deployment splits
The README is explicit that there are two deployment services. The main project service is required. The Agent Computer, described as a sandbox, is optional. That split is the most consequential architectural decision visible in the material, because it determines how you size your hardware.
The README states that the sandbox includes a personal computer and therefore requires more resources, and that it supports separate deployment across multiple servers. In the main local service you configure one or more Agent Computer deployment addresses. So the topology the documentation describes is a control plane that knows the network locations of one or more execution planes. You can start with the main service alone and add sandboxes later, or run the main service on one host and distribute sandboxes across several. Each sandbox server needs its own Docker and Docker Compose installation, and the README points to a separate installation document for that tier.
The architecture diagram in the README shows a frontend layer above an access layer carrying REST API, long connection, and WebSocket. The diagram is truncated in the supplied material after the access layer, so anything below it cannot be confirmed from what is available here. What can be confirmed is the shape of the top: multiple client types feed a single access layer, and the platform is expected to serve long-lived connections rather than only request-response calls. That matters for capacity planning, because WebSocket and long-connection traffic does not behave like stateless HTTP under a load balancer.
Getting it running: nuwax-cli and the Docker prerequisite
Deployment runs through an official command tool called nuwax-cli. The README gives the invocation form as `./nuwax-cli` followed by a subcommand, which suggests a binary placed in the deployment directory rather than something installed globally.
The service management commands are:
`./nuwax-cli docker-service start` `./nuwax-cli docker-service stop` `./nuwax-cli docker-service restart` `./nuwax-cli docker-service status`
Backup is a separate command group. The README warns that the backup service requires stopping the Docker application servers and recommends operating during low-peak periods. The commands are `./nuwax-cli auto-backup run` for a manual backup, `./nuwax-cli list-backups` to enumerate them, and `./nuwax-cli rollback [BACKUP_ID]` to restore. Note the coupling: a backup is not an online snapshot, it is a stop-copy-start cycle. If your agents serve live traffic, that is a maintenance window, not a cron job.
Upgrade is two steps. First `./nuwax-cli check-update install`, which the README describes as checking whether the deployment client itself has a new version. Then `./nuwax-cli auto-upgrade-deploy run`, which detects and downloads new application versions and deploys them. The ordering matters: the CLI is upgraded before the application it manages.
The prerequisites are stated plainly. Ubuntu 22.04 LTS or later, with the caveat that other Linux versions are not fully tested. macOS 10.15 and later on Intel or Apple Silicon, with OrbStack recommended and Docker Desktop also supported. Windows 10 and 11 are listed with support coming soon, so Windows is not a deployment target today. Hardware floor is 4 cores and 8GB RAM. The current user needs Docker permissions, verifiable with `docker ps`, and the README notes you can fall back to sudo if permissions fail. Docker Compose V2 is required.
For verification before deployment, the README offers `docker --version`, `docker compose version`, and `docker run hello-world`. There is also a community one-click install script invoked as `bash <(wget -qO- https://xuanyuan.cloud/docker.sh)`, which the README says supports 13 distributions including openEuler, Anolis OS, OpenCloudOS, Alinux and Kylin Linux, with mirror source switching and a binary-install fallback. That script is third-party, not part of the repository, and it is fetched and piped directly into bash. Treat that as a supply-chain decision separate from adopting Nuwax.
Where the documentation thins out
The README is a deployment guide, not a developer guide. It tells you how to start, stop, back up and upgrade the stack. It does not, in the material supplied, show how an agent is defined, what a skill or plugin looks like on disk, how the knowledge base is indexed, or what the memory system persists and where. The topics list includes agentic-rag and mcp, but the README does not explain how either is wired into the runtime.
That is a real gap for anyone evaluating the platform on technical merit rather than operational convenience. You can confirm the deployment story from the README alone. You cannot confirm from it how much code you would write to add a custom tool, whether the plugin ecosystem has a stable interface, or whether the memory system survives a container restart. The README links to a docs directory and to separate installation pages on nuwax.com, so the detail may exist there. Based on the repository material alone, it is unverified.
The second thin spot is the sandbox. The README says the Agent Computer includes a personal computer and needs more resources, and that it can be distributed across servers. It does not describe the isolation boundary. Whether a sandbox is a container, a VM, or something else is not stated in the supplied text. If your threat model depends on that answer, you need to read the agent-computer-deploy page before you commit hardware.
Backup and upgrade as the real operating cost
The maintenance burden here is not the initial install. It is the recurring cycle the CLI encodes. Backups stop the application servers, which means every backup is downtime of some length. The README recommends low-peak windows, which is an acknowledgement that this is disruptive. If you run agents that answer internal queries during business hours, you are choosing between data protection and availability on a schedule.
Upgrades are described as automatic: `auto-upgrade-deploy run` detects and downloads new versions and deploys them. Automatic here means the tool performs the deployment, not that the upgrade is risk-free. The release history in the repository shows a cadence of roughly weekly point releases in mid-2026, with v1.1.13, v1.1.14 and v1.1.16 appearing across June and July. A project shipping at that rate will hand you upgrade decisions frequently. The two-step sequence, CLI first then application, is the documented procedure, and skipping the first step risks a client that cannot manage the newer application.
On licensing, the repository is Apache-2.0. That permits commercial use, modification and redistribution, and it includes a patent grant. It also means you carry the obligations Apache-2.0 imposes, notably around preserving notices and stating changes. This is a description of the licence text, not legal advice; if you plan to redistribute a modified Nuwax, have counsel read the terms. The README's mention of Alibaba Cloud mirror acceleration and a Chinese mirror-switching install script suggests the primary user base is in mainland China, which may affect where you get support and how quickly issues in your locale are answered.
What you would use instead, and how it differs
The obvious comparison is Dify, another open source platform in the same territory: agent and workflow building, knowledge base, model management, self-hosted via Docker Compose. The difference in approach is where the execution boundary sits. Dify's documented deployment centres on a single Compose stack that you run and scale as one unit. Nuwax splits the sandbox into a tier you can place on separate servers and register by address from the main service. If your agents need to execute code or operate a desktop-like environment, and you want that execution isolated from the control plane and scaled independently, Nuwax's topology is the more direct fit. If you want one stack to run and one thing to upgrade, Dify's model is simpler.
A second comparison is LangGraph or the OpenAI Agents SDK. Those give you orchestration primitives and leave hosting, knowledge storage and model routing to you. Nuwax is the opposite trade: you accept Docker and a CLI as the price of getting memory, knowledge base, model proxy and a plugin layer already assembled. Choosing between them is choosing whether you want to own the assembly or inherit it.
A third option worth naming is running the agent inside your existing chat platform's own bot framework, for example a Feishu or DingTalk bot backed by your own service. Nuwax's frontend layer already targets those IM clients, so if that is your only surface, the platform's value depends entirely on whether the knowledge base, memory and model proxy components are better than what you would build. Nothing in the README lets you settle that question, and that is the honest answer.
Who should deploy Nuwax, and what to check first
Adopt Nuwax if you are an infrastructure or platform team that wants an agent platform running on your own hardware, you already operate Docker Compose in production, and you expect to need isolated execution environments that scale separately from the control plane. The Apache-2.0 licence and the CLI-driven lifecycle make it a reasonable fit for an internal deployment where you control the hosts.
Do not adopt it if Windows is your deployment target. The README lists Windows 10 and 11 with support coming soon, which means the documented path does not cover it. Do not adopt it if you cannot tolerate periodic application downtime, because the documented backup procedure stops the Docker application servers. And do not adopt it on the strength of the README alone if your decision hinges on the agent authoring model, the plugin interface, or the sandbox isolation mechanism, because none of those are described in the material available here.
What to verify before you commit hardware: run `docker compose version` and confirm V2, since the README requires it; run `docker ps` as the deploying user to confirm Docker permissions rather than planning to use sudo; read the agent-computer-deploy page to learn what the sandbox actually is before you budget servers for it; and check whether the weekly release cadence visible in the release list matches the change window your team can absorb, given that `./nuwax-cli auto-upgrade-deploy run` is a deployment action, not a notification.
Editorial conclusion
Adopt Nuwax if you need an agent platform you host yourself, your team already runs Docker Compose on Ubuntu 22.04 or macOS, and you want the sandbox tier on separate machines. Do not adopt it if you need Windows deployment today, since the README marks Windows 10/11 support as coming soon, or if you want a single binary with no Docker dependency. Before committing, run `./nuwax-cli docker-service status`, confirm `docker compose version` reports V2, and check that the release cadence visible in the repository matches your upgrade window.
Community notes