ComOps is software you install, not a service you rent a seat in. It runs on a server you control: a machine in your own building, or a virtual server at whichever cloud provider you choose and pay directly. The database, the uploaded files and the backups sit on that infrastructure, and nobody else holds a copy of them.
Both are the same installation. On your own hardware you have a Linux machine, a web server, PHP and MariaDB, and ComOps on top of them. At a cloud provider you have a virtual server of the same shape, in a region you pick, on an account that is yours and billed to you. The choice is about who racks the hardware, not about what the software does or where the data can be read from. In both cases the instance is yours, on your domain, with your database behind it.
ComOps is written in PHP 8.3 against MariaDB, with no framework underneath it and no dependency tree to resolve. There is no build step and no asset pipeline: the files you deploy are the files that run, and a deployment is the code plus the schema and nothing else. The requirements are short. A Linux server, Apache with mod_rewrite in front of PHP-FPM, PHP 8.3 with the usual extensions, MariaDB behind it.
There is no analytics, no telemetry, no error-reporting service and no vendor SDK anywhere in the application. Nothing measures how you work and nothing reports it. ComOps depends on no third-party service in order to run: the one network path it genuinely needs is the mail server you configure it to send through, which is a server you choose, on credentials you hold. An administrator can ask the system check screen to test outbound reachability, and that is a button somebody presses.
One script takes a clean server to a running ComOps: the web server, PHP, the database, the application user, the background worker and its cron entries, ending at the setup wizard in your browser. The wizard starts from an empty database or from one of your own encrypted backups, so rebuilding a server is a restore rather than a re-entry. After that, every schema change ships as a numbered migration with its rollback file beside it, and the migration tool takes a backup before it touches anything unless you tell it not to.
A backup is a single encrypted archive holding the database dump and the uploaded files, protected by a passphrase you set and keep. It runs on demand from the admin screens or from cron on a schedule you decide, and it lands where you point it, so your archives live where your own policy says they live. Restoring is that same file read back, and the checks below are how you confirm the restored books still add up.
ComOps ships with a verification harness that drives whole business flows from end to end, and a set of read-only invariant checks that ask the database whether the books still hold: outstanding balances that match an independently computed figure, allocations that point at live invoices, plus stock, bank, VAT, numbering and audit-chain health. They run inside a read-only transaction, they can be run on a schedule, and they exit non-zero the moment an invariant breaks. Beside them sits an automated test suite that runs entirely offline against a local database. The access controls those checks sit next to are described on the security page.
A Linux server with PHP 8.3 and MariaDB, a web server in front of them, one cron minute for the background worker and a five-minute entry for its watchdog, and an SMTP server to send mail through. Storage is a single directory.
Only the mail ComOps sends through the SMTP server you configure. There is no analytics, no telemetry and no third-party service in the runtime path.
Want to see it running against a dataset of your own shape?
