Short answer: Yes. A phone-as-camera app that serves its own live view over your Wi-Fi doesn't have "seats" — anyone who can reach the phone's address on the network and knows the password can open the stream in a browser, including two or three people at the same time. What you don't get is the thing an account gives you: a per-person invite, a per-person revoke, and a record of who watched. This guide covers how to share access properly, and the one failure nobody plans for.
Most guides about turning an old Android phone into a camera stop at the moment the video appears on your laptop. That's where the interesting part starts, because a camera in a house is almost never a one-person tool. Your partner wants to check the porch. Your brother is minding the shop on Thursday. Your parents want to see the dog without phoning you to ask.
With a cloud camera, that's a settings screen: invite an email address, they install the app, done. With a local-only camera there is no account to invite — and that is both the point and the problem. Here is how sharing actually works, what it costs the phone, and what you're giving up.
Can two people watch the same phone camera at the same time?
Yes. Background Camera RemoteStream runs a small web server on the phone itself (an embedded Ktor server), and a web server's normal job is to serve more than one connected browser. Each viewer opens the phone's address on your Wi-Fi in an ordinary browser — no app to install on their side, no account to create, nothing routed through a company's servers. Two people on the same network can both have the live view open, on a laptop and a phone, at the same time. The practical ceiling isn't a licence limit, it's physics: every additional viewer is another copy of the video the phone has to push out over the same Wi-Fi radio.
Everything below is how to set that up without accidentally sharing it with the whole building.
The thing an account was quietly doing for you
It's worth naming what you removed when you removed the cloud account, because "no account" gets sold as pure upside and it isn't.
An account-based camera service uses your identity as the unit of access. That identity is what lets it offer:
- Invite — add a person by email, without giving them your credentials.
- Revoke — remove one person without disturbing anyone else.
- Attribution — a list of which account viewed or downloaded what.
- Recovery — forgot the password? A reset link arrives in your inbox.
A local-only camera has none of those, because there's no third party holding the list. Access is reachability plus a shared secret: can you get to the phone on the network, and do you know the password. That's a simpler, smaller thing to trust — nobody can hand your footage to an advertiser or lose it in a breach, because nobody else has it. It's also blunter. Sharing is not "add a person"; it's "tell a person the secret."
Once you understand it that way, the setup steps follow naturally.
Step 1 — Change the password before you tell anyone the address
Do this first, before you share anything with anyone, and before you go looking for the phone's IP address.
Every app that ships a built-in web server has to ship some starting credential so the first launch works. That starting value is, by definition, in the documentation — which means it's also in search results, in AI-generated answers, and in the hands of anyone who has ever read a setup guide for the same app. A default password is not a secret. It's a placeholder.
So: open the app's server/streaming settings, set a password you chose, and only then hand out the address. If more than one person will use it, pick something you're willing to say out loud in a kitchen — you're going to be repeating it — but not something guessable by a person who knows you.
Step 2 — Get them the address, and stop it from changing
The live view lives at a local address that looks something like http://192.168.1.42:8080. Two things to know about it.
It's a private address. It only means something inside your own network. Sending it to someone at work does nothing; their browser will simply fail to connect. That's not a bug, it's the boundary doing its job.
It can change. Your router hands out addresses by DHCP, on a lease. When the lease expires, or the router reboots, or the phone is off Wi-Fi for a day, the phone can come back with a different number — and the address you wrote on the fridge is now wrong. Two fixes, both free:
- Reserve the address on the router. Nearly every home router has a page called DHCP reservation, Static lease, or Address reservation. Find the phone in the client list, pin it to its current address, save. Now the address survives reboots.
- Or just re-read it from the app each time it drifts. Fine for one household, annoying for three people.
Do option 1 once and you never have to explain "the number changed" to anyone.
Step 3 — Check that your network will actually let them through
This is where most shared-access attempts fail, and it's never the app's fault.
- Guest networks are isolated on purpose. If your visitor's phone joined "MyWiFi-Guest" and the camera phone is on "MyWiFi", the guest network is doing exactly what it was designed to do: keep devices on it from reaching devices on the main network. Put both on the same network.
- Client isolation (sometimes "AP isolation") does the same thing on a single network, and some routers ship with it on. If two devices on the same Wi-Fi genuinely cannot see each other, this is usually why.
- Some "home" networks are building networks. In a shared flat, hostel, dorm or above-a-shop apartment, the Wi-Fi may cover far more people than you think — in which case a password on the stream isn't optional hygiene, it's the only thing standing between your camera and the neighbours. I wrote about that whole threat model in why "local-only" is not the same as "private".
Step 4 — Decide what "access" actually means for each person
"Access to the camera" is two different things, and it's worth being deliberate about which one you're granting.
Live view is the low-stakes one. Someone can see what's in front of the lens right now. When they close the tab, they have nothing. This is what you want for the neighbour watching the shop front for an afternoon.
The recorded files are the high-stakes one. Video written to the phone's storage is the evidence, the private moments, the whole archive. On a local-only setup those files sit on the device, which means access to them is mostly physical access to the phone — and that's a different, slower, more deliberate act than opening a URL. Keep it that way. A screen lock on the camera phone is not decoration; it's the boundary between "can watch the hallway" and "can scroll six weeks of your evenings."
If someone only needs to check on things, give them the live-view address. Don't hand over the phone.
What a second and third viewer actually cost you
Adding viewers isn't free, and the cost lands in three places at once:
- Wi-Fi. The phone has one radio, and it now sends the same video two or three times. On a crowded 2.4 GHz network in a dense building, this is the first thing to give — you'll see stalling before you see an error message.
- Heat. Encoding and transmitting is work, and a phone that is warm with one viewer is warmer with three. On a 24/7 setup that matters more than it sounds; the heat and battery side of continuous running is its own subject, covered in can you leave an old Android phone recording 24/7?.
- Battery, if it's not plugged in. For any multi-viewer setup, keep the camera phone on a charger. This is not the use case for running on battery.
The lever that fixes almost all of it is resolution. Two people watching a modest stream is far smoother than two people watching the maximum the phone can produce, and for "is the gate closed / is the dog on the sofa / is anyone at the counter", modest is completely sufficient. Turn it down before you turn anything else up.
The failure nobody plans for: one person knows how it works
Here's the part I'd argue is the real risk in a household camera, and it has nothing to do with hackers.
Somebody sets the camera up. That person knows the router login, the phone's screen-lock code, the app password, and where the phone is physically wedged. Everyone else in the house knows "there's a camera." Then that person travels, or is in hospital, or simply isn't picking up — and on the night the camera is most needed, nobody else can restart it, re-read the address, or get the clip off it.
Account-based services paper over this with password resets and a second admin. A local-only setup has no such backstop by design: there is no company to email, and no reset link, because there is no account. The recovery mechanism has to be you.
It costs five minutes:
- Write down four things — the Wi-Fi password, the router admin login, the camera phone's screen-lock code, and the stream password.
- Put that paper where a second adult in the household can find it. Not in a password manager only you can open.
- Show one other person, once, the two actions that matter: open the address in a browser, and where the phone lives.
- If the phone is somewhere awkward — high shelf, taped behind a sign, inside a cupboard — make sure that second person can physically reach it.
Everything else about a local-only camera is more robust than a cloud one. This is the single dimension where it's more fragile, and it's fixed with a pen.
What you're giving up, stated plainly
No hedging on this list:
- No per-person revoke. The password is shared, so removing one person's access means changing it for everyone and telling the rest the new one.
- No record of who watched. If three people have the address, you cannot tell which of them opened the stream on Tuesday.
- No remote invite. Granting access is a real-world conversation, not an email field.
- No password recovery. Forget it and you're resetting from the phone in your hand.
Those are real costs. They buy something specific in return: the video never leaves your network, so there is no vendor account to breach, no plan to renew, no retention policy that changes underneath you, and no third party who could be compelled to hand over footage they don't have. For most households that's the right trade — but you should make it knowingly.
If the other person isn't on your Wi-Fi
Everything above assumes both people are on the same network. If the person who needs the view is somewhere else entirely — at work, in another city — that's a different problem with several honest solutions and one bad one (opening a port to the internet). I laid out four routes, ranked, in how to watch your phone's camera from outside your home network without port forwarding.
The short version
Sharing a local-only phone camera is easier than sharing a cloud one in the moment — no invites, no seats, no per-user fee, and the second person doesn't even install anything. It's harder over time, because the things an account was doing quietly (revoke, attribution, recovery) are now your job. Change the password, pin the address, keep both people on the same network, share the live view rather than the phone, and write the four facts on paper for whoever will need them when you're not there.
Background Camera RemoteStream records with the screen off, stores everything locally, and serves its own live view over your network — no account, no cloud, no subscription.
- Google Play: https://play.google.com/store/apps/details?id=com.superfunicular.digicam&utm_source=devto&utm_medium=article&utm_campaign=2026w34
- Website: https://superfunicular.com/?utm_source=devto&utm_medium=article&utm_campaign=2026w34
Related reading
- The best way to watch an old Android phone as a camera in your web browser — which apps give you a browser view at all, scored honestly.
- How an Android phone serves its own live camera feed over your LAN: an embedded Ktor server deep-dive — the architecture underneath the multi-viewer answer.
- "Local-only" is not the same as "private": the LAN threat model — who else on your Wi-Fi can reach the stream.
- How to watch your phone's camera from outside your home network (without port forwarding) — for the viewer who isn't in the building.
Top comments (0)