A self-hosted deployment is a promise you make to yourself: the communication your organization depends on will run on infrastructure you control, and you will keep the decisions about where data and media live. RoomHex is designed for that model from the start. This guide walks through what to prepare before you deploy, what is verified to run today, and where the design is heading for larger, multi-site setups.
Start with the media core
The most important part of a RoomHex deployment is the real-time media core, because it carries every call and meeting. This is also the part that is verified to run on a single node today. A single-node deployment of the media plane is documented and has been proven end to end, which makes it a sensible place to begin. You bring a server you control, a domain name, and a valid certificate, and the media core runs behind your own address.
Because the media core is fail-closed, it will not start without its security settings in place, which is a feature rather than an obstacle. It means a misconfigured server refuses to serve rather than serving insecurely. Plan for that behavior so your first startup is a deliberate, checked step.
What to prepare before you begin
A smooth deployment is mostly preparation. Gather the following before the install so the process stays predictable.
- A server your organization operates, sized for the number of concurrent sessions you expect
- A domain name and a valid certificate for it, so clients connect to an address you own
- Network paths that allow real-time media, with relay fallback available for participants on restrictive networks
- A plan for who provisions access, since RoomHex uses reviewed, provisioned access and not public signup
- A backup and update routine that fits your existing operations
None of this requires a paid third-party service in the runtime path. That is a deliberate design choice: the pieces RoomHex needs to run are self-hosted, so your deployment does not quietly depend on someone else's service to place a call.
Thinking ahead to more than one site
Many organizations begin on a single node and later want more capacity, closer placement for distant users, or separation between branches. RoomHex is designed for split and multi-site deployment, with region affinity and separate handling per branch. It is important to be clear that this larger topology is a design goal today, not a verified running configuration. The single-node path is the proven one, and the multi-site design is where the platform is heading.
Planning for that future now costs little. If you keep your naming, access, and backup routines tidy on the first node, extending to more nodes later is far less painful.
A short use case
A regional agency wants to move its internal meetings off a public service. It starts with a single node in a data center it already uses, deploys the media core behind its own domain, and provisions access for a pilot group. Meetings and calls run on that node while the team learns the operational routine. When usage grows and a second location joins, the agency revisits the multi-site design with a clear sense of its own load, rather than guessing on day one.
Decision points before you commit
- Do you have a server and network you fully control for the first node?
- Who owns provisioning, backups, and updates as an ongoing responsibility?
- Are your expected concurrent sessions small enough for a single node to start?
- Do you need the multi-site design soon, or is single-node enough for the first phase?
A self-hosted deployment rewards preparation and a staged approach. Begin with the verified single-node media core, get your operational routine steady, and let the multi-site design guide your growth as your needs become clear. When you are ready to plan the specifics for your environment, a reviewed conversation with our team is the right next step.
- deployment
- self-hosted
- operations