Agent DVR and private CCTV access

The problem

Agent DVR needed remote access, but built-in forwarding and reverse-proxy functions introduced licensing and TLS constraints. A second CCTV system belonging to family also had to remain completely untouched.

Interface reference

Official interface and documentation

A separate public deployment screenshot is not used here because it would be misleading or expose account details. The official project page below is the authoritative visual reference.

Open Agent DVR web client →

What I did

I separated the two environments and kept my Agent DVR instance reachable through the trusted LAN/private overlay path.

Verified direct service access on the local Agent DVR HTTP port
Avoided altering the separate parents’ CCTV system
Tested certificate approaches and identified licence-gated forwarding behaviour
Selected Tailscale/private VPN access as the clean free route
Kept the Agent DVR SSL port disabled rather than deploying a broken partial TLS configuration

Implementation notes

Representative commands from the way I diagnose and maintain this project. Public examples use placeholders instead of credentials or sensitive addresses.

Camera service and access checks

# Check the service locally before blaming the reverse proxy
curl -I http://127.0.0.1:<PORT>/
ss -lntup | grep <PORT>
docker logs --tail 100 <agentdvr-container>

# Verify name resolution and the published route separately
getent ahostsv4 camera.example.net
curl -4 -I https://camera.example.net

# Use Tailscale for direct private access when the application protocol
# or WebSocket behaviour is not suitable for ordinary HTTP publishing
tailscale status
ip route get <CAMERA_HOST_IP>

Photo evidence

**Private CCTV monitoring station.** A locally managed CCTV monitoring station. Camera views are redacted in the public copy.

Result

The CCTV service remains remotely usable through private networking without pretending an unsupported reverse-proxy setup is secure.