Help centre

Relay Bridge turns an event into a real-world action. A click in a browser, a call from your ERP, a button on your own web page, or motion on a camera can close a physical relay at your site — sounding a horn, ringing a bell, flashing a beacon, starting a fountain.

It works the other way round too: it shows you live camera video from your site with no ports opened on your network, records 24/7 to a machine you own, and can keep a searchable copy in the cloud.

There are two halves. The app (this website) is where you control and watch everything. The Bridge is a small program you install on a PC, NUC or Raspberry Pi at the site — it talks to your cameras on the local network and dials out to us, so nothing needs to be exposed to the internet.

Accounts are approved by hand, so signing in is a request rather than an instant sign-up. Nothing is created on your behalf until we approve it.

You can use Continue with Google or an email and password. Either way we ask for your name, your company, a phone number and a line about what you want to switch — a person reads every one of those before approving, which is the whole reason they're asked.

If you signed up with an email and password, confirm your email first — we check that at the moment of approval, so an unconfirmed address can't be approved. There's a button on the waiting-list screen to send the link again.

Approval is usually the same working day, and you'll get an email the moment your account is open. Until then you'll see the waiting-list screen when you sign in. If you're on that screen and expected to be in an existing account, check which address you're signed in as — it's at the bottom of the page, with Sign out beside it.

Open Settings and click Connect Shelly. You'll sign in to Shelly, approve access, and land back here — there are no keys or codes to copy anywhere.

Once connected, your Shelly devices appear as a list you can claim from. Connecting also switches on the real-time link, which is what lets the app reflect a relay's true state within a second, including when somebody presses it by hand at the panel.

On Controls, choose Claim a device, pick the relay from your Shelly account, and give it a name you'd recognise on a busy screen — “Shipping horn”, not “Relay 1”.

Open the device and press the big red FIRE button. That's a real physical action, so treat the button with the respect you'd give the panel itself.

FIRE sends a pulse: it closes the relay, holds it for a set time, then releases. That's what you want for a horn, a bell, a chime or a door buzzer — anything that should sound and stop.

On and Off are latches: they stay put until you change them. Use those for lights, a compressor, a heater — anything meant to run.

Pulse length is set per device (150 ms to 10 seconds) on the device page. A tap is around 300 ms; a horn blast is usually 1–2 seconds.

Relay Bridge is built for signalling and novelty loads: horns, bells, sirens, beacons, lights, chimes, fountains, gongs.

Everything on your account is one of four things, and the quickest way to keep them straight is by the verb — what you do with it.

A device is a logical thing, not a box. That one sentence explains most of the surprises. A single piece of hardware can be several devices, and a single device can be two things at once.

A camera and a relay can be the same device. If a camera is watching the thing a relay operates, add it to that relay rather than as a separate camera. Then the two know about each other, which is what makes “save a snapshot whenever this fires” and “record a short clip whenever this fires” possible. Such a device shows up on both screens — on Cameras because you count it as a camera, and on Controls because you still switch it.

Speakers and sensors are always their own device. There is nothing to combine them with.

Every device can start a rule and every device can be the target of one, whatever kind it is. A sensor reading can make a speaker talk; a camera seeing a person can fire a relay; a relay firing can trigger a webhook. That is the whole point of keeping them as separate, named things.

Two kinds, and the difference is worth understanding because it affects what happens when something goes wrong.

A LAN relay is the sturdier option for a plant or a yard: nothing depends on a third party's cloud being up, and the hardware is built for the environment. It does require a Bridge on site, since that's what reaches it.

A ControlByWeb box — an X-410 and its relatives — is reached over your own network by a Bridge, with no vendor cloud in between. One box becomes several devices: one per relay output, plus one per reading you choose to watch.

1. Add the box. On Controls, under Add a LAN relay box, give us four things:

Name them something short — the name gets a number added per output, so “X-410” becomes X-410 1 through X-410 4.

2. Its inputs appear on their own. The box reports its digital inputs and its supply voltage in the same message we already read to switch the relays, so a contact sensor, a float switch or a door loop needs no extra hardware. Within about a minute of adding the box, its Bridge reports which points it actually has and they show up under Add a sensor on the same screen.

