Fast remote viewing
Desktop capture, H.264 transport, and adaptive relay logic keep Beam responsive even when the network is not.
Remote support, rebuilt for your stack
Screen sharing with a product-grade front door.
Beam gives support teams and software products a polished way to launch remote viewing. Share a code, route through your own relay, and open browser-based sessions without asking anyone to touch VPNs, routers, or network policy.
Relay sessions over your own VPS
Browser viewer via WebRTC
Adaptive bitrate plus FEC
8765 / 8767
Signaling and relay ports already wired for Beam
8770 / 8771
Control plane API and WebRTC signaling live today
49200-49260
UDP media range for browser sessions through the relay
Design direction
The landing page now follows a darker app-builder SaaS visual system with local BrightHub-inspired assets and a more premium product framing.
Why Beam
Everything the support team needs, with a landing page that finally looks like the product behind it.
The old version explained the tech. This version sells the experience: cleaner hierarchy, stronger contrast, real product framing, and a layout that feels closer to a modern SaaS launch page.
Self-hosted by default
Run signaling, relay, API, and browser-view infrastructure on your own VPS instead of handing sessions to a third-party cloud.
Browser-ready sessions
Expose live sessions through the WebRTC bridge so your agents can watch a screen from the browser without another install step.
Built for embedding
Create sessions over the API, surface approval in your app, and use webhooks to mirror the session lifecycle into your own workflows.
Workflow
A three-step path from "I need help" to "I can see the screen."
Beam still works the same operationally. The difference is that the page now narrates the support flow in a sharper, less utility-first way.
Step 01
Start a session
The customer opens Beam, gets a short code, and stays inside a clean lightweight handoff instead of a networking checklist.
Step 02
Route through your relay
The app targets your relay host, registers the session, and prepares either app-to-app viewing or browser viewing through the WebRTC bridge.
Step 03
Guide in real time
The viewer joins over the native app or embedded web flow, while the relay stack handles signaling, media routing, and resilience.
Deploy it
The current Beam stack is already opinionated. The landing page should say that clearly.
Instead of generic marketing copy, this section leans into the actual topology you are running today so the page feels grounded in a real product.
Current infrastructure shape
+VM 108 runs the Beam relay server, API, and WebRTC bridge on Ubuntu 24.04.
+Public host 81.196.53.61 forwards Beam-specific ports into VM 108.
+Public 80 and 443 terminate on VM 107, where Dockerized Caddy fronts external hostnames.
+beam.be-online.ro now reaches VM 108 through that ingress chain, which is the right pattern for future public Beam pages too.
How the app points at the relay
The page now showcases the actual relay mode configuration rather than pretending Beam is a generic website-only product.
// appsettings.json
{
"Server": {
"Mode": "relay",
"Host": "relay.be-online.ro",
"SignalingPort": 8765,
"RelayUdpPort": 8767
}
}
// public landing
beam.be-online.ro -> Caddy on VM 107 -> nginx on VM 108
{
"Server": {
"Mode": "relay",
"Host": "relay.be-online.ro",
"SignalingPort": 8765,
"RelayUdpPort": 8767
}
}
// public landing
beam.be-online.ro -> Caddy on VM 107 -> nginx on VM 108
Developers
Use Beam as a support surface inside your own product.
The BrightHub reference had a stronger product-builder feel, so this section now leans much harder into the "embed this into your workflow" story.
Ready to ship
Beam now looks closer to the product it wants to become.
Download the Windows app, keep improving the relay stack, and use this darker Beam page as the marketing front door while the product matures.