nivq
This install section is for Enterprise / on-prem customers who self-host nivq.

Production hardening

Take nivq from a first install to a hardened production deployment — image pinning, persistence and backups, TLS, observability, and health probes.

Once nivq is up — whether via Docker Compose, Kubernetes, or bare metal — this page covers what to tighten for production. It applies to all three install methods.

Pin the image (or JAR)

Never run :latest in production. Pin the exact version Nivorbit shipped, so a redeploy can't silently pull a different build:

YAML
# Docker Compose
nivq:
  image: ghcr.io/nivorbit/images/nivq:1.4.0

On Kubernetes set image.tag in your values file; on bare metal, keep the versioned JAR filename.

Persistence and backups

  • Postgres is the source of truth — back it up. It holds your workspaces, the audit log, pattern memory, and the active licence. Use a managed Postgres with point-in-time recovery, or a reliable volume plus a scheduled pg_dump.
  • The licence needs no file volume. It lives in the database, so the on-disk file is only an optional first-boot seed — a restored database comes back already licensed.
  • Redis/Valkey is a cache and can be treated as ephemeral.
  • Guard the encryption key. NIVQ_ENCRYPTION_KEY_V1 decrypts every stored credential; keep it in a secret manager and back it up separately from the database.

TLS and reverse proxy

nivq serves plain HTTP on port 8080. Terminate TLS at a reverse proxy or load balancer (nginx, Caddy, a cloud LB, or a Kubernetes ingress) in front of it, and set BACKEND_URL / FRONTEND_URL to the public HTTPS URLs — they're used as the token issuer and for OAuth redirects, so they must match what the browser actually hits.

Observability

nivq exports OpenTelemetry traces and metrics, and can emit structured ECS JSON logs for an ELK stack:

Shell
NIVQ_LOG_FORMAT_CONSOLE=ecs
NIVQ_OTLP_TRACING_EXPORT_URL=http://otel-collector:4318/v1/traces
NIVQ_OTLP_METRICS_EXPORT_URL=http://otel-collector:4318/v1/metrics

Point the OTLP URLs at your collector and ship the JSON logs to Elasticsearch/Kibana (nivq tags them so you can index them into nivq-logs-*). In production the metrics endpoint is also exposed for scraping at GET /actuator/prometheus.

Health and readiness

Wire your orchestrator's probes to:

GET /actuator/health      # liveness / readiness
GET /actuator/info        # build metadata

Both stay reachable even while a deployment is activation-pending, so your platform can manage and route to a node that hasn't been licensed yet.

Air-gapped

For fully disconnected sites: load the image (or JAR) from the offline artifact Nivorbit provides, run a local Ollama model and set the platform LLM BASE_URL to it, seed the licence from a file, and — if policy forbids any vendor-initiated DB connection — enable MCP-native mode. nivq then makes no outbound calls of its own.

JAR integrity (tamper-resistance)

Defence-in-depth on top of the licence. Nivorbit's release pipeline signs the JAR with its code-signing certificate; you can make a node refuse to run a repackaged or foreign-signed JAR by turning verification on. Set both — it's fail-closed, so enabling it without the fingerprint refuses to boot:

Shell
NIVQ_LICENSING_VERIFY_JAR_SIGNATURE=true
NIVQ_LICENSING_EXPECTED_SIGNER_SHA256=<signer fingerprint>     # provided with the release

The fingerprint is the SHA-256 of Nivorbit's signing certificate, provided with each release. With verification on, a node refuses to boot any JAR not signed by that certificate. It's optional defence-in-depth on top of the signed licence — leave it off if you don't need it.