3. Pick a point and name it. A digital input reads closed or open. vin is the supply voltage at the box, in volts.

Once a sensor exists it behaves like any other device: it has its own name, its own history, and it can start a rule. A contact closing can fire a relay, make a speaker talk, or call a webhook.

You only need the Bridge for cameras, recording and speakers — and for LAN relays and sensors, which are reached over your own network. Shelly relays are the exception: they go through Shelly's cloud and work with no Bridge at all.

1. Download it from Get the Bridge app. Windows has an installer; Linux is a single curl … | bash line.
2. It starts automatically and runs quietly in the background. On Windows it doesn't appear under Task Manager's Apps — look under Details or Background processes.
3. Open its local panel at http://localhost:7077, then connect it to your account with an enrol code from Sites → Bridges → + Add a Bridge (it works once and expires in 15 minutes).

With a Bridge installed, use Find cameras on the Cameras screen. The Bridge scans your local network, asks each camera who it is, and tries any camera logins you've saved — so most cameras appear already identified, with nothing for you to type.

Pick one, name it, and save. We test the video before we keep the camera: if the stream never opens, you get told to check the username and password instead of ending up with a broken camera in your list.

A camera doesn't need a relay. You can add cameras on their own — and a relay can be given one, which is what lets it take a snapshot every time it fires.

Plenty of cameras don't announce themselves on the network — most Hikvisions among them — and a camera on a different subnet won't be found either. That's normal, not a fault.

Use Add by address instead. Type the camera's address (something like 192.168.1.93) and its login. If you know the make, pick it — it only tells us which stream path to try first.

You almost never need the RTSP path. We try the usual paths for each brand and keep the first one that actually returns video. Only fill that box in if the usual ones fail.

No hardware yet, or you want a second angle for an afternoon? Choose Use this phone or computer on the Cameras page. The device you're holding becomes a camera, streaming from its own browser — no Bridge, nothing to install, working in about a minute.

Give it a site and it sits with the other cameras there, so you can have two views of the same thing on one page.

Two honest limits. It's live only — 24/7 recording, the cloud archive and motion alerts all need a Bridge reading a camera on your site's network, and a browser stream never touches one. And the page has to stay open: closing the tab, locking the phone or switching apps ends the stream. It's a camera you're holding, not one that's installed. We keep the screen awake while it runs.

Settings → Security stores the username and password for a group of cameras once, so adding the next camera needs no typing and the Bridge can re-authenticate on its own.

Passwords are encrypted before they're stored and are never returned by any read in the app — you can reveal one deliberately, but nothing lists them back to you or to a page.

You can also rotate a login: we change the password on the cameras themselves, keep both the old and new one working until every camera has confirmed the change, and tell you plainly which cameras still answer to the old one. Nothing is lost if it only half-finishes.

Your cameras don't stream to us around the clock. When you open a camera, the app tells your Bridge that somebody is watching; the Bridge starts sending video, and it stops again shortly after you look away.

That's deliberate: it means an idle camera costs nothing to have connected, and you're only ever billed for video you actually watched. The trade is a start-up of about 5 seconds the first time you open a camera. Once it's warm, it's instant.

The player waits for the stream to genuinely come up before it tries to play, so a slow start looks like “waiting”, not like an error.

If a particular camera needs to open straight away every time — a gate, a loading bay, anything you check in a hurry — ask us to put it on Instant start. That camera then streams to us continuously and opens in about a second, at the cost of using the site's upload bandwidth around the clock.

Work down this list — they're in order of likelihood:

1. Give it about 5 seconds. See the article above.
2. Check the camera's video format. If the camera is set to H.265 / HEVC, browsers can't play it and you get a black rectangle with everything else looking healthy. The camera panel says so explicitly when it detects this — switch the camera to H.264.
3. Check the Bridge is online on Sites → Bridges.
4. Look at the camera's error line in the camera panel. A 401 Unauthorized means the camera rejected the login.
5. Check nothing else is holding the camera. Some cameras allow only a couple of simultaneous connections.

That's allowed, and we handle it: only one Bridge is elected to stream a given camera at a time. The other shows “Standby — another Bridge is streaming this camera” in its local panel.

We do this because two programs pulling the same camera at once makes many cameras lock out connections and the picture flap. If the active Bridge goes away, another takes over within about a minute.

