Kelra Room,
end to end.

01 Overview

Kelra Room is a software layer that turns any meeting-room touch panel — a Windows OPS module, a Huawei IdeaHub, a generic vendor display — into a unified room terminal: schedule, one-tap video-conference joining, and a collaborative whiteboard.

The product answers a simple problem: a fleet of meeting rooms is never homogeneous. Screens bought years apart, different brands, different remote controls. Every meeting starts with five minutes of troubleshooting. Kelra Room imposes the same interface, the same gestures and the same video call across the whole estate, whatever hardware sits underneath.

What an installation is made of

Design principles

What Kelra Room does not do

To frame an evaluation properly, the scope limits are worth stating plainly:

• Kelra Room does not replace your video-conferencing platform. It detects the Teams, Meet or Zoom link in the invitation and opens it full screen — the meeting stays with its vendor.
• It does not drive the room's audio/video hardware (camera, soundbar, panel control). Those remain handled by their usual Windows drivers.
• It does not measure actual call duration: the statistics are based on the slots booked in the calendar (see Operations).
• The hosted multi-site admin console is a separate commercial option; a standard deployment administers each server individually.

02 Features

The full life of a meeting, from the schedule on the wall to the minutes emailed to attendees.

Room screen

The screen permanently shows the time, the room name, its status and the day's schedule. The status is readable from the corridor: green when the room is free, red when it is busy, with the time it frees up or the next booking.

Joining a video call

Kelra Room parses the meeting invitation and extracts the call link, whatever the format — an Exchange HTML body, a Google description, a link pasted by hand. A large “Join the call” button appears as soon as a meeting starts.

Recognised platforms

Microsoft Teams · Zoom · Google Meet · Cisco Webex · Whereby · Jitsi Meet · Proton Meet · BlueJeans · GoTo Meeting · RingCentral · Livestorm.

The call opens in a real browser

When someone taps “Join”, the application launches Microsoft Edge full screen, in a dedicated, isolated profile. That choice is imposed by the platforms themselves: Google and Microsoft refuse participation from a browser embedded inside an application. Edge ships with Windows — nothing to install.

During the call a floating bar stays above every window, movable, translated into the screen's language. It carries two deliberately separate actions:

• “Back to kiosk” — brings the room screen to the front without touching the meeting, which carries on behind, audio and camera included. That is what lets you open the whiteboard mid-session and then return to the call: the button then reads “Back to the call”.
• “Leave the call” — actually ends the meeting and returns to the room screen. Different colour, different area: it is the only one of the two that cuts the call.

Closing the window by hand triggers the same cleanup: no window and no process piles up from one meeting to the next.

Two identity modes in meetings

The mode is set per room in the console. The room account is signed in once, at installation, from the screen itself; the session is kept in the call profile.

Instant meeting

One tap creates a Teams or Google Meet meeting on the fly in the room's calendar, books the room for an hour and opens the call. Available only in “room account” mode: an anonymous participant would have neither a directory nor any way to invite anyone, and the room could end up stuck in its own lobby.

Collaborative whiteboard

A full-screen whiteboard, shared in real time, opened from the room screen in one gesture. Excalidraw engine, scene relay hosted on your own server.

Multi-tenant broker — booking arbitration

The use case: a building shared by two organisations, one on Microsoft 365, the other on Google Workspace. Both want to book the same physical room, each from its own resource calendar. Without arbitration both accept — and two meetings turn up at the same time.

The Kelra Room broker aggregates the calendars of every organisation linked to a room and arbitrates pending invitations:

• First come, first served — invitations are processed in the order they arrive.
• Slot free across every calendar → the invitation is accepted and the organiser gets the usual confirmation.
• Conflict with an already-accepted booking, including one in the other organisation → the invitation is declined with a reason, visible to the organiser in the response.

Busy mirrors

A refusal arrives after the fact: until then, Outlook's Room Finder and Google's room picker show the room as free — they only read their own calendar. As soon as a booking is accepted, Kelra Room therefore places a neutral busy event on the room's other calendars, titled “Booked — another organisation”. The room shows as busy in the tool the user actually looks at, before any attempt.

• The subject and the organiser never cross the boundary between organisations. The mirror carries only a neutral title, which you choose.
• Mirrors are reconciled on every pass: booking moved → mirror moved; cancelled → mirror removed.
• They do not appear on the room screen, which already shows the original meeting, but they are visible and labelled in the console.
• The mechanism can be switched off; arbitration still declines conflicts regardless.

Admin console

A web interface served by the server, reachable from any machine on the permitted network. Nine tabs:

