Turning on emergency access
Set up emergency access (OLCRTC) for your users: Pro subscription, an emergency route, the cluster switch and per-server runtime — step by step, in the right order.
This page is for you, the service owner. It covers how to turn emergency access on so your users can rely on it. For the users themselves there are separate pages: Emergency access — how it works and what to do during a block — and Installing the emergency client — where to download the app and how to install it.
Emergency access (OLCRTC) is a backup channel for allow-list networks where the normal connection does not get through at all. Traffic still runs over your own servers, but it is disguised as a video call on a permitted service. It is not a second protocol and not a replacement for the main one: it's slower, meant for short sessions, started manually by the user, and only for when everything else has stopped working.
The feature is experimental and rolling out in stages. Even with every switch turned on, the emergency runtime may not be installed on your servers yet and session start-up may not be active: access opens up gradually. If a server stays away from "healthy" for a long time after you enable it, the rollout most likely just hasn't reached you yet.
It also does not work on every network or in every country, and it depends on an external video service being reachable (and, for the email path, on mail getting through). Don't promise it as a guaranteed capability — present it as insurance against hard blocks.
What you need
- a Pro subscription (or Max, which includes everything in Pro);
- at least one route marked as emergency;
- the OLCRTC switch enabled on the cluster;
- at least one server in that cluster with runtime enabled;
- users with a verified email and an active account (see the limits section below).
Order of operations
There are three switches, in three different places, and they're easy to mix up — two of them are named almost identically:
| What you enable | Where it lives | What it's called |
|---|---|---|
| Route | route settings (when editing) | "Emergency route (OLCRTC)" |
| Cluster | cluster page, above the route list | "Enable OLCRTC for this cluster" |
| Server | server panel, "Edit" button | "Run OLCRTC on this server" |
Order matters: the cluster will not let you enable OLCRTC while there is no emergency route. Route first, cluster second.
Subscribe to Pro. Go to Billing → subscription block. Without an active Pro the emergency switches are not shown at all: the cluster page displays an "Emergency access (OLCRTC)" card with a "Subscribe" button instead.
Mark a route as emergency — in the route's own settings. Open the route for editing and, in the "Emergency access (OLCRTC)" block, turn on "Emergency route (OLCRTC)".
The switch only appears when editing an existing route. The new-route form doesn't have it: create the route first, then open its settings and mark it as emergency.
The servers on that route join the emergency pool. You can mark several routes — the pool merges them all, and if one route has no suitable server, the connection goes to a server from another. Marked routes get an emergency badge in the route list.
Enable OLCRTC for the whole cluster. This is a second, separate switch — not the one in the route. It lives on the cluster page, in the "Emergency access" block marked OLCRTC, right above the route list, and is called "Enable OLCRTC for this cluster".
This is the master switch: while it's off, users of the cluster cannot request anything, no matter how many routes you marked as emergency. Below the switch you can see how many emergency routes are already in the pool.
Allow sessions on servers. Click a server to open its panel, find the Emergency runtime (OLCRTC) block, press "Edit", turn on "Run OLCRTC on this server" and press "Save".
The runtime installs and updates itself in the background — no need to log into the server. Until it is installed and reporting, the state shows "not healthy"; that's normal, wait for "healthy · N/M active".
The block only appears in the regular interface mode — the simplified Single mode does not have it.
Set the capacity. In the same block — Max concurrent sessions. You may leave it empty, but it's better not to: see the next section.
Tell your users. Emergency access is useless if people learn about it once they're already blocked: the client has to be installed in advance. Point them at Emergency access and Installing the client, and ask them to walk through it once while the internet still works normally.
How many sessions a server can take
An emergency session is not "one more VPN user" — it's considerably more expensive: the server packs traffic into a video stream, and that costs CPU time.
Measured on a live session (Full HD video, about 5 Mbit/s), one session takes roughly 15% of one core and 31 MB of memory. Memory barely matters; CPU is the real limit.
| Cores on the server | Sensible capacity |
|---|---|
| 1 | 3 |
| 2 | 6–7 |
| 4 | 12–14 |
Don't go above these numbers even on a dedicated server: four sessions on a single core is already about 60% of it plus background load. And note the measurement was taken while watching video (~5 Mbit/s); if a user saturates the tunnel, one session can cost noticeably more.
An empty capacity field means "no limit". The only protection left is the automation that stops placing new sessions on a badly overloaded server. It reacts with a delay, though, and on a weak server your regular users will already be suffering by then. On single-core servers, set the capacity explicitly.
Balancing helps to a degree: if the route uses the by load algorithm (the default), a server with high CPU usage reports less free bandwidth and new regular users are routed to less loaded servers. But that is a correction based on overall CPU, not a count of emergency sessions, and it lags by several minutes — it is not a substitute for an explicit capacity.
What the interface shows
In each server's Emergency runtime (OLCRTC) block:
- Capability — whether sessions may run on this server;
- Capacity — your limit on concurrent sessions ("not set" = no limit);
- Runtime — state: "healthy · N/M active", "not healthy", or "not reporting yet".
Right after you enable it, expect "not healthy" — that's normal, the server is still installing the runtime and hasn't reported yet. If it stays that way for a long time, check that the server is reachable at all. "Not reporting yet" only flashes while the page is loading.
Limits worth knowing up front
A session lives up to 12 hours, then stops by itself. It cannot be extended — the user creates a fresh call and requests a new connection.
One session per user. A second request creates nothing while one is running — in the cabinet it says "a session is already running", by email it gets no reply. Worth explaining to users up front so it doesn't look broken.
About 14 Mbit/s down and under a megabit up, with 175–235 ms latency. Watching video and doing email is comfortable; sending large files, video calls and gaming are not. That is the ceiling of the current tunnel configuration, not of the main connection.
The requirements on users are stricter than they look. A verified email is required — users you created manually without one cannot request access. The account must also be active: paused, expired, limit-exhausted and awaiting-first-payment (on_hold — everyone who signed up themselves and hasn't paid yet) accounts are rejected. The email must pass sender authentication, and the rate is capped at five requests per hour per user and a hundred for the whole service.
In the cabinet each rejection is shown with its reason; by email a reply is sent whenever we can recognise the sender as your user (an unauthenticated or unknown sender stays silent). If someone complains that "I asked and nothing happened", start with the account status and the call link they used; for the email path also check that they sent it from their account address and that the mail contained only the room link.
Multi-hop routes don't take part. Only direct routes are used for emergency sessions.
iPhone is harder. The iOS client can only be sideloaded — Apple doesn't carry it. Your iPhone users need to prepare in advance and more carefully; the installation guide covers this.
Turning it off
You can clear Enable OLCRTC for this cluster at any time — new sessions stop being started. Sessions already running finish their term.
The last emergency route cannot be unmarked or deleted while OLCRTC is on: mark another route first, or disable OLCRTC on the cluster.
If your Pro subscription has lapsed, you can still turn things off, but turning them back on requires renewing it.