Product · Deployment

An offline kit for your own virtual machines

An offline kit for your own VMs; nothing phones home; AI is optional, off by default, and never touches the result.

LogVeil runs inside the customer’s network: the offline kit in the customer’s own virtual machines; the sanitised bundle and its attestation are the one thing that leaves, under the customer’s own release decision; nothing reaches Zindagi. THE CUSTOMER’S NETWORK — AIR GAP · NOTHING OUTBOUND OUTSIDE THE NETWORK Operator · Reviewer · Reverser · Auditor browser over HTTPS; seven roles, enforced OEM diagnostic bundle in upload or mounted path; never leaves the network raw Your policy, your key written and signed by the customer; generated and held in the deployment; Zindagi sees neither LogVeil offline kit in the customer’s own VMs · Docker Compose web — nginx one HTTPS origin;serves the app andproxies the API api every role check onevery request; auditof every change workers ingest · collectcompile · rewriteverify · attest database PostgreSQL; the jobqueue; no broker blob store filesystem or objectstore; inputs deletedafter the job ai-local optional; off bydefault; never changesa result THE MAP encrypted per job; reversalper token, two-person rule;hash-chained audit THE KEY unwrapped at start from theadmin’s passphrase; neverat rest in plaintext zero-egress test: a full job with outbound network blocked no telemetry · no update checks · no external font or script signed images · pinned compose · SBOM per image · signed manifest Sanitised bundle + attestation + report every value rewritten under the policy; non-assertions declared; verified by independent scanners before release Release decision: the customer’s own The vendor’s technical assistance centre receives the sanitised bundle and its attestation Zindagi no channel in or out: no copy of the bundles, the policy, the key, the map, the attestations or the audit log reaches us LogVeil runs inside the customer’s network: the offline kit in the customer’s own virtual machines; the sanitised bundle and its attestation are the one thing that leaves, under the customer’s own release decision; nothing reaches Zindagi. THE CUSTOMER’S NETWORK — AIR GAP Operator · Reviewer · Reverser · Auditor browser over HTTPS; seven roles, enforced on every request OEM diagnostic bundle in upload or mounted path; never leaves the network raw Your policy, your key written and signed by the customer; held in the deployment; Zindagi sees neither LogVeil offline kit in the customer’s own VMs · Docker Compose web — nginx one HTTPS origin api role checks; audit workers ingest … verify · attest database PostgreSQL; no broker blob store inputs deleted after ai-local optional; off by default THE MAP encrypted; per-token reversal THE KEY never at rest in plaintext zero-egress test · no telemetry · no update checks no external font or script · signed images SBOM per image · signed manifest Sanitised bundle + attestation + report every value rewritten under the policy; non-assertions declared; verified before release Release decision: the customer’s own OUTSIDE THE NETWORK The vendor’s technical assistance centre receives the sanitised bundle and attestation Zindagi no channel in or out — nothing reaches us

Drawn by code from the product’s specification; not a screen.

The kit

The offline kit

in development

LogVeil is delivered as an offline kit for the customer's own virtual machines: image tarballs for every service, a digest-pinned compose file, migrations inside the image, an installer that loads the images, sets up TLS from the customer's certificate authority or a bundled private one, seeds the first administrator and runs the smoke test, a signed SHA-256 manifest, a CycloneDX software bill of materials per image, and the corresponding-source archive or written offer for every copyleft binary shipped. Images are built for amd64 and arm64; hosts are Ubuntu 24.04 LTS or RHEL/Rocky 9 with no dependency beyond Docker. Docker Compose is the unit of deployment: an API service, worker replicas that scale horizontally, a PostgreSQL 16 database that also carries the job queue — no separate broker — a web service that serves the application and proxies the API from one origin, and an optional local-AI service; blob storage on the filesystem or an S3-compatible backend.