If a camera is failing, the app names which Bridge is failing and the exact error, so you don't have to guess which machine to go and look at.

Most cameras produce two streams at once: a full-resolution main stream and a small sub stream. The camera panel lists what yours offers and lets you switch which one is used for live viewing.

The sub-stream is the cheap thing to watch — less data, faster to start, easier on the camera. The main stream is what you want for identifying detail. Switching the stream changes what the Bridge reads for everything — live viewing, 24/7 recording and the cloud archive all come off the same source. So a sub-stream saves bandwidth but also lowers the quality of what gets recorded from that point on. Nothing changes on the camera itself, and switching back restores it.

The panel shows what's happening now: resolution, video and audio format, data in from the camera, data out to viewers, how many people are watching, and how long the stream has been up.

These are two separate things and it's worth being clear which you have on.

Recording is driven by settings held on the Bridge, not by us. If your internet drops, or the machine reboots, recording continues and resumes by itself — which is exactly when you need it most.

Local recording has two limits and whichever bites first wins: how many days to keep, and a hard size cap in GB. Oldest footage goes first, and the segment currently being written is never touched.

The cloud archive has its own separate retention in days.

The recording panel shows what's held, how much disk is free, and a per-day coverage bar so you can see at a glance whether there are gaps.

What gets uploaded to the cloud is your choice per camera:

• Full quality — the original recording. Biggest, and the most storage.
• Browse quality — a small copy made from the camera's own second stream. On a real 3-megapixel camera this is around 80–95% smaller, opens far faster on a slow connection, and is perfectly good for finding the moment you want. Full resolution stays on the Bridge, and “save this moment” still exports full quality from it.
• Both — the small copy for scrubbing and the original in the cloud. You can pull the original for any minute without the Bridge being involved at all, which means the footage isn't tied to a machine at your site any more.

Under the live picture there is a bar showing today: solid blue where there is recorded footage, ticks above it for things that happened, and the current time at the right-hand end. Click or drag it and the same player winds back — no new window, no separate screen.

The timestamp burned into the corner of the picture follows the footage, not the clock — so a screen-grab of something you scrubbed back to still says when it happened.

Fast playback is cheap because it plays the small browse copy, not the full-quality one — see Two qualities above.

Open a camera's archive and pick a day. You get a player plus a 24-hour bar showing where footage exists, with gaps drawn as gaps — click anywhere and it jumps there. Clicking inside a gap snaps to the next real footage rather than showing you nothing.

Above the bar is a marker lane: red for alerts, grey for movement, blue for saved clips, purple for relay fires. Below it is a strip of event thumbnails — click one to jump to just before it happened. You can also step event by event with the ‹ › buttons, or the , and . keys.

A 24-hour bar a thousand pixels wide gives each second about a hundredth of a pixel. A twenty-second delivery is a quarter of a pixel — you'll never find it by dragging, no matter how fast the video loads.

Events only fixes that by giving space to what happened instead of to the clock: periods with activity expand, and empty hours collapse to a thin hatched sliver labelled with what was skipped. On a quiet day, 98% of the day draws in about 6% of the bar, and a single event that was a fraction of a pixel becomes comfortably clickable.

Whole day gives you the plain, evenly-spaced 24 hours. Your choice is remembered.

⬇ Save this moment in the day viewer pulls roughly 15 seconds either side of the playhead at full quality from the Bridge and saves it as a clip, even if your cloud archive is set to browse quality.

Clips are kept separately from the archive and are not removed when you delete archive footage.

There are two delete buttons, and both only ever touch the cloud copy for one camera. Whatever the Bridge holds on its own disk is untouched.

Delete day removes that one day. Delete all footage removes every archived day for that camera, in every quality, and asks you to type DELETE first.

Cloud footage expires on the retention you set. If something matters — an incident, a claim, a delivery dispute — you can keep a day forever instead, from the Stored data card on the camera's Advanced tab.

A vaulted day is exempt from retention. It is the one place footage deliberately does not expire.

Switching the archive off stops new uploads immediately. Recording to the Bridge's disk carries on as before, and footage already in the cloud is not deleted — you can still browse it.

