# 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 differs | One account runs the machines | Each person has their own account |
|---|---|---|
| Fits | One person manages the machines; work runs through apps and agents | People who own machines, or manage their own access |
| Who signs in | One person, for the account | Each person, as themselves |
| How work gets access | One application key per workload | Each person's own keys, after the machine's owner invites them |
| Who sets application priority | The account, across all its applications | Each person, for their own applications |
| Ending access | Revoke that workload's key | Pause 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](/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](/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](/machines) switches sharing on (the switch beside **Sharing is off**).
   Switching it on adds nobody.
2. In [Sharing](/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](/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](/sharing) page and
their first request with their own key gets an answer. Adding a person can take up to a
minute.

**Managing access.**

| To | In the web | From the terminal |
|---|---|---|
| Stop requests to one machine from everyone you share with | Turn off **Share from this machine** on the machine's page | `saylek host stop`, on that machine |
| Pause one person | **Pause** on their page in Sharing | Web only |
| End one person's access | **Remove** followed by their name, on their page in Sharing | `saylek sharing revoke --person <name>` |
| Stop using someone's machines | **Stop using their compute** on their page | `saylek 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](/docs/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](/organizations#talk).

**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](/docs/privacy-and-egress) shows how to leave one.

## Reference

- [Sharing and access](/docs/sharing-and-access): how sharing works in each direction.
- [Invite flow](/docs/invite-flow): sending and accepting invitations.
- [Connect your app](/docs/connect-your-app): keys and client setup.
- [Sharing your models](/docs/share-your-models): pausing and stopping a machine.