u/Digisticks

TL;DR: Public K-12 district with ~350 cameras is evaluating UniFi Protect as a replacement for Verkada. We already have a 10 Gbps managed private WAN, dedicated camera VLANs, mostly Cat6 cabling, and Meraki/Catalyst switching. I’m looking for real-world experience from people running 250+ cameras, especially G6/G6 Pro: reliability, NVR workload, storage, 1 Gbps IDF uplinks, video quality, support, and what you wish you’d known before deploying.

I’m the Technology & Safety Director for a public K-12 district in the Southeast. We’re evaluating whether to replace Verkada with UniFi Protect as our older camera fleet ages out.

We have roughly 350 cameras across four locations, including about 135 classrooms and 50 exterior cameras. Two schools share the same physical campus and the District Core. Our current camera fleet is about half the Verkada D30, D40, and D50 domes with the other half being newer CM41 mini domes in Classrooms.

Our infrastructure is already fairly camera-friendly:
10 Gbps managed private WAN
Moving toward 3 Gbps Internet
Dedicated camera VLANs/subnets
Mostly Cat6 camera runs already in place
Meraki/Catalyst switching
Current IDF uplinks are largely 1 Gbps fiber, with 10 Gbps at the core
Future switch purchases will have 10 Gbps-capable fiber uplinks

I’m not replacing good switches just for this project, so I’m especially interested in whether 20–30 cameras behind a 1 Gbps IDF uplink has been an issue in real deployments.

My current camera thinking is standard G6 for normal coverage/classrooms and G6 Pro where low light, distance, optical zoom, or identification quality justify it. I’m also watching G6 Edge closely.

For recording, I’m leaning toward local NVRs rather than sending all recording traffic across the WAN, probably with ENVR Cores at the two larger locations.

My G6 Pro pilot is currently around 16 Mbps / High Quality, and ideally I want to stay toward the higher-quality end. Smooth motion and usable detail matter more to me than minimizing storage costs.

The biggest unknown for me is the NVR side.
I’ve managed Verkada for years, but I’ve never managed an NVR at all, much less several NVRs supporting hundreds of cameras. I’m also essentially a one-person Technology department, so I can’t save money on licensing only to create another full-time job maintaining storage, drives, firmware, permissions, exports, and recorder issues.

Principals also need to be able to find and export their own footage. I cannot become the district’s human video-search button.

I’ve spoken with another public K-12 district in the Southeast running nearly 1,000 UniFi cameras across multiple ENVRs, and their experience has been positive enough that they’d deploy Protect again.

For those running 250–1,000+ cameras, I’d love to hear:
- Camera/NVR/HDD failure rates and how long you’ve been running it
- How much ongoing NVR maintenance actually takes
- Whether 1 Gbps IDF uplinks have caused problems
- Real G6/G6 Pro bitrates and motion quality
- Real-world retention versus what you calculated
- How well multi-NVR management works
- Whether non-IT staff can reliably find/export footage
- Your experience when you actually need Ubiquiti support
- Any firmware/update horror stories
- How outdoor cameras hold up in serious heat, sun, storms, bugs, etc.
- If you came from Verkada/Avigilon/Genetec/Axis/etc., what did you miss?

Most importantly:
What has been worse about Protect than you expected?
I’m already interested in the platform. I’m trying to find the ugly parts before committing to ~350 cameras.

How are you all going about disabling student Gmail without breaking Google's collaboration features? We had a few accounts compromised and it's been like playing whackamole for weeks. Literally took the nuclear steps of deprovisioning all accounts, forcing a logout of all accounts, and resetting every district password. While that was happening, apparently one more email got sent to students and I didn't catch it. So we've now had another one. I can't keep up.

After the interest in some of the things we build using Claude from this post the other day here on the subreddit, I spent some time making some new versions of our status dashboard (StatusDash) shareable. I've linked it out to some that have asked specifically, but thought I'd share it here. Not sharing the other things for now, as I'm still tweaking some backend things. Not to mention, I'm not even sure where to begin on how to make that generic enough to share. Any feedback I get from this will go straight to working on other things.

It's not perfect by any means, and it has gaps. But it's free. We could have paid for a real platform over the years, but it always seemed like a waste of certain funds. With that, we are a server-less environment and almost entirely Apple-based, so I don't have devices to host it on. Add to that being basically a one-person shop....well, I needed something reliable. So this came to be.

Being completely clear and upfront here, I don't have skills to code. I was a classroom teacher before taking on the Technology Director role a few years ago. This was iteratively built with Claude. But it works.

StatusDash polls vendor status APIs directly and displays live tiles grouped into sections you define. It refreshes every 60 seconds. Vendors that don't expose a compatible API still show up as clickable link tiles that go straight to their status page. There's an optional Google Apps Script poller that runs every 5 minutes on Google's servers and fires an email or Google Chat alert when something goes down or comes back up, no browser required. The admin panel lets you add vendors, create sections, set your district branding, and manage everything without touching any code after the initial deploy.

What it can't do: it only works with vendors that publish a public status page. If a vendor goes dark without updating their status page, StatusDash won't know. It's not a monitoring tool either, it's not pinging your network or checking response times. It's purely reading what vendors say about themselves. Worth noting, it can only reach publicly accessible URLs, same as any browser tab. If you're worried about something being reachable, that's a firewall conversation, not a StatusDash one.

There are two versions in the Google Drive link at the bottom. There is a standard public dashboard that anyone with the link can view once you've got it pushed, and a gated version that requires staff to sign in with their district Google account. Both are in the Drive folder along with deployment guides. Pick whichever fits your environment.

Realistically, there doesn't seem to be much here that could go sideways. It's basically just polling vendor status APIs and displaying tiles. No student data, no sensitive information, nothing writing to your network as written. The worst case currently is a tile that won't load or the Apps Script that might skip. The disclaimer is in the docs because it has to be, not because I think you're going to have a bad time.

One known gap worth being upfront about is that the Firebase API key is visible in the page source, as it is with every client-side Firebase app based on the documentation I've seen. This is how Firebase web deployments work by design as best I can tell. If you know better, please, let me know. Your Firestore rules control what can actually be read or written, and this dashboard stores nothing sensitive unless you put it there. But if you're the type to go looking, you'll find it, and I'd rather you know that going in than discover it and wonder.

I'm happy to help where I can, but fair warning...some days are busier than others, and this time of year especially is busy. I'll do my best.

I appreciate any feedback. I'm always working to make things better and any feedback from this will inform my other platforms I've built.

Google Drive Link for StatusDash