Security & architecture

Security buyers can verify,
not just trust.

This page is written to be forwarded inside your organization. Every claim below is something you can read in our open-source code or check with a public reference — not a marketing slogan we ask you to take on faith.

Talk to engineering

Architecture overview

One labeled diagram, then the parts that matter. Detail follows in the sections below — this is the shape of the system.

Cameras stay in your network. Recordings live on a per-tenant encrypted volume. You watch from a browser over TLS.

Want the deep version — component-by-component, write/live/provisioning data flows, failure modes? Read the full architecture →

1. Cameras

Your IP cameras stay on your local network. They are never exposed to the public internet by us; we do not require port-forwarding or DDNS.
2. WireGuard tunnel

A WireGuard tunnel sidecar in your tenant pod terminates a peer at your site. Camera RTSP streams traverse only this encrypted tunnel (app/services/k8s/wireguard_sidecar.py).
3. Isolated tenant pod

Each customer gets a dedicated Kubernetes namespace and a dedicated LightNVR pod. No multi-tenant process boundary; cross-namespace ingress is denied by NetworkPolicy.
4. Encrypted PVC

Recordings are written to a DigitalOcean Block Storage volume mounted only into your pod. The volume is encrypted at rest by the storage provider.

Encryption

What the cryptography actually covers, and how the keys are managed. We state what we do, not what sounds good in a sales deck.

In transit

Cameras ↔ tenant pod: WireGuard (ChaCha20-Poly1305, Curve25519, BLAKE2s). The peer key material is generated server-side per tenant and delivered to your network device once (app/services/wireguard.py).
Browser ↔ dashboard / API: TLS 1.2+ (modern profiles preferred where the client supports them) on *.lightnvr.com, terminated at our ingress with certificates issued by Let's Encrypt (cert-manager) and renewed automatically.
Live video (WebRTC): DTLS-SRTP. When a direct peer connection is not possible, traffic is relayed via our COTURN service in the lightnvr namespace. The relay is opaque — it never decrypts the media.

At rest

Recording volumes: DigitalOcean Block Storage volumes, encrypted at the storage layer (LUKS/dm-crypt managed by the provider). Each tenant's volume is mounted into only that tenant's pod.
Database: Account, instance, and billing metadata live in managed PostgreSQL with provider-managed encryption at rest. Recordings are never stored in the database.
Key management: We do not currently operate a customer-managed-key (BYOK / HSM) tier. The encryption keys for recording volumes are managed by DigitalOcean. If your compliance posture requires customer-controlled keys, talk to us — we will tell you honestly whether we can meet it today.
Backups: Encrypted volume snapshots inherit the same provider-side encryption. Snapshot retention follows the volume's tenant lifecycle.

Tenant isolation

Every tenant runs in their own dedicated allocation. Recordings, configuration, and credentials are never shared across customers.

How it's separated

Dedicated compute. The CPU and memory you allocate are reserved for your instance. No other tenant runs in the same process boundary.
Dedicated storage. Your recordings live on a volume mounted only by your instance. Encrypted at rest at the provider level.
Network controls enforced at the platform layer. Only your instance and our control plane can reach your recordings. Cross-tenant traffic is denied by default.

Need full host isolation?

By default, tenants share underlying physical hosts at the hypervisor layer. For customers with stricter requirements — regulated data, compliance contracts, or kernel-level isolation — we can allocate dedicated hosts. You pick the configuration, we provision the host(s), and you're billed for the full host allocation.

Where the trust boundary ends

So you can decide whether the architecture fits your threat model.

Container image supply chain. A compromise of the LightNVR image (or any of its dependencies) would affect every tenant pod. We mitigate with pinned image digests and dependency review.
Infrastructure provider. DigitalOcean's control plane, hypervisor, and storage layer are part of our trust boundary. Dedicated-host allocation reduces shared-infrastructure exposure but does not eliminate it.
Operator access. A small number of operators hold credentials capable of reading any tenant. Access is logged centrally; a customer-facing audit log is on the roadmap, not yet shipped.

Vulnerability disclosure policy

Find something? Tell us first; we will fix it and credit you. Full policy at /vdp (in progress).

How to report

Email security@lightnvr.com with steps to reproduce and any proof-of-concept.
Please do not run automated scanners against production tenants. Test against a local self-hosted build instead.
Do not access, modify, or exfiltrate data that is not yours. Report the access path and stop.

Our SLA to you

Acknowledgment: within 24 hours.
Initial assessment: within 7 days.
Fix or mitigation: proportional to severity; disclosure timeline agreed with you.
Credit: public acknowledgment in the hall of fame below (opt-in).
Safe harbor: we will not pursue legal action against good-faith research that follows this policy.

Hall of fame

Empty for now — we would rather wait than pad it. Your name belongs here if you find something that matters.

Subprocessors

Third-party services we use to deliver LightNVR Cloud, what each one actually sees, and where their compliance documentation lives.

Subprocessor	Role	Data scope	Compliance
DigitalOcean	Kubernetes cluster, Block Storage volumes, LoadBalancers, managed Postgres.	Hosts every tenant pod and the encrypted PVCs that store recordings. Has infrastructure-level access by definition.	SOC 2 Type II, ISO 27001. Public security page →
Stripe	Payment processing and billing.	Sees billing data only — name, billing address, card token, invoice line items. Never sees recordings or camera config.	PCI DSS Level 1, SOC 1 / SOC 2. Public security page →
Mailjet	Transactional email (signup, password reset, billing notifications).	Sees email address + the contents of transactional messages we send you. Never sees recordings.	GDPR-compliant; ISO 27001. Public security page →

We notify customers via email if we change subprocessors materially. The list above is the current set as of this page's last update.

Data residency & retention

Where your recordings live, how long we keep them, and what happens when you cancel.

Region

The primary cluster runs in DigitalOcean's NYC1. EU customers can request AMS3 (Amsterdam) to keep footage in the EU; APAC customers can request BLR1 (Bangalore). Email us to coordinate placement.

🇺🇸 NYC1 — Live 🇳🇱 AMS3 — On request 🇮🇳 BLR1 — On request 🇺🇸 SFO3 — On request 🇨🇦 TOR1 — On request

Retention

Recording retention is configured per instance — you choose how much footage to keep based on the volume size you provision. There is no mandatory minimum or maximum imposed by us; the storage volume size you pick is the cap.

Cancellation & deletion

On cancellation we give you advance notice so you can export footage. When the instance is terminated, the namespace is deleted and the associated PVC is destroyed — recordings are permanently gone. No soft delete, no 30-day grace bucket on our side.

What we do not do with your footage

We do not view, scan, transcode, or analyze your recordings.
We do not train models on your recordings.
We do not share your recordings with third parties — including law enforcement — except where compelled by valid legal process, in which case we will notify you unless we are prohibited from doing so.

Open-source since 2024 175+ GitHub stars Built in Maine

Have a question we didn't answer?

Email support@lightnvr.com — a real human responds. We would rather have a conversation than ship a page that pretends to be exhaustive.

Security buyers can verify, not just trust.