Console language: French and English. The room screen speaks eight — it is seen by your visitors, whereas the console is only seen by your IT teams.

03 Architecture

One central server, one screen per room, and the attendees' own devices joining the whiteboard. Nothing else.

The server

A single service, delivered as a container, gathering four roles:

All persistent data — rooms, screens, organisations, licence, arbitrated bookings, logos — fits in a single volume: an embedded database and a folder of files. There is no external database server to install, back up or upgrade.

The room screen

A single Windows executable carrying everything it needs. It installs per machine — necessary, since in Windows kiosk mode the screen runs under a dedicated account, separate from the technician who installs it. Three locations on the machine survive an uninstall: the server address, the wallpaper library, and the screen's identification key. An upgrade therefore never forces you to re-provision the room.

Authentication, in short

04 Requirements

What must be in place before installation, on the server, on the screen and on the network.

Server

Room screen

Calendars

• A resource mailbox (room account) per physical room, in Microsoft 365 and/or Google Workspace — the one your staff already book.
• For Microsoft: an application registration in your directory, with admin consent. For Google: a Cloud project with the Calendar API enabled.
• For the instant meeting: a licence including Teams on the room mailbox (Teams Rooms Basic, free up to 25 rooms, is enough) or the Google Meet API enabled.

Network

The complete matrix, flow by flow, is in chapter 6.

05 Server sizing

Four tiers, from a pilot site to a 500-screen estate. The sizing is deliberately generous: the real footprint is lighter.

Tier 1 — up to 50 screens

Pilot deployment, single office.

Estimated load: ~1 request/s, 50 active real-time connections. An entry-level VPS or a local mini-PC is perfectly adequate.

Tier 2 — 50 to 150 screens

Single site, or a modest multi-site setup.

Estimated load: 3 to 5 requests/s, 150 real-time connections, broker arbitration every 60 s. A standard VPS is ideal.

Tier 3 — 150 to 300 screens

A campus, or busy multi-site.

Estimated load: 5 to 10 requests/s, 300 real-time connections, broker across several organisations. A dedicated server or a CPU-optimised VPS is recommended, with automated daily backups.

Tier 4 — 300 to 500 screens

Estimated load at 450 screens: ~15 requests/s sustained, 450 permanent real-time connections, and a broker potentially covering dozens of multi-organisation rooms. RAM is the main sizing factor.

Additional recommendations at this tier:

• A dedicated server (bare metal or a compute-optimised cloud instance) rather than a shared VPS.
• Automated daily off-site backup — a single volume holds the entire state.
• Availability monitoring on the /health endpoint.
• TLS mandatory.
• A UPS, or automatic service restart (already configured by default).

Summary

06 Network flow matrix

Every flow, source by destination — hand this table straight to your network or security team.

1 · Screens → Server (internal network)

2 · Admin workstation → Server (internal network)

3 · Provisioning & whiteboard (internal network)

4 · Server → Calendar providers (outbound internet)

4 bis · When that outbound path goes through a proxy

On a closed network the flows above do not leave directly: they cross a corporate proxy, sometimes paired with TLS inspection. Two points decide whether the installation succeeds, and neither is guessable.

Declare the proxy in the environment: block of the server service — not in the .env file alone, whose contents never reach the container:

environment:
  HTTPS_PROXY: http://proxy.company.local:8080
  HTTP_PROXY: http://proxy.company.local:8080
  NO_PROXY: localhost,127.0.0.1,10.0.0.0/8

Behind TLS inspection (Zscaler, Netskope, Fortinet…), the appliance presents a certificate signed by an internal authority. The server must be given that authority — mount the file, then point to its path inside the container:

volumes:
  - /etc/ssl/certs/company-ca.crt:/app/company-ca.crt:ro
environment:
  NODE_EXTRA_CA_CERTS: /app/company-ca.crt

Turning certificate verification off instead would expose the traffic — calendar tokens included — to anyone on the path. Kelra Room offers no such setting.

5 · Server → SMTP relay (outbound)

6 · Screens → Video-conferencing platforms (outbound internet)

These flows leave from the room screen's network, through the browser, and never from the server.

Firewall rules at a glance

07 Installation

Allow half a day for the server and the first room, then about ten minutes per additional room.

Server

The server ships as a deployment bundle containing the service image and its orchestration file. Bringing it up takes three steps:

1. Drop the bundle on the Linux machine and fill in the .env configuration file — at minimum a long, random administration secret.
2. Start the service. It restarts automatically when the machine reboots. Start-up

   docker compose up server -d

3. Check it. The API answers on http://<SERVER_IP>:4001, the console on http://<SERVER_IP>:4001/admin. The /health endpoint returns the exact version deployed.

