Nexent is a zero-code platform for auto-generating production-grade AI agents, built on Harness Engineering principles. It provides unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes — no orchestration, no complex drag-and-drop required, using pure language to develop any agent you want.
One prompt. Endless reach.
🚀 Get Started Now
⭐ Before you get started, please star us on GitHub — your support drives us forward!
Deploy on Your Own
If you need to run Nexent locally or in your private infrastructure, we offer two deployment options:
System Requirements
| Resource | Docker | Kubernetes |
|---|
| CPU | 4 cores (min) / 8 cores (rec.) | 4 cores (min) / 8 cores (rec.) |
| Memory | 8 GiB (min) / 16 GiB (rec.) | 16 GiB (min) / 64 GiB (rec.) |
| Disk | 40 GiB (min) / 100 GiB (rec.) | 100 GiB (min) / 200 GiB (rec.) |
| Architecture | x86_64 / ARM64 | x86_64 / ARM64 |
| Software | Docker 24+, Docker Compose v2+ | Kubernetes 1.24+, Helm 3+ |
Note: Recommended configurations ensure optimal performance in production environments.
Docker Deployment (Recommended for Individuals/Small Teams)
Quick and straightforward for most users. Prerequisites: Docker 24+ and Docker Compose v2+:
git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh docker
The root deploy.sh only forwards to the target deploy script; the native Docker implementation is bash deploy/docker/deploy.sh. The Docker and Kubernetes deploy scripts share the same deployment configuration model. Interactive runs show Bash TUI menus for component selection, port policy, and image source. infrastructure is required; application and data-process are selected by default and can be disabled when you want a smaller deployment. Use b/Backspace to return to the previous TUI step and q to quit. Use --defaults to skip the TUI and deploy with saved deploy.options or built-in defaults. Non-interactive runs can also pass the same choices with --version, --components, --port-policy development|production, and --image-source general|mainland|local-latest. Successful deployments save non-sensitive choices to each deploy directory's deploy.options for reuse on the next run.
Docker and Kubernetes both use deploy/env/.env as the runtime configuration file. Existing deploy/env/.env is kept as-is. If it does not exist, the deploy scripts first reuse docker/.env, then fall back to deploy/env/.env.example. Monitoring-specific settings are generated from deploy/env/monitoring.env.example into deploy/env/monitoring.env.
Docker uninstall is handled by bash uninstall.sh docker. It can preserve or delete data volumes: run it interactively, pass --delete-volumes true|false, or use bash uninstall.sh docker delete-all to remove containers and persistent data.
Offline image packages can be built with bash build.sh --package --target docker --compress true or bash deploy/offline/build_offline_package.sh --target docker --compress true. The package includes image tar files, load-images.sh, push-images.sh, root deploy/uninstall entrypoints, deployment scripts, SQL files, manifest.yaml, and checksums.txt. Package deploys use saved deploy.options or built-in defaults without opening the TUI; add --config to configure interactively. Deploy with bash deploy.sh --load-images docker ... on the target host, or use bash deploy.sh --push-images --image-registry-prefix registry.example.com/nexent docker ... to push loaded images to an internal registry and deploy with that image prefix. When --push-images is used without a prefix, deploy.sh asks for it before push-images.sh prompts for the registry username and password.
For detailed deployment instructions, see Docker Installation.
Kubernetes Deployment (For Enterprise Production)
Ideal for enterprise scenarios requiring high availability and elastic scaling. Prerequisites: Kubernetes 1.24+ and Helm 3+:
git clone https://github.com/ModelEngine-Group/nexent.git
cd nexent
bash deploy.sh k8s
The native Kubernetes implementation is bash deploy/k8s/deploy.sh. It installs two independent Helm releases: nexent-infrastructure for Elasticsearch, PostgreSQL, Redis, and MinIO, then nexent for application services after infrastructure and the Elasticsearch API key are ready. Use --release-scope all|infrastructure|nexent to operate both releases or either side independently. The script reads deploy/env/.env and renders explicit Helm ConfigMap and Secret overrides. Use --persistence-mode local|dynamic|existing, --storage-class/--sc, --local-path, --local-node-name, and --existing-claim-prefix to control PVC behavior.
Kubernetes uninstall is handled by bash uninstall.sh k8s. By default it removes nexent first and nexent-infrastructure second. The same --release-scope option supports application-only removal and dependency-protected infrastructure removal.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
