GraphCanon updated today · GitHub synced today · 26 views this month
Decision brief
Nexent offers a zero-code platform for generating production-grade AI agents with Harness Engineering principles built into its framework.
Good fit when
- When you require unified tools and skills management through its Harness Engineering principles.
- For projects needing built-in constraints, feedback loops, and control planes to ensure agent reliability and performance.
Avoid when
- When a simpler, non-production grade solution is sufficient since Nexent's robust infrastructure might add unnecessary complexity.
- For environments lacking the recommended system resources such as 8 cores CPU, 16 GiB Memory, and 100 GiB Disk (for Kubernetes deployment), which can limit its performance and reliability.
- Requirements:
- Min 8 GB RAM; Requires Docker
Observed Jul 12, 2026 · Source: enrich:decision_facts
Verify the decision
Maintenance and security
Full trust report- Maintenance
- Very active (0d since push)
- As of today
- Provenance
- Not a fork · Organization account
- As of today
- Security (OSV)
- No lockfile
- As of 3w
Public GitHub metadata and optional OSV scans. Signals, not a guarantee. Trust methodology.
Install
pip install nexentHow it fits your stack(5)
Typed graph edges - alternatives, integrations, successors, and dependencies. Ranked by relationship type, not raw GitHub stars.
Alternative
Integrates
Relationship graph
Optional deeper exploration of typed edges and category neighbours.
Similar tools
Same-category neighbours not already linked as typed edges.
Evidence and technical details
Sourced facts, taxonomy, compatibility claims, README excerpt, and machine-readable endpoints.
Overview
Nexent is a platform designed to automatically generate production-grade AI agents using principles from Harness Engineering, supporting unified tools, skills, memory, and orchestration with built-in constraints, feedback loops, and control planes. The platform can be deployed via Docker or Kubernetes.
Capability facts
- Languages
- python
Source: github.language · Aug 18, 2026
Categories
Tags
README
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, data-process, and supabase 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 reads the same deploy/env/.env as Docker and renders explicit values into Helm ConfigMap and Secret overrides. Use --persistence-mode local|dynamic|existing, --storage-class/--sc, --local-path, --local-node-name, and `--existing-claim-p
For agents
This page has a .md twin and JSON over the API.