QgenticQgentic
Qgentic / deployment
Delivery engineering · every edition

Deployment your IT
will actually approve.

Every Qgentic edition ships the way enterprise IT already governs software: a signed artifact with a pinned identity, an egress table you can read in one glance, and updates only your change process applies. Cloud when you want nothing installed; your own hardware when the data cannot leave.

Contact Sales Security & evidence

Nothing Qgentic ships updates itself. That is architecture, not a setting.

One Engine, Four Postures

Choose Where It Runs — the Software Does Not Change

The edition is configuration, not a fork. A fix or feature reaches every deployment model from the same codebase, through the delivery discipline below.

Qgentic Cloud

Nothing to install. The console is a browser page, the API is HTTPS, tenants are isolated by construction, and TLS terminates at our ingress. Delivery questions move to our side of the line — your estate never changes. Pricing →

Qgentic Dedicated

The same gateway, one tenant, its own stack — operated by Qgentic in a dedicated environment or your cloud account. Isolation without operating software yourself. Talk to sales →

On-Premise (Connected)

One hardened container on your Linux host. Your reverse proxy fronts it with your internal-CA certificate; the only outbound flows are the ones your change request approved — HMRC for live filing, optionally our signed release feed. First boot self-provisions from a sealed profile.

Air-Gapped

No egress at all — enforced in-process, logged when refused, testable on delivery. A sealed executable or offline container; updates travel your own transfer process as verified tarballs. Air-gapped edition →

Supply Chain

The Artifact Carries Its Own Case

A vendor-risk review should read the artifact, not chase the vendor. Everything a security architecture needs to verify travels with the delivery.

1 · Pinned Identity

Digest, Not Tag

Your compose file names the exact image by its sha256 digest. A version bump is a one-line diff a change reviewer reads in seconds — never a floating tag that means something different tomorrow.

2 · Signed & Attested

Sigstore + SBOM

Every image is cosign-signed and attested with a CycloneDX software bill of materials. The public key ships in the delivery kit; verification is one command, or a rule in your admission policy.

cosign verify --key qgentic-cosign.pub qgentic.azurecr.io/qgentic@sha256:…
3 · Scanned & Rebuilt

Your Scanner Goes First

Releases gate on a critical-severity scan before publication and the base image is rebuilt monthly. Mirror-first is the default posture: pull once with a scoped token, scan and promote in your own registry — the runtime host needs no vendor egress at all.

4 · Hardened by Default

Posture in the Artifact

Non-root user, read-only root filesystem, all capabilities dropped, no privilege escalation, bounded resources, a health endpoint, structured logs to stdout. Declared in the shipped compose file — where a security review actually reads it — not in an appendix.

Change Control

Updates Your IT Applies. On Rails.

Auto-updating server software fails vendor risk review, so we never built it. There is no auto-update capability to disable. The update mechanism is your operations team — with the tedious parts done properly.

  1. A release is announcedwith its digest, release notes, migration notes and a security flag — in a release manifest signed with the same key discipline as our licences. A tampered manifest fails verification whatever a proxy did to the transport.
  2. Your team verifiesthe cosign signature (or your registry pipeline already did), and the rail refuses to continue without a fresh, verified snapshot of the evidence store.
  3. One line changesthe pinned digest in the environment file — the whole reviewable diff — then the stack restarts and health-checks itself.
  4. Rollback is symmetricalthe previous digest is recorded before anything moves; reverting is one command, plus the snapshot when a migration ran. The update itself lands in the audit chain: version from, version to, who ran it.
