Runtime
Runs locally
ARC control lives on your hardware rather than depending on a remote browser-only model.
Local-first control
Your rooms keep running where they run: on site
ARC is designed around a local runtime because live rooms should not feel like they are waiting on a distant service to decide what happens next.
The operator app talks to local host APIs, the runtime is on premises, and optional cloud services exist where they help - not where they take over the room.
Daily operations
Internet not required
ARC is built so normal room control is not defined by whether the public internet behaves.
Guard rails
Controlled access
The platform already includes network hardening and readiness gates for sensitive routes.
What local-first means in practice
Local-first means your control software stays close to your room, your devices, and your operators. ARC does not treat the room like a thin client connected to a remote brain somewhere else.
That matters because escape rooms are live operations. When staff need to react, reset, monitor, or override, they need a system that feels present and dependable on site.
Why operators care about local-first
More confidence on live game days
A room that runs locally is easier to trust when guests are in the building and staff need fast answers.
Room logic stays close to the room
Sensitive runtime behavior and control logic do not need to be pushed out into the open just to make the system work.
Easier to reason about the system
When the important parts of ARC live on site, troubleshooting and ownership become clearer for the people actually running the venue.
Better fit for mixed hardware environments
Rooms with a real mix of devices benefit from a local system that sits next to those devices instead of abstracting them away through a cloud-first model.
Where cloud still helps
Local-first does not mean anti-cloud. It means the cloud should be used on purpose.
Account
Sign-in, subscriptions, and licensing
ARC already uses platform services for account, billing, installations, and license flow where central coordination makes sense.
Remote visibility
Optional telemetry and dashboards
The wider ARC architecture already includes cloud telemetry and dashboard scenarios without making them the center of room control.
Updates
Packaged releases
A local product still needs a clear release path. ARC uses a launcher and packaged installer flow so updates stay organized.
Security and control in plain language
- ARC already includes ways to limit who can reach the system on your network.
- Sensitive license-changing routes can be protected instead of left open.
- The host and runtime already use readiness checks so the system does not behave like every route should be live before ARC is actually ready.
次のステップ
Check launch availability and support expectations
If the local-first model fits how you run rooms, the next practical questions are where ARC is launching first and how support works.