What your security review asks first.
Access, audit log, hardening
Roles and sign-in, encryption, a log the database itself protects, checked releases with SBOMs, and a plain list of what does not exist yet.
Self-assessment at level 2
All 253 requirements checked one by one against code, tests and configuration, with the result per level.
What the AI may do and what is stored
Your own provider and key, no prompt text stored by default, no training on your data, your own network only if you wish.
Docker Compose or Kubernetes.
The whole application in one step
A small server with 2 vCPU and 4 GB of memory is enough for a pilot; 8 GB is recommended. Requirements, backup and update are documented.
One namespace, no cluster-wide rights
Every container runs as a non-root user with a fixed UID, on a read-only root filesystem, with all Linux capabilities dropped, tested with Pod Security “restricted”. PostgreSQL and S3-compatible storage come from your platform or run in the same namespace. Traffic arrives through your Ingress or Gateway API.
Two ways in, both signed.
From our registry
Your platform pulls the images with its own per-customer access, which can be revoked at any time. Or your mirror, such as Harbor or Artifactory, fetches them for you.
As a handover archive
Each release as an archive with images, Helm chart, SBOMs and scan results. It loads into your own registry without internet access.
Every image is signed and can be verified with our public key, also after it has moved into your registry.
Your model, your network.
Your own model
A model server with an OpenAI-compatible interface on your own network, proven with Ollama and llama.cpp. Then no document leaves your environment. Only the model server needs a GPU, not OpsCodex.
Any other endpoint
Any model with an OpenAI-compatible API, in your own data centre or in the cloud, such as those from Anthropic, OpenAI, Google or Mistral. Under your own contract, switchable in the admin UI.
What your own model needs
For your own AI assistants, such as Microsoft Copilot, there is an MCP interface: read-only, approved processes only, opened per token, and every access is logged.
Light and scalable.
The AI runs on the model server, not inside OpsCodex. That keeps the application itself small.
Updates you can plan.
Rhythm
About one release a quarter, named after its month. Nine months of fixes for high and critical vulnerabilities, a monthly patch day, and a critical fix does not wait for it.
A gate before every release
Only what passed the gate ships: a cold start on empty volumes, a smoke test, a Trivy scan of every image and an attack from outside on the running application with OWASP ZAP. A severe finding stops the release. The images you get are the ones that were tested, each with an SBOM.
You decide
Nothing updates itself. Every release says what an update involves and whether it can be rolled back without restoring the backup.
More on access, the audit log and what does not exist yet: Security → · Evaluating OpsCodex →
See OpsCodex on one of your own processes.
Bring a PDF, a slide deck or a messy SOP, or use our sample data. In one hour we run the process end-to-end — draft, approval, export — and the concierge answers questions on it. Afterwards you get the process and an analysis report.
“In our consulting projects we spent weeks working through interviews, and in the workshop everyone still described the same process differently. Gaps and overlaps surfaced late, and the approved version vanished into a repository. We built OpsCodex for the whole road: from the draft through optimisation to the work that follows.”
Tillmann Schatz · Product owner OpsCodex, Senior Manager at Mews PartnersOpsCodex is built by a team at Mews Partners.