Encrypting the traffic (TLS)

The server can serve the console and the API over https with no extra component. Three modes, chosen in the .env file:

The local authority, in practice

TLS_NAMES lists the names and addresses the server will be reached by — for example 192.168.1.10,rooms.internal,localhost. They are written into the certificate: an address missing from that list will be refused by the browser. The authority created stays stable and survives renewal of the server certificate: screens already deployed need no further action.

• Admin workstations — the authority is downloaded from /tls/ca.crt and installed once into the machine's or the domain's certificate store. The console is then served without any warning.
• Room screens — the Windows application fetches the authority on first contact with the server and pins it. It then refuses any different authority: a server swapped in later is rejected, not silently accepted. The fingerprint is printed in the server's start-up banner and logged by the application at the moment it pins — comparing them once is your verification.

If the kiosk address was left on http

This is the most common oversight after a switchover. An address left on http:// against a server listening over HTTPS made the screen unusable with nothing naming the cause: the QR code link landed on a 404 — often the corporate proxy's, which therefore appeared to blame the application — and the screen's countdown kept running while the console answered "Link expired".

Three safety nets now catch the oversight. They do not replace fixing it.

• The kiosk corrects the address by itself. It asks the server at startup, then again from the screen's own browser, and uses the scheme the server actually serves. The correction applies to the current session and is not saved.
• The screen says so, and the log repeats it. A banner announces the correction; docker compose logs kiosk gives the configured address, the one in use, and the variable to fix. Fixing OPENROOM_SERVER_URL is still required — otherwise the mismatch returns at the next deployment.
• The server names the failure. A cleartext request on an HTTPS port produces no reply at all: the handshake fails before the application exists, and no redirect can be sent. docker compose logs server now carries a [tls] ⚠ une requête en CLAIR est arrivée sur ce port line.

Behind a reverse proxy that terminates TLS (Caddy, Traefik, Tailscale), the server listens in cleartext while its clients speak HTTPS. It then follows the x-forwarded-proto header, which those proxies set by default, and correctly announces https://. The header is consulted only when the server does not encrypt the traffic itself: no forged request can make an encrypted server announce a cleartext URL.

The other routes

Room screen

A single Windows installer, supplied by Kelra. It bundles the application, its service and its runtime: nothing else to install on the machine, no virtualisation layer.

What the installer does

• A per-machine install, into Program Files — elevation is requested once. It is necessary: in kiosk mode the screen runs under a dedicated account, separate from the technician's.
• On first launch the application registers itself to start at logon. This can be disabled if you drive start-up through a Windows policy.
• The application is already full screen, with no address bar and no tabs.

First launch

1. Enter the server address on the first-launch screen, by touch. A “Test connection” button validates the address; saving is only possible after a successful test, and only once — an address that could be changed at any time would let any machine on the network redirect the screen to a server it controls.
2. Provision the screen: it then shows a QR code, valid for 5 minutes and refreshed automatically. Scan it with a phone — or open the URL printed underneath from a machine that can reach the server — pick the room from the list and confirm. The screen configures itself within seconds.
3. Set the machine's clock and time zone — see the box below.

Locking Windows down on top

The application is already locked full screen. Windows kiosk mode adds only three things: preventing escape to the desktop, restarting the application if it closes, and barring other programs.

Silencing the browser's prompts

Do this once per machine. A room screen must ask for nothing: you press “Join” and you are in the meeting. The application already prepares the video-call profile at every launch — translation off, notifications and geolocation blocked, camera and microphone granted upfront to the known platforms, first-run banners dismissed.

One dialog remains that only an enterprise policy can remove: “This site is trying to open Microsoft Teams”. The Teams web page tries to launch the desktop application, which has no business being installed on a room screen. An Edge policy blocking the msteams:, msteams-enterprise:, zoommtg: and zoomus: protocols removes it silently — the exact procedure ships with the product.

What remains: Teams shows its own page — “How do you want to join your meeting?” — with a “Continue on this browser” button. That is not a browser dialog but the content of Microsoft's page, and no policy reaches it. One tap is therefore still needed for Teams meetings. URL parameters that bypass it circulate, but Microsoft does not document them: hard-wiring those would make meetings open, across an entire estate, on behaviour that can change without notice.

Addresses used by the QR codes

Shared URLs — the whiteboard QR, the provisioning QR — must never contain localhost. The screen detects its local address automatically, discarding virtual adapters. If detection picks the wrong interface, the address can be forced through configuration. Remember to allow the relevant ports in the Windows firewall, or attendees who scan the QR will not reach the whiteboard.

08 Configuration

