Nixopus: an AI agent that deploys and repairs your apps on your own VPS
Run production apps without thinking about infrastructure. On your server or ours. Fully agentic.
At a glance
- What is it?
- Nixopus is a Go-based, self-hostable deployment platform whose selling point is an AI agent that generates configs, ships containers, and (eventually) opens fix PRs when a deploy breaks. It is early alpha software with an unclear licence, and the healing loop is still marked in development.
- Who is it for?
- Nixopus fits engineers who already run a VPS, are comfortable with container-based deploys, and want a dashboard plus an agent that writes build configs for them. It does not fit teams that need a stable release line, a clearly identified licence, or automated failure remediation today, because the README itself marks the self-healing step as in development.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Go, 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 gap Nixopus claims: config generation and failure triage, not just hosting
Most self-hosted deployment tools assume you already know what a Dockerfile should contain. Nixopus targets the step before that. According to the README, the agent "analyzes your codebase, generates the right config, and deploys", and the project describes itself as framework agnostic: Next.js, Django, Rails, Go, FastAPI and Compose stacks are all listed, with the boundary stated as anything that runs in a container image. The intended user is someone with a server and a repository who does not want to hand-write build configuration or sit in a terminal wiring up a reverse proxy. The second audience is teams already paying for a managed platform who want the same push-to-deploy loop on hardware they control. The README frames the self-hosted edition as having "full feature parity" with the cloud version and being free forever, which is a licensing and business-model claim rather than a technical one, and it is the kind of claim worth re-checking against the repository itself.
How the pieces fit: repo connection, agent, containers, Caddy
The documented flow has four steps. You link a GitHub account and pick a repository. You ask the agent to deploy, either from the dashboard or from a VS Code or Cursor extension. The agent reads the codebase and produces build configuration. The app is then run as a container and given a URL with TLS. The README attributes TLS to Caddy, with certificates "provisioned and renewed automatically via Let's Encrypt". Domains are handled inside the product: the example given is telling the agent "add domain app.mysite.com", with DNS verification and SSL handled for you. Rollbacks reuse retained images rather than rebuilding, so a revert is not a full pipeline run. The agent is also reachable through a chat interface where you can tag resources as `@App`, `@Container` or `@Domain` to scope a request. That tagging syntax is the most concrete detail in the README about how the agent avoids ambiguity when a project has several services. The repository is primarily Go, with TypeScript also listed among the topics. The failure-recovery loop, where the agent reads logs and raises a pull request with a fix, is explicitly labelled "in development", so today the autonomous part covers config generation and deploy, not repair.
Installing it: one curl, environment variables, and an LLM key
The README gives a single install command: `curl -fsSL install.nixopus.com | sudo bash`. A second form passes configuration as environment variables on the same line: `curl -fsSL install.nixopus.com | sudo DOMAIN=panel.example.com ADMIN_EMAIL=admin@example.com OPENROUTER_API_KEY=sk-or-xxxxx bash`. A third shows the provider being swapped, with `LLM_PROVIDER=anthropic` and `ANTHROPIC_API_KEY`. Two things follow from that. First, the agent is not running a model locally; you supply a key for an external provider, and the README's examples cover OpenRouter and Anthropic. Second, `DOMAIN` and `ADMIN_EMAIL` are install-time inputs, which means the panel's own hostname and the certificate contact address are decided before the stack is up. The README points to a separate installation guide for the full configuration reference, and the truncated command list ends mid-line, so the complete set of accepted variables is not visible in the material available here. Piping a remote script into a root shell is a real trust decision, and the documentation does not show a checksum or a signed release artefact alongside it.
Where it will bite: alpha versioning, an unclear licence, and a repair loop that is not finished
The release history is the clearest signal. The most recent tags are `v0.1.0-alpha.168`, `v0.1.0-alpha.167` and `v0.1.0-alpha.166`. An alpha line that has reached its hundred-and-sixty-eighth revision suggests rapid iteration, and equally suggests that interfaces, install behaviour and configuration keys may move between releases. Treat any deployment you build on it as something you can rebuild. The licence field is reported as NOASSERTION, which means the repository does not expose a recognised licence identifier. The README claims self-hosting is "free forever with full feature parity" and that there is "no lock-in", but a stated intention in a README is not the same as a licence grant, and for a platform that runs your code and holds your API keys, the terms matter. Read the actual licence file in the repository rather than the marketing sentence. The third limitation is the one the project states itself: the agent that watches for failures and opens fix PRs is marked in development. If you adopt Nixopus expecting unattended remediation, you are adopting a roadmap item. The agent also depends on an external LLM provider, so quality of generated configuration varies with the model you point it at, and your source context is being sent to that provider.
How it differs from Coolify and Dokploy
Coolify is the obvious comparison, and it appears in the repository's own topic list. Coolify is a self-hosted control plane over Docker and Docker Compose: you choose a build pack, set environment variables, and the platform handles the reverse proxy, certificates and container lifecycle. Its model is deterministic. What you configure is what runs, and a failed build gives you a log to read. Nixopus changes the input to that process. Instead of selecting a build pack, you describe the intent and an agent derives the configuration. That is a different failure surface: when a Coolify build fails, the cause is in your Dockerfile or your environment variables. When an agent-generated configuration fails, the cause may be in the generated file itself, and you need to be able to read and override that output. The README does not describe an escape hatch for hand-editing generated configuration, which is the question I would want answered before moving a real workload onto it. The trade-off is explicit: Coolify gives you reproducibility and a smaller dependency surface; Nixopus gives you less configuration work in exchange for a model provider in the loop.
Maintenance, upgrades and what the licence status implies
Self-hosting a platform that manages your own infrastructure means you own its upgrades too. The README does not describe an upgrade path for an existing installation, nor does it state whether the install script is safe to re-run over a live panel. With an alpha release cadence this matters more than usual: a hundred-plus alpha tags in a short window implies you will want a way to pin a version and roll the panel back if an upgrade breaks the dashboard that manages your apps. The licence situation deserves the same caution. NOASSERTION on the repository metadata means no recognised licence was detected, so the permissions you have are whatever the repository's own licence file says, and that is the document to read before you build a business process on top of it. Nothing here is legal advice; the practical point is that "open source and self-hostable" in a README and a permissive licence in the repository are two separate facts, and only one of them is checkable from the metadata.
Editorial conclusion
Nixopus fits engineers who already run a VPS, are comfortable with container-based deploys, and want a dashboard plus an agent that writes build configs for them. It does not fit teams that need a stable release line, a clearly identified licence, or automated failure remediation today, because the README itself marks the self-healing step as in development. Verify three things before adopting: the actual licence text in the repository, the LLM provider and API key you will supply, and whether the install script's default Caddy and Let's Encrypt setup can coexist with anything already bound to ports 80 and 443 on the host.
Community notes