# Nixopus: a self-hosted deployment platform with an agentic deploy loop

> Nixopus pairs a Go control plane and Docker Compose stack with an AI agent that generates configs, deploys containers and, per the README, opens a PR when a deploy fails. It is alpha software and the self-healing step is still marked in development.

**nixopus/nixopus** — Run production apps without thinking about infrastructure. On your server or ours. Fully agentic.

- Repository: https://github.com/nixopus/nixopus
- Website: https://nixopus.com
- Stars: 1,467 · Forks: 136
- Language: Go
- License: NOASSERTION
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/nixopus-nixopus

## What Nixopus actually replaces

The README frames the target user narrowly: someone with a repository and a server who does not want to assemble a deploy pipeline by hand. Nixopus runs on your own machine or on Nixopus Cloud, and the pitch is that the agent handles the lifecycle from codebase analysis to a live URL with TLS. The repository layout backs the self-hosted claim. There is a docker-compose.yml, an installer/ directory, a .env.sample with database, Redis, Caddy and SSH settings, and an api/ directory written in Go. The view/ directory holds the dashboard front end, and the package.json lists a separate CLI versioned independently of the platform (0.1.45 against platform 0.1.0-alpha.168), with packages for .deb, .rpm, .apk, a Darwin arm64 .pkg and a tarball. That is a real distribution surface, not a single Docker image.

The honest framing is that this is a Heroku or Vercel shaped product pointed at your own VPS. It is not a Kubernetes operator and it is not a CI system. If your problem is "I have a repo and a $5 server and I want a URL with HTTPS without writing a deploy script," Nixopus addresses exactly that. If your problem is multi-region rollouts with canary analysis, the README puts load balancing and automated scaling on the roadmap, which means they are not there yet.

## How the agent and the control plane fit together

The data flow described in the README is: you connect a GitHub account and pick a repository, then ask the agent to deploy from the dashboard or from the VS Code and Cursor extension. The agent analyzes the codebase, generates build configuration, and ships the app. The README says the agent detects your stack, naming Next.js, Django, Rails, Go, FastAPI and Compose stacks, and that anything running in a container image can be deployed.

The runtime side is visible in docker-compose.yml. A nixopus-api service built from ghcr.io/nixopus/nixopus-api:latest listens on port 8443 and exposes /api/v1/health for its healthcheck. It mounts the Docker socket at /var/run/docker.sock, which is how it manages containers on the host, and it mounts ${NIXOPUS_HOME:-/etc/nixopus} for configuration. A nixopus-db service runs postgres:14-alpine under the local-db profile, bound to 127.0.0.1 on ${DB_PORT:-5432}, with scram-sha-256 authentication and connection logging enabled. The API depends on the auth service at http://nixopus-auth:9090. Caddy handles TLS, with CADDY_PORT=2019 and data and config volumes under /etc/nixopus/caddy in .env.sample.

The trade-off is the Docker socket mount. Giving the API container direct control of the host daemon is what makes single-command deploys possible, and it is also the most privileged thing in the stack. Anyone who reaches the panel effectively reaches the host. The README does not discuss that boundary, and .env.sample ships SSH_PASSWORD=nixopuspassword and PASSWORD=changeme as defaults, so the first thing to change after install is those values.

## Installing Nixopus on a VPS and deploying a first app

The README gives a one-line installer for self-hosting. It fetches a script from install.nixopus.com and runs it under sudo.

```bash
curl -fsSL install.nixopus.com | sudo bash
```

The README also documents passing a custom domain, an admin email and an OpenRouter key as environment variables on the same command, which is the form to use if you want the panel on a real hostname from the start.

```bash
curl -fsSL install.nixopus.com | sudo DOMAIN=panel.example.com ADMIN_EMAIL=admin@example.com OPENROUTER_API_KEY=sk-or-xxxxx bash
```

A third documented form switches the LLM provider, here to Anthropic.

```bash
curl -fsSL install.nixopus.com | sudo LLM_PROVIDER=anthropic ANTHROPIC_API_KEY
```

If you would rather run the stack yourself, the repository ships docker-compose.yml and a .env.sample to copy from. The sample sets API_PORT=8443, NEXT_PUBLIC_PORT=7443, DB_PORT=5432, REDIS_PORT=6379 and AUTH_SERVICE_PORT=9090, along with ALLOWED_ORIGIN and CORS_ALLOWED_ORIGINS that must match your domain.

```bash
cp .env.sample .env
# edit .env: set PASSWORD, REDIS_PASSWORD, AUTH_SERVICE_SECRET, ALLOWED_ORIGIN
docker compose up -d
```

After that, the first real use is the flow from the README: link your GitHub account, select a repository, and tell the agent to deploy. You should end up with a running container and a URL served over HTTPS, with TLS provisioned through Caddy and Let's Encrypt. If the deploy fails, the README's described behaviour is that the agent reads the logs and raises a PR with a fix, but that step is labelled in development, so expect to read the logs yourself in the dashboard terminal for now.

## Where Nixopus is the wrong tool

