Skip to content

Set up Saylek for a team

Bring your machines into one setup, or let each person keep control of theirs. Choose who manages access and application priorities.

Choose a setup

What differsOne account runs the machinesEach person has their own account
FitsOne person manages the machines; work runs through apps and agentsPeople who own machines, or manage their own access
Who signs inOne person, for the accountEach person, as themselves
How work gets accessOne application key per workloadEach person's own keys, after the machine's owner invites them
Who sets application priorityThe account, across all its applicationsEach person, for their own applications
Ending accessRevoke that workload's keyPause or remove that person

You can combine them: one account owns the machines and invites each teammate, and each teammate works from their own account. Everyone signs in as themselves and can be removed alone. Application priority then applies within each person's own applications.

Setup 1: one account runs the machines

  1. Connect each machine. Signed in to the account, open Machines and choose Connect a machine. Run the command it gives you on the machine, and approve the machine when it checks in. The account's keys can use a connected machine's models with sharing off.
  2. Create one application per workload. In Applications, choose Add application, name it for the workload, and choose Create key. Store each key as a secret where that workload runs.
  3. Set the order. Under Application priority, drag the most important application to the top, or use Move up and Move down in an application's menu. Give higher-priority applications precedence when requests are waiting for capacity. The order does not reserve capacity or make a request faster. A waiting request gives up after 180 seconds when it streams, 60 when it does not.

You know it worked when each workload's first request with its own key gets an answer.

To end one workload's access, choose Revoke API key in its application's menu; the other keys keep working. Rotate API key replaces a key's secret.

Setup 2: each person has their own account

The machine's owner:

  1. Connects their machines to their own account, then on each machine's page in Machines switches sharing on (the switch beside Sharing is off). Switching it on adds nobody.
  2. In Sharing, chooses Invite someone. One person sends an invitation to an email address. A lab, team or class gives one link, with a limit on how many people can accept it. People who accept the same link get no access to each other's machines.
  3. Optionally chooses Edit schedule on the machine's page to set when it is shared, or runs saylek host hours --set 09:00-17:00 on the machine, in its own time zone.

Each person invited accepts the invitation signed in as themselves, then creates their own applications and keys in Applications and sets their own Application priority. Nobody has to share anything back.

You know it worked when the person appears on the owner's Sharing page and their first request with their own key gets an answer. Adding a person can take up to a minute.

Managing access.

ToIn the webFrom the terminal
Stop requests to one machine from everyone you share withTurn off Share from this machine on the machine's pagesaylek host stop, on that machine
Pause one personPause on their page in SharingWeb only
End one person's accessRemove followed by their name, on their page in Sharingsaylek sharing revoke --person <name>
Stop using someone's machinesStop using their compute on their pagesaylek sharing stop-using --person <name>

Only the person who set up the sharing can remove someone. Removing applies to their new requests; pausing can take up to a minute.

Sharing hours

A machine's sharing hours decide when it takes requests sent through Saylek.

  • Hours use the machine's clock, not the time zone of whoever sends the request.
  • Each period applies on exactly the days you choose. A period that ends the next day belongs to the day it starts: Friday 18:00 to 09:00 runs into Saturday morning.
  • A schedule has at most 5 periods. A period is a set of days with one time range, or all day. Monday to Friday 18:00 to 09:00 is one period; all day Saturday and Sunday is another. Each window in saylek host hours --set 09:00-17:00,23:00-07:00 is one period covering every day. Edit schedule refuses more than 5 rather than cutting the schedule short.

Example: offices in New York and San Francisco

A company has machines in both offices. It runs them centrally and lets its San Francisco engineers manage their own work.

Central control. One account connects nyc-workstation, nyc-inference and sf-workstation. It creates an application for each company workload: Coding agents, Support assistant and Nightly QA, each with its own key, ranked in that order. When requests are waiting for capacity, a waiting Coding agents request goes ahead of a waiting Nightly QA request. Retiring Nightly QA means revoking one key.

Delegated applications. The same account switches sharing on for nyc-workstation and invites each San Francisco engineer. Each engineer signs in as themselves, creates their own applications and keys, and ranks them. Their order applies to their own requests only, and the account's own work has priority on the machines it shares.

Off-hours access. On nyc-workstation, Edit schedule sets two periods: Monday to Friday 18:00 to 09:00 (it ends the next day), and all day Saturday and Sunday. The schedule runs on the machine's clock, New York time, so the machine starts accepting shared work at 15:00 in San Francisco and serves the engineers' afternoons and overnight jobs. The engineers set nothing; the schedule belongs to the machine.

Outside those periods the machine turns away the engineers' requests and keeps serving the account's own keys, so the Coding agents, Support assistant and Nightly QA keys reach nyc-workstation at any hour. A schedule needs Saylek 0.1.1577 or later on the machine: an older version with a schedule set cannot connect until it is updated with saylek update.

Access, priority and privacy

  • Access is per person, not per key. In setup 2 the owner can pause or remove each person. A schedule applies only to the people the machine is shared with; the account's own keys reach the machine at any hour. A key names an application, not a person: it cannot be limited to some models, and every key reaches every model its account can use.
  • An account has no admin roles. Whoever signs in to an account controls all of it: machines, keys and sharing.
  • Priority stays inside one account. Application priority orders only that account's own requests. Nothing a member can set ranks one person above another. On a machine, work its owner sends to Saylek's local API on that machine goes first, and requests sent with a key wait for it or are stopped (Make more of one GPU explains).
  • Not provided: organization sign-in, audit logs and reserved capacity. To tell us what your team needs, use Talk to us.

Privacy. The machine that serves a request reads it in the clear. A machine with sharing on serves the people it is shared with and, if its owner's account is in a group, that group's members. Groups are not part of either setup; Privacy and egress shows how to leave one.

Reference

Last checked 2026-09-29 · read as markdown at /docs/set-up-for-a-team.md