Console
The console is where you create a project, mint the keys a host signs in with, and watch the sessions that project has open.
It reads one project over the same routes the CLI calls. Every panel loads on its own, so one slow read greys one panel and never the page.
Install the CLI
Every bitskiff command on this page comes from @bitskiff/cli, installed from its tarball on the
downloads page: npm install takes a URL as well as a name.
npm i -g https://docs.dev.bitskiff.com/downloads/0.3.0/bitskiff-cli.tgz
bitskiff config set endpoint https://api.dev.bitskiff.com
bitskiff login
The CLI page has the endpoint each environment answers on.
First sign-in
Enter your email address in the console, and we send you a sign-in link. Open it on the same device and you are signed in. On your first sign-in you accept the terms, and the console creates your organization.
There are no passwords. Every link works once, it expires, and it has to be opened on the device that asked for it. A link only signs in the address it was sent to.
Every project, key and session belongs to an organization. To work in a team's organization
rather than your own, ask an owner or admin of it to add your address—bitskiff members invite from the CLI, or the console's
Members panel—and open the link that arrives.
Once you are in, the browser holds the sign-in and refreshes it, so a reload keeps you signed in. Signing out ends it and sends you back here.
The CLI signs in with an organization key instead, which you make in the console's Keys panel. Install the CLI first.
Organizations and projects
The organization is a switcher in the header, because one person is often in several. A project sits under it and holds your keys, your limits and your sessions.
Create a project with a name; the slug comes from the name and the id is the platform's. A project
has no delete. From the CLI: bitskiff projects list and bitskiff projects create.
Keys
One table for the project's keys, each with its scope and its permissions. A publishable key goes in the page your clients open and is bounded by its origin allowlist. A secret key stays on your backend or on a device you control, and carries an explicit permission list.
Create one and the console asks for the type, a label, an expiry and any limits this key should carry below the project's. A secret key adds one question, where the key will live, and fills the permissions in from the answer. The full key string appears once, on the page that created it, and is gone when you close it.
Revoke asks which of two things happened. A key that may have leaked stops now, and the sessions
it opened end with it. A key you are replacing stops now, and its sessions run out on their own.
Rotation is a CLI verb: bitskiff keys rotate <keyId>, beside bitskiff keys list,
bitskiff keys create and bitskiff keys revoke.
The organization's own keys are a second table, under Keys on the organization. That is the key
bitskiff login takes; revoking it stops the CLI on the machines holding it and ends nothing that
is running.
Limits
Every limit the project has, with its effective value, whether the project or a key set it, and the
counter behind it. The concurrentSessions and concurrentClients rows show what is in use now;
the metered rows show this period's consumption and when it rolls over.
Change on a row takes a new value. Every row but one takes a count; the tokensMaxTtl row takes a
duration string. That row shows the length you set—1h, and
never 3600—and its field takes the same spelling back: a bare number is refused before it is
sent.
Lowering applies at once and never ends live work. A raise applies at once too, and binds the next
open or join; see Raises. From the CLI: bitskiff limits reads the
same numbers.
Live sessions
The sessions this project has open, polled while you watch: the session, its state, its label, how many clients are connected, its capacity, and how long ago it opened. A row opens the session page.
Close ends a session: every client is disconnected, the host is told, and the confirmation names
how many clients that costs.
For a host that reopens by itself, closing is not a stop: it opens another session about a minute
later, with a new join code. The wait is the loop's reopenAfterClose, 1m by default; see
Unattended hosts. The code on the host changes, and anyone holding
the old one has to scan again. From the CLI: bitskiff sessions list and
bitskiff sessions close <sessionId>.
The session page
Three parts.
The session is its state, its label and metadata, when it opened, the config it was opened with (each duration as the host wrote it), and the deadlines counting down: host grace left, the idle limit, the longest this session may run, and when the join code next changes.
The roster is one row per client: what it joined as, its number and its grants, its state and
presence, the path its connection took, and the SDK it is running. A client's grants are what it
may do inside this session—sendInput, receiveInput, broadcast, receiveBroadcast,
manage—and the host is the one that sets them.
This session so far is the meters: connected time, messages and bytes by channel and direction, joins attempted, accepted and refused, reconnects and grant changes.
Boot on a roster row removes one client and gives its place back, and the session carries on.
Close session confirms once and leaves you on a page that now names the reason the session ended.
Usage
The meters this project has recorded, by day or by month, over this month or last. There is no currency amount and no tier here.
Usage appears the day after a session runs, because this panel reads the frozen daily and monthly
totals rather than live counters. What is live is on Limits, and each panel says which it is. From
the CLI: bitskiff usage.
Settings
The panel shows the project's join URL, whether end-to-end encryption is off or required, and
restricted mode. It writes two of the three: the join URL and restricted mode. Encryption, and
every other setting, changes from the CLI with bitskiff settings set; bitskiff settings get
reads them all.
The join URL is the page a client lands on after scanning a join code. A new project starts on our sample client page, and this field is where you point it at a page of your own.
Warnings appear under it when the URL will not work: when it is http, when the sample client page
is close to the bound past which new clients are turned away, or when no publishable key allows
that origin.
Restricted mode is a switch: publishable keys stop opening new sessions while it is on, a host opens with a secret key or a token or resumes what it had, and nothing running stops.
Encryption is shown here and not written here. The project's setting holds every session the
project opens; one host can also require encryption for itself with e2ee: 'required' on its
constructor (host package), and the stricter of the two is what a session
runs under.
Webhooks
One https URL per project, and the signing secret your receiver checks deliveries with. The secret
comes back when you set the URL. To read it again, send the same URL to
PUT /v1/project/webhooks: the value is derived from your project, so re-reading it hands you the
secret your receiver already has and breaks nothing. The row in the console afterwards says only
which signing key is in use.
Set the URL here. A URL that is not https, carries credentials, or does not point somewhere
public is refused here rather than dialed later. What the deliveries contain and how to verify one
is the Webhooks guide.
Audit
Every key, limit and webhook action on this project. Filter by action, by actor or by a time range, and page from there.
An actor renders as the person or the key it was. Nothing here can be edited or deleted, from this
panel or anywhere else. From the CLI: bitskiff audit.
Members and invitations
The organization's invitations: who was invited, to what, when the offer expires and what became of it. The panel lists offers rather than people.
Invite someone with an email address and the roles they get when they accept. No row ever shows the link
or the token—that went to the inbox and exists nowhere else, which is why re-inviting mints a
fresh one. From the CLI: bitskiff members invite, bitskiff members list and
bitskiff members revoke.