Everything is set from the admin console, except the prerequisites to create at Microsoft and Google.

Console and accounts

The console opens at http://<SERVER_IP>:4001/admin.

1. First sign-in — on first start the server creates an admin / admin account. A password change is enforced straight away, and until it is done the whole API refuses to answer. A well-known default credential pair is the first thing bots try; the lock exists so that a forgotten deployment does not stay open.
2. Named accounts — Accounts tab: one account per administrator. All have full access; to separate several entities, deploy one instance per entity rather than sharing this one.
3. Connect an organisation — Organisations tab: Microsoft 365 and/or Google Workspace (next sections).
4. Create the rooms — Rooms tab: name, description, resource calendar address (e.g. room-a@mycompany.com), organisation, theme, logo.
5. Provision the screens — by QR code from each screen, or by creating the device by hand in the Devices tab.

Connecting Google Workspace

On the Google Cloud side

1. Create a project — or reuse one — in the Google Cloud console.
2. Enable the Google Calendar API. For instant meetings, also enable the Google Meet API.
3. Create OAuth 2.0 credentials of the “Web application” type and note the client ID and client secret.
4. Obtain a refresh token using the account that has access to the resource calendars. The scopes needed: calendar read, plus Meet space creation if instant meetings are wanted. For multi-organisation arbitration, the full calendar write scope is required.

On the Kelra Room side

Organisations tab → New organisation:

“Verify and save” genuinely tests the credentials before accepting them. The refresh token stays valid until access is revoked; the access token is renewed automatically.

Connecting Microsoft 365

On the Azure / Entra ID side

1. Register an application — App registrations → New registration. Accounts in this organisational directory only; no redirect URI. Note the tenant ID and the application ID.
2. Choose the authentication method — two options, identical in operation. Client secret: Certificates & secrets → 24-month lifetime → copy the secret's value (not its ID). Certificate: upload a public certificate under the Certificates tab of the same page. The certificate is the recommended option, and becomes mandatory where internal policy forbids client secrets.
3. Grant the Calendars.ReadWrite permission of type Application on Microsoft Graph, then click Grant admin consent. That single permission covers schedule display, instant meetings and arbitration. The read-only permission would display the calendar but make meeting creation fail.

Certificate authentication — no shared secret

Many organisations forbid client secrets by policy: a secret is a long-lived string, copied into a configuration file, that nothing distinguishes in an audit log. With a certificate, Kelra Room signs a short-lived token using a private key that never leaves your server; only the public half is deposited in Entra.

Entra does not validate the trust chain of an application authentication certificate: it stores the public key and locates the certificate by its thumbprint. A self-signed certificate is therefore a nominal case, and a certificate issued by your internal PKI works just as well — with the added benefit of your existing governance: inventory, expiry alerts, revocation.

Without a PKI, the utility ships inside the server image:

docker compose exec server node scripts/generer-certificat-entra.mjs kelra-room 2

It produces a .cer — the public certificate, to be uploaded to Entra — and a .key, the private key, to be entered in the admin console and shared with nobody. The thumbprint it prints must match the one the Azure portal shows after upload.

Optional — letting external attendees in

By default Teams puts attendees from outside your directory in the lobby — and nobody is signed in on the screen to admit them. To open the lobby automatically on instant meetings, an extra permission (OnlineMeetings.ReadWrite.All) and a Teams Application Access Policy are needed. Without that configuration instant meetings still work: internal attendees walk straight in, only external ones have to be admitted.

On the Kelra Room side

Multi-organisation broker

Permissions

Wiring a room to its organisations

1. Broker tab → Link a calendar: pick the room, the organisation, and enter the resource mailbox address within that organisation. Each organisation has its own for the same physical room.
2. Repeat for the second organisation. As long as a room has only one calendar linked, the broker has nothing to arbitrate and says so.
3. Synchronise forces an immediate poll and reports the bookings seen, the decisions taken and the errors met.
4. Bookings unfolds what the broker saw and decided for that room: accepted, declined with the reason and the competing organisation, pending, cancelled.

A room accepts only one connection per organisation, and a resource calendar can be linked to only one room within the same organisation — the console explicitly refuses duplicates, which would make arbitration self-contradictory.

Broker settings

Synchronisation covers a window from 1 day back to 60 days ahead. Removing a connection cleans up its mirrors before deleting it.

Email sending and PDF export

Downloading the PDF works with no configuration. Sending it by email requires an SMTP relay, declared on the server side:

SMTP serves two purposes: sending the PDF minutes at the end of a meeting, and sending the whiteboard link to attendees — useful during a video call, when remote participants cannot scan the QR code displayed in the room.