What the kit contains

  • signed image tarballs
  • a digest-pinned compose file
  • installer and migrations
  • a software bill of materials per image
  • signed checksums
  • the source archive or written offer for every GPL component shipped

For the customer’s own virtual machines, on amd64 and arm64, on Ubuntu 24.04 LTS or RHEL/Rocky 9.

Zero egress

The installer's smoke test runs a full job with the virtual machine's outbound network blocked and asserts that no connection was attempted; no component checks for updates; there is no telemetry, no external font, no external script. Hardening in early access: no privileged containers, read-only root filesystems where possible, AppArmor or SELinux enforcing, TLS 1.2 or later only with HSTS, secrets supplied as files rather than environment variables. Time comes from chrony against the local clock, and every attestation states its time source. Application logs never contain sensitive values — they pass through the same recognisers before they are written. No copy of any customer data ever leaves the deployment: Zindagi never receives bundles, policies, keys, maps or audit logs, and support in the full product works from LogVeil's own support bundle, which LogVeil sanitises before the customer decides to send it.

What Zindagi never receives

No copy of any customer data ever leaves the deployment: not the bundles, not the policy or the key, not the map, not the attestations or the audit log unless the customer chooses to share them. The product has no remote-access or remote-support channel.

Keys

Key custody and retention

in development

Each job's map is stored encrypted with AES-256-GCM under a per-job data key; a per-tenant key-encryption key wraps the data keys — envelope encryption — and the key-encryption key is never at rest in plaintext. In early access it is unwrapped at service start from a passphrase held by the Platform Admin, entered rather than configured — the early-access key ceremony, labelled as such in the admin screen. Split-key custody (Shamir shares) or a hardware token are full product; keys sealed to a TPM are the appliance's. Every reversal, key operation and policy signature is written to the audit log. Maps expire per tenant policy — the default is retention while the support case is open plus 180 days — and destruction is a two-person, audited action; retention policy and destruction are full product.

The policy and the key →

Roadmap

Hypervisor images, and the appliance

Hypervisor images — OVA, qcow2, VHDX — from the same kit, a kit-to-kit upgrade path with rollback, and multi-node workers are full product. The appliance on the roadmap is a one- or two-unit x86 server with NVMe scratch sized at ten times the largest expected bundle, an optional 48 GB-class GPU for local AI, keys sealed to a TPM and a tamper-evident case. Virtual-machine sizing and the web service’s network port are agreed during early access against the customer’s own bundle sizes.

Hypervisor images

planned

OVA for VMware, qcow2 for KVM, VHDX for Hyper-V — built from the same kit.

An appliance

planned

A server with a local GPU for local AI and TPM-sealed keys. No bill of quantities, no price — it is a roadmap item.

Questions

What the deployment needs

in development

Where does it run, and does it connect to the internet?

Inside your network, on your own virtual machines, delivered as an offline kit: signed container images, a pinned compose file, an installer, a software bill of materials per image and signed checksums. A smoke test in the installer runs a full job with the outbound network blocked and confirms that nothing tried to connect. There is no telemetry, no update check, no external font or script. Nothing phones home, because there is nothing to phone.

What does the deployment need?

Docker Compose on Ubuntu 24.04 LTS or RHEL/Rocky 9, on amd64 or arm64, with local scratch storage sized for the bundles you expect to process — a large bundle can expand many times over on extraction. Hypervisor images (OVA, qcow2, VHDX) are planned. Exact sizing is agreed during early access against your own bundle sizes.

Is there a cloud version?

No. A hosted instance exists only as a demonstrator on synthetic data. LogVeil is designed for the air gap, and a real bundle never leaves your network to be processed.

How it works, in depth →

Status, and the next step

LogVeil is in development. An early-access programme opens after our first field trial.

Early access is a free, guided proof-of-concept on your own bundles inside your own network: you choose the bundles, you write the policy with our help, and you keep the key; we hand over the offline kit, run the first jobs with your engineers, and leave you with the attestations.

Request early access