The instance

Settings → Instance.

This instance

The tab opens on the instance at a glance:

• Live now, peak viewers today, accounts and peers, and, where past broadcasts are kept, what recordings take and how full their disk is.
• Viewers and live channels over the last 24 hours, every channel together: each point is the busiest moment of five minutes. Someone watching from another server counts once for that server.
• What crosses with each peer: their streams here, ours there, and chat both ways, as actually in force -- a box ticked on the Federation tab that the peer has not matched shows here as not crossing.
• Alerts firing, the same ones as Alerts below. A full disk or an engine that stops answering shows here even with no webhook; failed sign-ins and server errors are counted over each minute by the alert checker, which runs only while an alert webhook is saved.

The same figures, and more, are what a Prometheus scrapes; see the operators' Monitoring page.

Name, description and icon

Shown in the page title, on the sign-in page, and in link previews when somebody shares a page from this instance.

Theme

How the instance looks to everyone: its colours, its corners and its typeface. Pick one of eight themes:

Every theme has a dark and a light set: it follows each reader's device, and is dark when the device does not say. Every set meets WCAG 2.2 AA contrast (Control room, AAA), and red always means live and danger.

Preview on this browser paints the theme on your tab only, on every page you open, until you press Stop preview or close the tab -- nobody else sees it. Show picks the set to preview, so you can see the light one from a dark device. Apply to everyone saves it; viewers see it on their next page.

Customize starts Custom from the theme on screen: a dark set, a light set or both, each colour, the four corner sizes, and the typeface. The typefaces are fonts already on each reader's device; nothing is downloaded from anywhere else.

Readers can choose a theme for themselves in their own settings; yours is what everyone sees until they do.

Identity provider

Where sign-ins go, if the instance uses one (Authentik, Keycloak, any OpenID Connect provider): its issuer URL, the client ID and secret, and how its button is labelled. Changes take effect at the next restart of the server.

If the operator configured the provider through the server's environment instead, this section is read-only -- the server's settings win, and a change here would do nothing.

When setting up the provider: create the application with the authorization code grant and the openid, email and profile scopes, and redirect URI https://<your instance>/auth/callback. Admins are the members of the group named by the operator (vibe-live-admins by default), sent in the provider's groups claim.

Documentation

This documentation is built into the app and served at https://<your instance>/docs/. Documentation chooses who may read it:

• Only admins (the default): everyone else gets "not found", and no link to it appears.
• Signed-in accounts: anyone with an account here; someone signed out is sent to sign in.
• Everyone: public, like the instance's terms.

A Documentation link appears at the foot of every page for whoever may open it. Until you choose, the server's VIBE_LIVE_DOCS_ACCESS decides (off unless the operator set it).

Seeking through live streams

Let viewers seek through a live stream -- on by default. Viewers can drag back to any moment of a stream in progress, from its start, and return to live. It changes the next stream that starts, not those already live. Nothing is kept after a stream ends because of it: that is past broadcasts, below. The server records each live stream for it, and deletes the recording when the stream ends unless it is kept.

Past broadcasts

Streams kept after they end, for viewers to watch again. Off by default: nothing is kept until you allow it here AND each streamer turns it on for their own channel.

• Let streamers keep their streams as past broadcasts -- the switch. Turning it off hides every past broadcast at once and keeps no new one; what is already stored stays until you delete it or it expires.
• Keep each one for -- days; 0 keeps them until deleted.
• Disk limit (optional) -- how full the disk may get, like 80%, or how much recordings may take, like 50GB. Leave it empty for a disk that grows with its use.
• Per streamer (optional) -- the most one streamer's past broadcasts may take, in GB.
• Stitch a stream that comes back within -- minutes, 15 by default, 0 for never. This is what a stream is on this instance: a streamer whose PC crashed, or whose encoder dropped, and who goes live again within that time continues the same stream -- one entry in their stats and export, one title -- and, when kept, the same past broadcast: one replay, with both parts in order, rather than two. A longer stop ends the stream. It applies whether or not past broadcasts are allowed.
• Keep past broadcasts in these qualities too -- none by default. After a stream ends, each quality ticked is made once from the kept recording, with this server's own ffmpeg, so a viewer on a weak connection plays a smaller one: the replay's player moves between them as their connection allows. A quality taller than the stream is skipped. They are made one broadcast at a time, by one server where several share the database, and a replay plays in its original quality until they are ready. They take more disk -- roughly 40% more for 720p beside a 1080p stream, 15% more for 360p -- and the size shown and every limit count them. Each streamer can turn them off for their channel. A replay bound for a bucket is uploaded once its qualities are made, with them. Hidden on a server without ffmpeg.