Screen appearance

Appearance changes take effect the next time the screen loads.

09 Operations

Backup, updates, monitoring and usage statistics.

Backup

The server's entire state lives in a single volume: the database — rooms, screens, organisations, licence, arbitrated bookings — and the uploaded logos. Backing up that volume is enough.

Two things are not in it and must be backed up separately: the .env configuration file — organisation secrets, administration secret, SMTP — and your wallpaper library.

The database uses no write-ahead log: a cold copy, with the service stopped for a few seconds, is clean and sufficient. Schedule a daily backup outside meeting hours. A hot copy works in the vast majority of cases but may catch a write in progress — acceptable as a safety net, never for a migration.

Migrating to another server

Restoring the archive on the new machine and copying the configuration across is enough. The licence keeps working: it is stored in the database and tied to no hardware. The trial-period anchor is preserved too — restoring a backup does not hand back another 30 days. Remember to update the server address on the screens if it changes.

Updates

A supplied update script fetches the new version, rebuilds the image and restarts the service. It refuses to run if a file affecting the deployment has been modified locally, rather than overwriting it silently.

On the screen side, updating means reinstalling the supplied executable. The server address, the device key and the wallpapers survive reinstallation: an update never forces you to re-provision a room.

Knowing what is running

The version and the build fingerprint are visible in five places: the server's start-up banner, the /health endpoint, the console sidebar (including before sign-in), the screen's diagnostics panel — which shows both versions, its own and that of the server it queries — and the Windows application log. An up-to-date screen talking to a stale server is therefore obvious immediately.

Monitoring

The /health endpoint is public and unauthenticated: it plugs straight into your monitoring stack (Uptime Kuma, Grafana, Zabbix…). It returns the service state, its version and its build fingerprint.

Usage statistics

Statistics tab, over 7, 30 or 90 days: meetings held, average duration, average attendance, hours occupied, and the split by day, by room and by video-conferencing platform.

The figures cover this deployment. A multi-site customer running one server per site has no consolidated view — that is what the hosted admin console, offered as an option, is for.

10 Security & data

What is stored, where, and what never leaves your network.

Where the data lives

No telemetry is emitted towards Kelra. A deployment with no internet connection works — except that it obviously cannot read a hosted calendar or open a video conference.

Access controls

• Screens — a unique device key, obtained by QR code, never written into a configuration file nor into the code served to the browser. Revocable instantly from the console: the screen then falls back to its provisioning screen.
• Administrators — named accounts, an enforced password change on first access, and an audit log attributed to each author.
• Whiteboard participants — access by session link; the room screen's relay forwards only the routes strictly needed by the whiteboard, and the admin console stays out of reach of the guest network. Every refused route is logged.
• First-launch screen — the server address can be saved only once, and only after a successful connection test, so that no machine on the network can redirect a screen to a server it controls.

On what crosses the boundary between organisations

In a multi-organisation deployment, only the fact that a slot is busy crosses the boundary. The meeting subject, the organiser and the attendee list are never replicated: the mirror posted on the other calendar carries nothing but a neutral title, which you choose.

Third-party components

Kelra Room embeds open-source components, each keeping its own licence — notably the Excalidraw whiteboard engine, under the MIT licence. The exhaustive list of components and their licences ships with the product and is regenerated with every release.

11 Troubleshooting

The most frequent symptoms and their real cause. The screen's diagnostics panel answers most of these questions without leaving the room.

12 Licensing & pricing

One perpetual licence per screen, with no mandatory subscription. Hosted administration is an option, not a toll.

Prices exclude VAT. Volume discount from 20 screens up.

How the licence works

Software licence

Kelra Room is distributed under the Business Source License 1.1 — the same model as MariaDB, HashiCorp or Sentry:

• The source code is supplied, auditable and modifiable.
• Non-production use is free: development, testing, demonstration, evaluation.
• Production use requires a commercial licence, sold per screen, beyond a 30-day trial period per deployment.
• Every release automatically converts to the Apache License 2.0 four years after publication — a deployment is never stranded, whatever becomes of the vendor.

The licence text supplied with the product is the authoritative one; the summary above does not replace it. Third-party components keep their own licences.

13 Support

Before writing to us, three things speed the diagnosis up considerably.

1. The screen's diagnostics panel — a photo is enough. It gives the IP address, the gateway, the server state, internet egress, the state of each calendar, the clock, and both versions (screen and server).
2. The exact server version, readable in the console sidebar or at the /health endpoint — version, build fingerprint and date.
3. What changed recently: an update, a server address change, a permission change on the Microsoft or Google side, a network intervention.