For what happens to the money, see the archive fee. In short: the fee is charged by the day, so you pay for the part of the month you had it on — and footage you leave in the cloud afterwards is billed as storage.

Footage is filed by the site's local day, not yours and not the recording machine's — otherwise an evening's footage lands on tomorrow's timeline for anyone west of Greenwich.

Set it in Settings → Site time zone. There's a one-click button for your browser's zone, and a camera can override its site if it's somewhere else.

The archive panel shows how many segments are queued. A backlog after an outage is normal and drains on its own — uploads go oldest-first and back off rather than hammering a struggling connection.

What matters is the other warning — the app says “N segment(s) were deleted locally before they reached the cloud”. That means local footage hit its retention limit before it could be uploaded, so those minutes only ever existed at your site. It's the honest signal that the site's upload speed can't keep up with what you're recording. Fixes, cheapest first: raise how long footage is kept locally so there's more time to upload, switch the archive to browse quality, lower the recording bitrate, or get more upload bandwidth.

A timelapse takes one still every few minutes of real time and plays them back as video, so a working day becomes about a minute you can actually watch. It's built from footage that is already in your cloud archive — nothing extra is recorded, nothing extra is uploaded from your site, and nothing is added to what you're storing.

That's why it's included rather than metered: the work is a few seconds of our processing over files we already hold.

Open the camera, go to Timelapse, and set:

As you change the settings the form tells you roughly how many frames and how long the finished video will be, so you can see before you start whether you're asking for four seconds or four minutes.

A build starts within a minute of you asking, and a full day usually finishes a couple of minutes after that. The list updates itself while it runs — you don't have to sit on the page.

There's a ceiling of 6,000 frames per timelapse. If your range and interval would go past it, the form warns you before you build, and if a build does hit the limit the finished video says so plainly rather than quietly stopping early. Widen “one frame every” or shorten the range.

The date and time we burn in come from our record of when the footage was recorded, not from the camera's own on-screen clock.

That matters more than it sounds. Camera clocks drift, and often nobody notices for months — on one of our own test cameras the camera's overlay runs about two minutes fast. If you ever need a timelapse to support a claim or settle a dispute about when something happened, the stamp we add is the one that holds up.

A finished timelapse can be published, which is the point if you want the public — or a client, or a city — to be able to watch progress without an account.

Press Share publicly and you get two things:

• A link to a simple page with the video on it. Anyone with the link can watch; there's nothing to sign in to.
• An embed snippet you can paste into your own website or CMS. It plays muted and loops, so it works as a banner on a project page.

What a visitor can see: the video, the label you gave it, the dates and hours it covers, and how it was made. That's all. They cannot see your camera's name, your other cameras, your account, or anything live — a published timelapse is a finished file, not a way into your system.

Press Stop sharing and the link stops working. One honest caveat: to keep a public page fast we let copies be cached, so a copy already cached can keep playing for up to 24 hours. Treat “stop sharing” as “no longer published”, not “instantly unreachable everywhere”. The video itself is kept either way.

The Timelapse tab shows a view count for anything you've published, so you can tell whether the page is actually being watched.

There's a limit to building on demand: you can only build from footage that's still in the archive, and archived footage expires (30 days by default). So on a six-month job, the timelapse you'd most want — the whole thing, start to finish — is the one you can't make.

The fix is a switch on the camera's Timelapse tab: keep a still every interval for this camera. It's off unless you turn it on. With it on, every night we save one still per interval from that day and keep it after the footage itself has expired. Months later you can still build the whole job, because the stills are still there.

When it's on you can also set:

• How often to keep a still, which hours, and what size.
• Also render that day's video each night — you wake up to yesterday's timelapse already made, labelled with the date.

Once a range of stills exists, the build form grows a Build from choice: Recorded video (limited to what's still archived) or Kept stills (reaching back as far as you've been keeping them). Everything else works the same — including setting narrower hours at build time than you captured with.

By default, kept stills don't expire at all. That's the point of them: recorded footage expires (30 days by default) and the stills outlive it, so a timelapse of the whole job is still possible months later. Nothing deletes them but you.

That's right while a job is running. It's less right once a job ends. A camera that comes off a finished site keeps its stills — and keeps using storage for them — until someone says otherwise. So on the camera's Timelapse tab there's Keep the stills for, which is set to as long as I keep the camera unless you change it.