Past a limit, the oldest go first -- that streamer's own for their limit, anybody's for the disk -- and a stream in progress is never cut short: if nothing old is left to delete, it simply is not kept. Under the switches the page says what recordings take and how full the disk is.

Where this server keeps them, and whether streamers bring their own:

• On this server's disk -- the default.
• In this instance's bucket -- an S3-compatible bucket you set up below (AWS, B2, R2, Wasabi, a MinIO or Garage of your own). Each replay is uploaded when its stream ends and served from there through links that expire; only a few kilobytes stay here.
• Nowhere -- this server keeps no replays of its own and is only the middleman: streams are recorded while they run, and kept only for streamers who brought their own bucket.
• Let streamers keep their past broadcasts in their own bucket -- each streamer can then enter a bucket in their settings. Their replays are uploaded to it as soon as each stream ends, and your copy becomes a cache: dropped past your limits, the replay then plays from their bucket.
• Keep each streamer's newest here -- a count, alongside the size limit.

The limits above -- retention, disk, per streamer and this count -- limit what you keep. A replay that also lives in the streamer's bucket only loses your copy; one that does not is deleted.

This instance's bucket: endpoint, region, name, an optional folder, path-style addressing for self-hosted stores, and a key pair. Save, then Test, which writes and deletes a small file and says what the bucket answered. The secret is never shown again. Forget this bucket leaves what is in it where it is.

If the media engine records nothing, the page says so instead: no stream can be kept on that instance. Where recordings are stored on the server is the operator's choice (VIBE_LIVE_RECORDINGS_DIR, see Operators).

Every past broadcast

Below the settings, every past broadcast on the instance with whose it is: filter by streamer or title, sort newest or largest (the line above the list says who takes the most). For each one you can rename it, change who sees it, delete it, or hide it -- moderation: a hidden broadcast plays for nobody but its streamer and the admins, its files included, and only an admin can list it again.

Streamer stats

Streamers see how their streams went on their own Stats page: how many watched over time, how long they stayed, and who came back. Viewers are kept only as anonymous codes, never their address or account.

Keep figures for sets how long that data is kept, from 1 to 365 days (90 by default). Older figures are deleted within the hour after you shorten it, and a streamer's figures are always deleted with their account.

Alerts

Alerts posts a message to a webhook of yours (Discord, Slack, or anything that accepts their shape) when something needs you:

• the disk recordings are written to gets fuller than the share you set (90% by default);
• recordings take over 90% of the size you allow them;
• the media engine stops answering;
• more failed sign-ins in a minute than you set (10 by default), which is usually somebody guessing passwords;
• more than 5% of answers are server errors.

The site checks every minute, and each alert is sent once when it starts and once when it clears. Send a test checks that messages arrive. The webhook is saved encrypted and never shown again; leave the field empty to keep it, or Turn alerts off to forget it. Running Prometheus instead? The same alerts exist as rules, see the operators' Monitoring page.

Rate limits

Rate limits says how many requests each limit allows per window before refusing the rest -- password guesses on one account, sign-ins from one address, lookups and peer servers' requests, Fediverse deliveries, mentions, chat messages and the others, each with a line on what it bounds. Change the count or the window and Save: it applies at once on the server that answered and within 30 seconds on every other. Default puts it back.

No limit can be switched off: a count is at least 1 and a window between 10 seconds and a day. The limits against guessing a password or a second factor stop at 100 per window, since above that they no longer stop a guesser. Refused is what each limit refused since the server last started; the same figure is vibe_live_rate_limited_total for a Prometheus.

Instance (shown once you have peers) picks whose limits you see: All instances by default, or one peer server. For a peer, the limits its requests go through -- lookups and peer requests, Fediverse deliveries, signing in from it -- can be set apart from everybody else's, for a busy peer that keeps hitting them. Its refusals are counted apart too. A request is counted as that peer's only when it says it is signed by it, and per address, so somebody merely claiming to be a peer from elsewhere cannot use its allowance up. Same as all drops the peer's own limit.

Media engine

Read-only: which engine carries the video on this instance, and what that gives you here --

• Go live from the browser
• End a stream from the app (force-stop)
• Asks the engine whether a stream is really live
• Preview images of live streams
• Viewers can choose: the qualities on the player's menu

The engine is chosen by the operator when the server is deployed, never from this page. What each engine offers, and how to change it, is in Choosing and swapping engines.