./qgentic-update.sh sha256:<new digest> # verify → snapshot gate → switch → health
The update rail: our release, your verification, your switch, one audit entry A release ships as an Ed25519-signed manifest with a pinned sha256 digest and a cosign-signed image with a CycloneDX SBOM — and no auto-update: no updater daemon exists. Your team verifies the signatures in your own change process — mirror, scan, promote — and the rail refuses to move without a fresh, verified snapshot of the evidence store. The switch is one command over one pinned digest, the whole reviewable diff, followed by a health check; rollback is symmetrical because the previous digest is recorded before anything moves. The update itself lands on the audit chain — version from and to, who ran it, when — and security releases state the oldest supported version so a change board can expedite on facts. § OUR RELEASE § YOUR VERIFICATION § THE SWITCH § THE RECORD Release manifest pinned sha256 digest Ed25519-signed, verified Signed image cosign + CycloneDX SBOM critical-scan gated No auto-update no updater daemon exists architecture, not a setting Your team, your change process cosign verify --key qgentic.pub manifest signature re-checked mirror → scan → promote SNAPSHOT GATE No fresh, verified backup — no update. The rail refuses. tampered manifest = hard fail, whatever a proxy did in transit ONE LINE CHANGES ./qgentic-update.sh sha256:… verify → snapshot → switch → health-check The reviewable diff is one pinned digest in one file. ROLLBACK IS SYMMETRICAL The previous digest is recorded before anything moves — reverting is one command. The audit entry version from → to who ran it · when the update itself lands on the audit chain security: true expedite on facts — oldest supported version stated in the manifest your CAB reads a document Nothing Qgentic ships updates itself — a release becomes an update only when your team applies it: verified, snapshot-gated, one-line diffed, recorded.
The update rail. A release arrives signed twice — the image by cosign, the manifest by the same Ed25519 discipline as the licence — and becomes an update only when your operations team runs it: backup verified first, one pinned digest changed, health-checked, rollback symmetrical, and the change itself recorded on the audit chain.

Security releases carry security: true and the manifest states the oldest version still supported — so your change board expedites on facts, not adjectives.

Near-Zero Setup

Pre-Configured Before It Arrives

The Sealed Profile

Your deployment — organisation, packs, data source, approval policy, named people — is sealed and signed at our HQ and verified by the software against a compiled public key. It carries no live credentials: signed is not encrypted, so secrets are entered once, on your box, by you.

First Boot Provisions

On a pristine host the container provisions its tenant and people from the sealed profile and refuses to boot on a tampered one — loudly, at install time, not weeks later. Reboots are no-ops.

People Activate

Named users activate with one-time codes from the printed hand-over pack; only hashes ever exist in files. The single per-user credential Qgentic never touches: each person's own HMRC sign-in, done in their own browser.

IT Engagement

The Change Request Arrives Pre-Answered

Before anything ships, we run a 22-question survey with your IT — container runtime, registry path, proxy and TLS inspection, egress rules, backup and retention, what evidence your CAB requires. The output is the change request your IT department submits: system description, the exhaustive egress table, install method, update governance, backout plan, SBOM annexes.

Your change board gets a document, not a discovery meeting.

FAQ

Frequently Asked Questions

Does anything update itself?

No. No Qgentic edition contains an auto-update path; deployment profiles only permit "notify" or "none". Updates are applied by your operations team through your own change process, using the shipped update rail or your registry promotion pipeline.

What outbound access does an on-premise install need?

At most three flows, each named in the change request: HMRC APIs for live filing, an optional read-only check of the signed release manifest, and an optional SMTP relay for notifications. The air-gapped edition needs none and refuses all outbound requests by architecture.

How do we verify what we received?

Cosign signature on the image digest, SHA-256 sums on every file in the delivery kit, a CycloneDX SBOM, and an Ed25519-signed release manifest. After every run, hash-chained audit logs re-verify offline on any machine.

Can our registry pipeline mirror the image?

Yes — mirror-first is the default for strict estates: pull once with a scoped, revocable token, then scan, promote and deploy from your internal registry. The runtime host never needs vendor egress.

What changes with the SaaS edition?

Nothing installs. The console and API are HTTPS, tenants are isolated by construction, and every filing still pauses for a named person approval recorded in the audit chain. The delivery discipline on this page runs on our side of the line instead of yours.

How fast do security fixes reach us?

The signed release manifest flags security releases and states the oldest version still supported; your named contact is notified for an expedited pass through your change process. On Cloud, we apply them ourselves.

The change request is pre-answered. Ask for the IT questionnaire and we return the document your change board needs. Contact sales.