• Pick a limit and stills older than it are removed automatically, within the hour.
• The shortest limit is 7 days, so the nightly build and the cleanup can't fight over the same day.
• You can always set it back to as long as I keep the camera — it isn't a one-way door.

Timelapses you've already built are not affected. A finished video is its own file with its own Delete — deleting the stills it was made from doesn't touch it. What you lose is the ability to build a new timelapse from that far back.

Timelapses are built from the archived copy, and if that's browse quality it comes from your camera's small second stream. We won't stretch a small picture to fill a bigger frame — that adds file size and no detail — so asking for 1280 wide on a 640-wide source gives you 640.

If you want bigger timelapses, set that camera's archive quality to full or both. See archive quality.

Each finished timelapse has its own Delete, which removes that video and nothing else — the footage it was built from is untouched.

Kept stills and rendered timelapses are also listed as their own kind on the camera's Stored data panel, with their own delete, so clearing them never costs you footage and clearing footage never costs you them. Deleting the camera removes both.

Three stages, each filtering for the next:

1. On the Bridge, free and always on. It watches for change in the picture. This costs nothing and never leaves your site.
2. Object detection, in the cloud. When change is detected, a full-resolution still is checked for what is there — person, vehicle, animal, package. If nothing on your alert list is present, it stops here.
3. A written description. Only if something relevant was found do we spend an AI credit describing it, giving you a sentence like “Several people stand near a blue electric bus”.

Alerting on an identified object rather than on changed pixels is the whole point — it's the difference between “something moved” and “a person is at the back gate”.

The grid sits over a still from the camera so you can see what you're excluding. Click or drag to paint. Blue cells are watched; everything else is ignored.

Mask out a public road, a tree line, and any burned-in timestamp overlay. That one grid also gives you a minimum object size — a change smaller than a cell won't trip anything.

Unsaved edits survive the panel refreshing, and are marked as unsaved until you save them.

A camera can be switched on, watching, recording and raising events all day and still be reporting the wrong thing. The commonest version: a strip of public road, a footpath or a tree is inside the watch area, and almost every event is traffic. You get a busy event log, and the one time somebody actually walks up to the building, it's buried.

So the Motion & alerts tab checks your camera's own history and tells you what it finds. It reads recent events only — no footage, no AI, nothing to switch on, and it costs nothing.

• “41 of 41 events came from the same 4 cells.” When nearly every event fires in the same small patch, that patch is the cause. Stop watching those cells switches off exactly those squares and nothing else — the rest of the view is untouched, and you can switch them back on in the grid at any time.
• “41 events reviewed, and not one contained people.” Either what's setting it off is something else entirely, or what you care about is there and the movement threshold is too high to notice it — someone in dark clothing standing in shade barely changes the picture.
• Scene-wide changes. Events where most of the view changed at once are normally the camera adjusting its own exposure or switching to night mode. There's nothing to mask, but a tighter watch area helps anyway.

Show where it fires paints the counts straight onto the watch-area grid, so you can see the hot spot over the actual picture before you decide.

The order that fixes most cameras: narrow the watch area first, then lower the movement threshold. Doing it the other way round — turning up sensitivity while a road is still in frame — just gives you more traffic.

Guessing at sensitivity is miserable, so there's a test mode: the same grid is drawn over the live video and lights up as things fire.

• Amber — fired, inside your watch area, and counted.
• Faint white — changed, but outside your area, so ignored.

The status line tells you how much of the picture changed, how many cells are firing versus how many are needed, and whether it's in a cool-down.

When a camera switches to night mode, or headlights sweep the yard, the whole picture changes at once. We classify that as a lighting change and ignore it — no event is created at all, so you won't see it in the log. You can watch it happen live in Test on live video, where the status line says “lighting change — ignored”, and the camera's State tile shows “light change” for a minute afterwards.

If you're still getting noise: tighten the watch area first, then raise the number of cells required, then require the movement to persist across more frames. Those three, in that order, solve most of it.

Before you start turning dials, look at the tuning check on the same tab — it reads the camera's own event history and will usually name the exact squares causing the noise.

Two mechanisms handle this.

