Open-Source Virtual Office: A Lightweight, Self-Hosted Option for Remote Teams

If you're searching for an open-source virtual office, you don't need the "why" explained. Per-seat pricing on a tool the whole company keeps open all day, presence data you'd rather keep on your own servers, a category with a history of pivots and shutdowns: you're here because of some mix of those already.

The harder part is that there aren't many real options, and the "open source" label hides big differences. Some tools are open-core with the useful parts behind a paid edition, and some need a small fleet of services to self-host. So this article does two things. First, it gives you a five-point checklist for evaluating any open-source virtual office. Second, it walks through one concrete candidate: Hiroba, an Apache-2.0 virtual office with a single-binary self-hostable Rust server and a native desktop client.

What to look for in an open-source virtual office

One thing to fix before the checklist: what job the tool is for. Meetings are already covered; Zoom and Google Meet aren't going anywhere. What a virtual office restores is the moment before a conversation: seeing that a colleague is around, walking over, and asking, "got a sec?" That reduces to two jobs, presence at a glance and conversation without ceremony. Tools that bolt video meetings, recording, and whiteboards on top of those two jobs grow heavy to run and heavy to host, so the checklist below treats the two jobs as the yardstick.

With that settled, these are the questions that actually separate the options. "Open source" on the label doesn't tell you much by itself.

1. What does the license really cover?

Check two things: the license itself (permissive like Apache-2.0/MIT versus copyleft like AGPL, which matters if you plan to modify and offer it as a service), and what's carved out. Some "open source" products are open-core: the interesting parts, like SSO, admin controls, and scale, live in a paid closed edition. Read the repository's license section, not the marketing page.

2. How much work is self-hosting, really?

This is where virtual offices differ most. Some require a docker-compose stack: an app server, a database, a media server (SFU), a TURN server, Redis. That's a real operational commitment; each moving part is something to patch and monitor. At the other end, some servers are a single binary you copy to a VM and run. Before committing, find the self-hosting guide and count the boxes in the architecture diagram.

3. Where does the audio actually flow?

An underrated question. If voice is routed through a media server (SFU), your server needs the bandwidth and CPU for every concurrent conversation, and it technically touches the audio. If voice is WebRTC peer-to-peer, the server only brokers connections, stays cheap to run, and never handles a single audio packet. P2P has limits (mesh audio doesn't scale to big rooms), but for the small spontaneous conversations a virtual office exists for, it's a good trade.

4. Can it stay open all day on ordinary laptops?

A virtual office is only useful when everyone is in it, and the fastest way to kill adoption is a client that makes fans spin. Browser tabs and Electron apps can be fine, but they're fighting their platform's weight. Look for published idle CPU and memory numbers, and test on your team's oldest machine, not your newest.

5. What does it phone home?

Open source makes this checkable, so check it: what telemetry exists, where it's documented, and whether a self-hosted deployment contacts the vendor at all.

Hiroba: an open-source, self-hostable virtual office

Hiroba (Japanese for "town square") is our attempt at the two-job virtual office described above, built to score well on exactly those five questions.

What using it looks like

Your organization gets a floor: a shared lobby in the middle, team rooms around it. When you open Hiroba, your avatar appears on the floor, and that alone tells your team you're around.

• Presence at a glance. The floor shows who's active, away, busy, or already in a call.
• Walk over to talk. Move your avatar near a teammate and spatial voice fades in. No link, no invite, no ceremony.
• Page anyone in one click. For someone in another room, hit Call next to their name in the roster. It's the software version of a tap on the shoulder. During a 1:1 page call you can optionally share your screen directly with that peer.
• No video meetings, on purpose. There's no always-on video, no recording. Meetings stay in Zoom or Meet; Hiroba covers everything between the meetings.

How it's built (and why that keeps it light)

The server is written in Rust (axum + tokio) and compiles to a single static binary. It only moves control data: the roster, avatar positions, proximity decisions, and the WebRTC handshake. Audio never flows through the server. Voice is a WebRTC peer-to-peer mesh (Opus), so the server stays tiny and idle-cheap, and your conversations connect directly between the people having them.

The client is a native Tauri app (a Rust shell around the OS WebView, with a vanilla TypeScript + Canvas 2D frontend) rather than an Electron bundle shipping its own copy of Chromium. In our measurements it idles at roughly 100 MB of memory (measured on macOS; varies by environment) with near-zero idle CPU. It's designed to sit in the background from morning to evening without competing with your actual work.

License and telemetry, in plain terms

Hiroba is Apache-2.0 on GitHub: code, docs, and protocol, with a patent grant. One honest caveat: the "Hiroba" name, logo, and app icons are excluded from the license grant, so a fork can't ship under our branding. Everything functional is open.

Telemetry is limited to the update check in official builds, documented in the README: one row per device per day (platform, architecture, version, coarse country), unlinkable across days and deleted after 90 days. There is no other telemetry: nothing about your org, floor, teammates, or calls. Self-hosted deployments that build their own client never contact us at all.

Self-hosting Hiroba in practice

The short version: copy one binary to a server and run it.

• No supporting cast. No media server, no Redis, no external database. Persistence is optional SQLite, enabled with an environment variable. The architecture diagram has one box.
• No seat limits or feature gating. The self-hosted server is the full product, for as many people as you want to bring.
• Clients are built from the same repo. You build the desktop client with your server's URL baked in; official installers target macOS and Windows.
• Networking notes are documented. Because voice is P2P, most setups need nothing special, but restrictive NATs can require a TURN server; the self-hosting guide covers deployment, configuration, and firewall/NAT details.

And if you like the product but don't want to operate it: there's a managed hosted edition with OAuth sign-in, invites, and billing at $2 per seat per month, with a 30-day free trial and no card required. Details on the pricing page. Same open-source core either way.

When Hiroba is not the right fit

In the spirit of the evaluation criteria above, the honest limits:

• You want meetings in the same tool. Hiroba deliberately has no video conferencing. If you're looking to replace Zoom rather than complement it, this isn't that.
• You need big-room audio. P2P mesh audio is comfortable for a lobby or team room of about five people talking at once. All-hands with fifty unmuted participants is SFU territory, and Hiroba doesn't have one, by design.
• You need mobile. Hiroba is a desktop app for macOS and Windows. It models being at your desk; there's no phone client.
• You want a decorated world. No custom maps, furniture, or mini-games. If the playful-world aspect of tools like Gather is a feature for your team rather than overhead, you'll find Hiroba plain.

Frequently asked questions