@aopslabs/aops-server

The ready-to-run aops Server package contains the application runtime, Cockpit, and aops PostgreSQL/SQLite migration support.

Install only the operator CLI. Its exact dependency brings this Server:

npm install --global @aopslabs/aops
aops

The one-page TUI selects SQLite or an existing PostgreSQL connection with TLS, checks readiness, and applies aops setup/migrations through explicit actions. Test never saves the candidate or changes database content/services; Connect is separate. SQLite Test may create WAL coordination sidecars. SQLite requires Node.js 22.16+ and a file on the Server machine. Multiple client computers use the Server API, not a shared database file. Database switching does not transfer data. PostgreSQL is operator-owned: aops does not install, provision, start, stop, or remove it. The local API defaults to http://127.0.0.1:5900.

For headless operation inspect aops setup init --help. Use aops server status, aops server health, and aops server stop for the aops service. Remote-only CLI users may leave the local Server dependency unconfigured and select another existing Server.

The PostgreSQL host owns one XF connection resource per kernel generation. Agentspace, ChatV3, Docman, Projectman, Sys and Tasker borrow the aops binding; their existing repositories, services and transactions remain domain-owned. The app's Agentspace flow helpers borrow the same resource. Reset/shutdown stops intake, drains accepted operations (including work whose HTTP response already timed out), closes captured plugin resources, then closes the pool. A failed close retains that generation for an explicit retry. Separate hosts and legacy standalone clients retain their own connections. SQLite keeps its existing native host/file ownership rules.

Source and contributor instructions live in the parent aops-platform README and the canonical aops-system document. Public npm distribution does not grant an open-source license.