Incidents. A car that arrives and stays is one incident, not an alert every cool-down. Continuations are recorded and searchable, but only the first one alerts you.

Learned scenery. If an object sits in the same place across several events over about fifteen minutes, it's treated as part of the scene and stops being a reason to alert. When it leaves, press Forget to reset.

On the Events page you can ask in plain English — “anyone at the back gate late at night this week”, “did anything get delivered”, “has a vehicle been in the yard on a Sunday”.

We show you how we interpreted the question, then the matching events with thumbnails and a one-line answer. Times are read in your local hours, including ranges that cross midnight, and open-ended questions are answered over the last 30 days.

Anything you want to happen is set up under Events → Rules, not on the camera. A rule watches for something — a camera seeing a person, a sensor closing, a relay firing — and then does up to six things: fire a relay (sound a horn when a vehicle enters after hours), say something on a speaker, or call a webhook so your own systems hear about it. Webhooks must be https, are signed so you can check they came from us, and are tried once — the attempt is recorded either way.

Keeping it in one place means one rule can do several things at once, and the same rule can watch several cameras.

There's also a monthly cap on AI checks per camera, so a camera pointed somewhere unexpectedly busy can't run up a surprise.

Events and their stills are two separate settings, both 30 days by default and both adjustable per camera under How long to keep motion history — “Keep events” and “Keep stills” sit side by side. Leaving them equal is usually right, since an event without its picture is half an event; shortening just the stills is a reasonable way to cut storage while keeping the record of what happened. The panel shows what's currently held.

Supporting you sometimes means one of us opening your account — to look at a bill, or to switch something on because you asked. Settings → Account access lists every time that has happened: when, who, and what they did.

You don't have to ask us for it and we don't have to remember to tell you. It's written the moment it happens, to a log we can't edit, and it's the same record we hold ourselves to internally — you're seeing our own audit trail, filtered to your account.

If nothing is listed, nobody has opened your account. The one thing that doesn't appear there is our own fleet-wide totals — counts across every account, which don't identify you or show your data.

Everyone on your account can see this page, not just the owner.

A panel is a public page showing a group of relays as a control grid, with live state, a camera view where there is one, and a button per device labelled in your words. Build one under Share & embed and send the link.

Each device on a panel gets the action you choose — a pulse for a horn, or a clean On for a compressor — plus a small On/Off row.

Where a device has a camera, tap Live camera to watch it, and the ⤢ in the corner to fill the screen with the video and put the buttons over the top — so you can watch the thing while you switch it. Press Escape or ✕ to come back. Operating a relay never interrupts the video.

Three modes:

• View only — no buttons at all. Good for a status wall.
• PIN required — the default for new panels. Anyone with the link must enter your PIN before anything fires.
• Open — anyone with the link can fire. Use this only where a stranger firing it would be harmless.

PINs are stored only as a one-way hash — we can't show you the PIN back, so keep your own note of it. Four characters is the minimum; six is meaningfully better on a link anyone can open, and letters are allowed.

Guessing gets nowhere. After a handful of wrong PINs the panel stops accepting any PIN for a while, and the wait grows the longer someone keeps trying. You'll see the wrong attempts, and an Unlock now button, on the panel in Share & embed — so you never have to wait out someone else's mischief.

Share & embed generates a one-tag snippet. Drop it on any page and you get a working button — and, if the device has a camera, a live view alongside it.

The widget is scoped to one device and can only trigger it; it can't read anything else in your account. It also stops streaming the moment the tab is hidden, so an embedded camera on a background tab isn't quietly costing you.

Create a secret key under Share & embed and POST to our trigger endpoint with it as a bearer token. It's the same code path as the button in the app, so anything you can do here you can do from your ERP, a PLC gateway, or a shell script.

Secret keys are shown once — we only keep a hash. Lost one, make a new one. Keys can be scoped to a single device, and each key has its own rate limit — 120 calls a minute for a secret key by default, 30 for a widget key. It's per key, so separate integrations don't compete with each other.

A panel can live on your own address — controls.yourcompany.com. Open the panel's Domain row, enter the hostname, and add the single CNAME record we show you. The certificate is issued automatically; the page then serves on your domain.

A Bridge with an audio output can be a public-address point: type a message in the app and it's spoken out loud at the site. Add it under Speakers.