The release history is the first limitation. The most recent release listed is v0.1.0-alpha.168, and the version in package.json is 0.1.0-alpha.168. Everything is on an alpha line. The last push to the repository was on 2026-09-06, so the project is being worked on, but an alpha version string means you should not treat an upgrade as a routine operation. The README does not document rollback of the panel itself, only rollback of your deployments, where it says previous images are retained so a rollback does not require a full rebuild.

The second limitation is scope. The README lists multi-machine deployments, load balancing and automated scaling as roadmap items. If you need any of those today, Nixopus will not provide them, and the multi-server feature as documented is monitoring CPU, RAM and running apps across a fleet from one dashboard, not orchestrating a distributed deployment.

The third is the agent itself. The README is explicit that the failure-fix loop is in development. The chat interface, config generation and deploy path are the parts described as working. If autonomous repair is the feature you are buying, that part is a promise in the README, not a shipped capability. And because the agent runs against your codebase and your LLM provider key, the deploy path depends on an external model API being reachable and on your key having quota.

## Nixopus compared with Coolify, Dokploy and plain Docker Compose

The nearest comparison is Coolify, which the repository lists as a topic alongside Heroku, Netlify and Vercel. Coolify is also self-hosted and also manages containers on your server from a web UI. The difference in approach is the agent. Coolify's model is that you configure the application, the build and the domain, and the platform executes. Nixopus inverts part of that: the README says the agent analyzes the codebase and generates the configuration, so the user is expected to describe intent rather than fill in a build form. That is a genuine difference, and it is also the part that is hardest to verify without running it, since the generated config depends on the model behind OPENROUTER_API_KEY or ANTHROPIC_API_KEY.

Against plain Docker Compose, Nixopus adds TLS through Caddy, domain verification, deployment history with image retention, an in-browser terminal and container view, and the chat layer. If your deployment is a single compose file that rarely changes, Nixopus is more moving parts than you need: an API container with the Docker socket, Postgres, Redis, an auth service and Caddy, all to replace a command you already type by hand. The value shows up when you are deploying several apps across more than one server and want one place to see them.

## Licence, upgrade cost and what to check in the repo

The repository's package.json declares AGPL-3.0-or-later, while the GitHub metadata reports the licence as NOASSERTION, meaning the platform could not classify the LICENSE.md file automatically. Those two signals disagree, and the file that settles it is LICENSE.md at the repository root. The README markets self-hosting as free forever with full feature parity and no lock-in. That is the project's own claim, not a legal position. If you intend to offer Nixopus as a service to third parties, or to modify and redistribute it, read LICENSE.md and the AGPL text rather than the README's summary. This is not legal advice.

The upgrade cost is the alpha cadence. Releases are numbered as patch increments on an alpha line, and the CLI carries its own version (0.1.45) with separate packages per platform. That means two things to track when you upgrade: the platform version and the CLI version, which move independently. The compose file pins the API image to the latest tag, so a pull can move you forward without you choosing a version. For anything you depend on, pin the image tag instead of relying on latest, and keep the .env file outside the image, since docker-compose.yml mounts it from ${NIXOPUS_HOME:-/etc/nixopus}/source/api/.env.

## Conclusion

Adopt Nixopus if you run one or a few VPS machines, already work in containers, and want the deploy agent plus the in-browser terminal and log view without a managed vendor. Do not adopt it if you need a stable release line or if the agentic failure-fix loop is the whole reason you are looking: the README marks that step as in development. Before installing, read installer/ and docker-compose.yml, replace PASSWORD, REDIS_PASSWORD and AUTH_SERVICE_SECRET from .env.sample, and confirm the AGPL-3.0-or-later terms in LICENSE.md against how you plan to run the panel.

## FAQ

### How do I install Nixopus on my own server?

The README gives a one-line installer: curl -fsSL install.nixopus.com | sudo bash. You can pass DOMAIN, ADMIN_EMAIL and an LLM key such as OPENROUTER_API_KEY or ANTHROPIC_API_KEY as environment variables on the same command.

### Does Nixopus need an external LLM provider key?

The installer examples pass OPENROUTER_API_KEY or switch with LLM_PROVIDER=anthropic and ANTHROPIC_API_KEY, so the agent path depends on a model provider being configured. The README does not describe running the agent without one.

### What are the requirements for self-hosting Nixopus?

The README has a Requirements section under Self Hosting, but the details are not reproduced in the repository's top-level files. The compose stack needs a host running Docker, with ports 8443 for the API and 7443 for the dashboard by default in .env.sample.

### Can Nixopus fix a failed deployment automatically?

The README describes the agent detecting a failure, reading the logs, raising a PR with a fix and redeploying, but labels that step as in development. Treat config generation and deployment as the shipped path and automatic repair as not yet available.

## Sources

- [Issues](https://github.com/nixopus/nixopus/issues)
- [nixopus/nixopus on GitHub](https://github.com/nixopus/nixopus)
- [Project website](https://nixopus.com)
- [README](https://github.com/nixopus/nixopus/blob/master/README.md)
- [Releases](https://github.com/nixopus/nixopus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nixopus-nixopus