Your cameras outgrew one box.
Traditional NVR software runs on a single server behind a single RAID array. Need more cameras or more days of retention, and you replace it. MotionScale treats every recorder and every drive you own as one pool of capacity — so you grow by adding hardware instead of throwing it away.
No RAID controller No cluster manager No quorum No cloud dependency
One machine is a ceiling. A pool isn't.
Every constraint on the left is an artifact of recording being tied to one server and one volume. Untie those two things and the constraints go with them.
- Cameras are assigned to a specific recorder. That machine dies, those cameras stop.
- Storage is one RAID array. Growing it means matched disks and a rebuild window.
- A failed drive triggers a rebuild — the slowest, most fragile hours the array will ever have.
- Retiring a disk means migrating or losing what is on it.
- High availability is bolted on: a load balancer, a virtual IP, a cluster manager, a quorum.
- Capacity is bought in whole servers, sized for a peak you hope to reach.
- Cameras belong to a pool. Any member can record them, and placement is decided fresh from measured capacity.
- Storage is a set of independent directories — any disks, any sizes, no volume manager between them.
- Nothing is striped, so there is no rebuild. A lost drive costs the footage on that drive and nothing else.
- Retire a disk by flipping it read-only and letting retention drain it. Nothing is copied.
- Placement and failover are the scheduler's ordinary behaviour, not a separate HA product.
- Add one drive or one server at a time. Mismatched hardware is fine.
Drives, pooled — with no volume manager underneath.
A storage target is just a writable directory. Group several into a pool and they share write load as one unit. Pooling never collapses them into one volume: no striping, no unified mount point, no rebuild on failure.
Fill or spread
Fill uses each target to its ceiling in order, so every disk holds a contiguous span of time. Spread writes targets in turn and drops a full one out of the rotation. Chosen per pool.
Tiers that roll downhill
A recorder has one tier chain. New footage lands on the lowest tier with room; when a tier fills, its oldest rolls to the next. Fast NVMe in front, bulk spinning disk behind, archive last.
Retire a disk by draining it
Turn a target read-only and nothing new is written there. What is already on it stays readable, stays in the timeline, stays playable, and ages out normally. Then unplug it.
An honest word on redundancy. Pooling solves capacity, not duplication. A segment is never split across drives, so losing one drive costs only the footage that lived on it — the recorder keeps running and the pool keeps recording. But MotionScale does not make a second copy for you. If a deployment must survive a drive failure with zero footage lost, put redundancy in the storage layer underneath, exactly as you would for any other application. What you no longer need is RAID as the only way to turn many disks into one large pool of recording space.
A camera belongs to a pool, not to a recorder.
This is the whole idea. A camera names no machine of its own — it names a pool, and the management service decides which member records it, recomputing that decision as members come, go, fail, and fill up.
When recorder-c stops answering health polls, its cameras are placed on whichever members still answer. Recorders already recording keep recording throughout.
Placement by real headroom
Each member reports writable free space and the actual bitrate of every camera it holds. Free bytes divided by summed bitrate is remaining retention headroom — highest score wins the camera. Recomputed every cycle, never trusted as a one-time answer.
No quorum, ever
One member down out of eight, or seven out of eight — the rule is identical. There is no threshold at which placement stops, because a rule that freezes at half the pool answers two nearly identical outages in opposite ways.
Churn is damped, not gambled on
A member must fail health polls for a sustained window before it counts as unreachable, and a camera moves at most once per cooldown. A flapping link relocates cameras once, then cannot move them again until it has settled or failed for good.
One timeline across members
A camera that moved mid-week still answers one coverage query. The timeline merges both halves and names which recorder holds each — and a recorder that did not answer is reported as silent rather than quietly dropped.
Servers can serve many pools
A camera belongs to exactly one pool, but a machine can join as many as you add it to, holding one key per pool. That is what shared capacity looks like when several groups of cameras run on the same hardware.
Pools can span sites
Where a pool spans locations and one site's link fails, the members still reachable are the ones that can still be given work. Cameras they can dial are cameras that keep being recorded.
A control plane for recorders — not a recorder with extras.
MotionScale is three services with separate responsibilities, separate databases, and no shared state. The management service orchestrates; it is never in the path video travels.
Recording survives management
A recorder whose management service is unreachable keeps recording, keeps enforcing retention, and keeps its own health. What is lost is configuration and viewing — which is the correct thing to lose.
Recording never decodes a pixel
H.264 and H.265 are written exactly as the camera sends them, into fragmented MP4. No transcode, no re-encode, no quality loss — and CPU proportional to camera count rather than to resolution.
Analytics is a peer, not a plugin
The detection service reads cameras directly and never speaks to a recorder. It is claimed, assigned, and load-balanced exactly as a recorder is — on GPU capacity instead of disk. An installation without it is complete, not degraded.
One TLS port for everything
Interface, API, live updates, and all media on a single port. There is no media protocol other than HTTP — one firewall rule to write, one certificate to renew.
Local-first, offline-capable
Streams, recordings, and control stay on the local network. Licences verify locally and offline. An installation with no internet connection is a supported deployment, not a crippled one.
Loud about failure
An offline camera, an unsupported codec, a full disk, or a clock problem is reported as a distinct condition with its own cause. Recording never stops quietly — and never stops because of a licensing state.
A compromised recorder is worth exactly one recorder.
One token per service, one audience each
Signing in mints a separate token for the management service and for each recorder you may reach. A token harvested from one recorder is refused by management and by every other recorder — so a breach does not compound.
Recorders verify; they never sign
Management is the only signer in the system. A recorder mints no token, holds no signing key, and cannot seal a credential it was not given the key for.
Camera passwords are sealed before they are sent
Credentials are encrypted under a per-pool key that lives outside the database. A stolen recorder database yields a username and a sealed password — and not the key that opens it.
Recorders never call out
The direction is always management outward. A recorder needs an address for its cameras and its time source, and nothing else. A health condition is found because management polled for it, not because anything phoned home.
Numbers with a boundary around them.
These are the targets reliability and latency claims are measured against, for one recorder on a modern four-core machine with a local fixed disk. Pools multiply them. Exceeding a target is not a defect — the targets exist so that "supported" has an edge and sizing guidance means something.
| Dimension | Target, per recorder |
|---|---|
| Cameras recording continuously | 16 |
| Aggregate ingest | 64 Mbps |
| Concurrent live viewers | 8, across up to 8 distinct cameras |
| Managed storage | 8 TB across up to 4 storage targets |
| Default retention | 30 days |
| Recording query response, 24-hour range | under 500 ms |
| Live-view latency, camera to browser | 6 seconds or less |
Analytics is sized separately and changes none of the above. It runs on its own host against the same cameras, adding a second connection per camera and nothing else — no ingest, no storage, and no CPU on the recorder. It is bounded by GPU and by whether your cameras report their own events.
One binary. The licence decides what it does.
Editions are a property of the licence, not of the build — so an upgrade is a new licence file, never a reinstallation. Licences verify locally and offline, and verification always fails towards the free tier rather than towards a stopped recorder.
- 4 configured cameras
- 1 recorder
- No activation, no account
- Every recording feature
- Multi-drive pools and tiers
- Cameras beyond four
- One recorder per pool
- Storage pools and tier chains
- Analytics service
- Offline verification
- Everything in Base
- Placement and failover across servers
- Direct browser-to-recorder media, without the proxy hop
- Two-way audio talkback
- Tenants — divide one installation between customers
- Everything in Pro
- Site connectors
- Remote sites need no licence of their own
- Pools that span locations
A recorder never consults the licence. Licensing lives entirely in the management service and is not a security boundary. An expired licence blocks configuration changes — it does not dissolve tenants, reassign cameras, disconnect a site, or stop recording. Cutting a customer's cameras off over a late renewal would be the worse outcome.
Start with four cameras.
Grow by adding hardware.
The free tier needs no licence, no activation, and no account — and it is the same binary every larger deployment runs.