On Linux the voice is synthetic and robotic — fine for “truck at the dock”, not for customer-facing announcements. A cheap and effective setup is a Raspberry Pi running the Bridge into a powered speaker, or into a 70-volt amplifier feeding ordinary ceiling speakers.

Five kinds of line, and they behave differently:

The archive is $12 per month per camera with the archive switched on, and that includes 50 GB-months of storage. The allowance is pooled across your account, so a busy camera borrows from a quiet one instead of generating a surprise. Storage beyond the pool is $0.05 per GB-month.

It's priced per camera rather than per gigabyte on purpose: it means choosing browse quality makes your archive cheaper for us to run without making it cheaper for you to be sold — so we can recommend the efficient setting honestly.

Storage is counted over time, not as a snapshot. 13 GB held for one day of a 31-day month is about 0.4 GB-months, not 13. Equally, footage you delete mid-month still counts for the time it was genuinely stored.

Settings → Statement itemises the month: a line per camera for data out, then fee lines, then the total. Pick any past month from the month selector.

Expand a camera to see the individual viewing sessions behind its number — when it was watched, for how long, how much data, and how many viewers. That detail is kept even if you later delete the camera, because it's the evidence behind an invoice you've already had.

Streaming and Watched are shown separately and are not the same thing. A camera can be publishing while nobody is looking at it; only the second one costs you anything.

Deleting a camera removes all of its footage, clips and snapshots, so it stops accruing storage from that moment. Storage it used earlier in the month remains on the statement.

Your viewing session history is deliberately kept — it's the itemised detail behind invoices already issued, and deleting a camera shouldn't erase your own billing records.

The Bridges page lists every Bridge on your account with its status, the machine it's on, its operating system, version, camera and speaker counts, and uptime. A Bridge is shown online if it has checked in within the last minute and a half.

For anything deeper, open its own panel at http://localhost:7077 on that machine. Its log is at ~/.realay-bridge/bridge.log (on Windows, %USERPROFILE%\.realay-bridge\bridge.log) and is the first place to look when a camera misbehaves.

The app shows an update available marker when a Bridge is behind. There's no automatic self-update — you install a new version yourself, deliberately, from the download page (Linux: re-run the same one-line installer).

Reinstalling keeps your cameras, your settings and your recorded footage.

Watching cameras and controlling relays needs no remote access — that's what the Bridge is for. But if you want to reach a camera's own web interface from off-site, there's a Remote access button on the device's own page in the app. Nothing to install and nothing to set up on the Bridge: the session runs out through the Bridge's existing outbound connection, on a one-off address that expires. See Remote access, and the remoteui.net domain.

This means the camera was deleted in the app, so the Bridge no longer has anything to report to. After ten minutes of that, it stops recording, motion and uploads for that camera and flags it.

Your footage and settings are kept — a problem on our side must never be able to wipe a site's setup. When you're satisfied it was intentional, press Remove on the Bridge to clear it.

If the camera reappears in your account, the Bridge picks it up again on its own.

A Bridge is what usually gives a site its address, because it's the thing physically there. Give a Bridge an address and it appears under Sites — including on Sites → Map — and the cameras it reads inherit that location. Anything without a Bridge, like a Shelly relay or a phone camera, can be placed by hand: Put at a site… on Sites assigns it. You can paste coordinates instead of an address, which is the answer for a yard or a well pad with no postal address.

The map view always lists your sites underneath, including the ones with no address yet, so you can see what still needs placing.

The Bridge makes outbound connections only. There is no port forwarding, no inbound firewall rule, no VPN and no static IP needed at your site — which is usually the first question your IT team will ask.

The same applies to cameras: they stay on your local network and never need to be reachable from the internet. Video only leaves your site when someone is actually watching, or when you've switched the cloud archive on.

An account owner or an admin can open remote access to a device at their own site — its own web page, from anywhere, with nothing to install and no inbound connection to your network. The session opens on a one-off address under remoteui.net.

That's a separate domain on purpose. What you see in a session is a page belonging to your equipment, not to us, so we keep it isolated from the Relay Bridge app — it cannot read the app's cookies or act on its behalf. (Google and GitHub separate user content the same way.)

Every piece of data in the system carries the account it belongs to, and every request is checked against the signed-in user's account before anything is returned. No customer can see another's devices, footage or history.

Your browser never talks to the database directly — all access goes through our API, which is the only thing holding the keys.

For your IT reviewer: relaybridge.io/security sets out access control, encryption, sub-processors, retention and what we don't have yet on one page. Our incident-response, breach-notification, retention and key-rotation procedures are written down too — ask and we'll send them.

Within your own account, what each person can do is set by their role, and the most sensitive actions can be protected with two-factor authentication.

Two things behave like keys rather than logins, and you should treat them that way:

• Shared panel links. There's no sign-in on a panel — the link is the credential. Set a PIN, and delete the panel to revoke it.
• API and widget keys. Anyone holding one can trigger the device it's scoped to. Secret keys are shown once and stored only as a one-way hash, so if you lose one, make a new one.

Invite people to your account and give each one a role. Separation of duties matters here — the person who watches the yard shouldn't be able to delete the recording of it.

Inviting someone: Settings → People → Invite someone. You get a link to send them; it works once and expires in 7 days. They sign in, click Join, and they're on your account with the role you chose.

Every invite, join, role change and removal is written to your activity log with who did it.

Set it up in Settings → Two-factor authentication with any authenticator app — Google Authenticator, 1Password, Authy. Scan the QR, enter the code it shows, and save the ten recovery codes you're given.

It's step-up, not a login wall. You won't be asked for a code to sign in, watch a camera or fire a relay. You'll be asked before something that can't be undone or that reaches somewhere sensitive:

• Deleting footage, clips or a camera
• Seeing or rotating camera passwords
• Opening remote access to a device
• Inviting people or changing their roles

Once you've entered a code, those stay unlocked for 15 minutes. When you're asked mid-action, answering the prompt continues what you were doing — nothing is lost.

Everything travels over HTTPS, and footage, snapshots and clips are stored encrypted at rest by our cloud provider.

Camera passwords you save are encrypted with a key we hold separately from the database, so a database leak alone would not expose them. They are never returned by any screen or API — you can deliberately reveal one, and that's recorded.

Being straight with you: this is not zero-knowledge. We have to be able to hand a password to a Bridge so it can talk to your camera, so we can decrypt it. Anyone telling you otherwise about a system that logs into your cameras for you is mistaken.

Panel PINs are stored one-way, with a per-panel salt and the same separately-held key, so a database leak alone can't turn a stored PIN back into the four digits someone types at the gate. They can't be shown back to you — keep your own note.

Live camera links expire. When something plays a live camera — the app, a shared panel, a widget on your site — it's handed a signed link that works only for that one camera and only for a few hours. Copying the address out of your browser therefore doesn't give anyone lasting access to the camera; the page re-issues a fresh link as it goes. Recordings and clips have always worked this way.

Every attempt to fire a relay is logged — who or what triggered it, when, which device, and the outcome, including failures. Deleting a camera or a day of footage is logged too. You can see it on the Events page.

We also record which Bridge reported what, so a problem at a multi-site account can be attributed to the right machine rather than guessed at.

A named list of people — no more than a handful, and each one added deliberately. Nobody gets access by working here; support staff can't reach your cameras or your bill unless they're on that list.

Every action an operator takes is recorded, including simply looking at your account: who, when, and what they opened. Changing who is on the list is itself recorded, and requires that person's own two-factor code.

The record is written in two places — our own database, and a logging system that the operators themselves cannot edit or delete. That second copy is the one that matters for an audit, and it's why we can answer "who looked at our footage" with a list rather than a reassurance.

If your own security review needs that list, or a report of access to your account over a period, ask and we'll provide it.

Footage and clips can be downloaded from the app at any time. Motion history and its stills expire on a schedule you set per camera; cloud footage expires on the archive's own retention.

Deleting a camera removes its footage, clips and snapshots from our storage. Your billing history is deliberately kept — it's the detail behind invoices you've already had.

These four things turn a long back-and-forth into a quick answer:

1. Which camera or relay, by the name you gave it.
2. When it happened, with the time zone.
3. The Bridge's version, from Sites → Bridges.
4. The last few lines of the Bridge log, if it's a camera or recording problem.