Multi-User Usage

gflow's multi-user model is a single machine shared by multiple Unix users, with one shared gflowd and one operating-system account per human user.

gbatch records the submitting username from the current shell environment (USER or USERNAME). By default, gqueue and gstats show the current user's jobs, so day-to-day usage already feels per-user even when the scheduler is shared.

Security Model

gflowd exposes an HTTP API and does not currently provide authentication or RBAC. If someone can reach the daemon endpoint, they can query scheduler state and send mutating requests.

For multi-user deployments, keep the daemon on localhost when possible, or restrict access with SSH, firewall rules, a VPN, or an authenticated proxy.

Recommended Setup

1. Run one shared gflowd on the machine.
2. Give each person a separate Unix account. Do not share one login.
3. Point every CLI to the same local daemon host and port.
4. Treat gflowd and gctl operational commands as administrator-only procedures.
5. Use projects and reservations to coordinate teams.

For Administrators

Run One Shared Daemon

Run a single scheduler for the machine instead of one daemon per user.

[daemon]
host = "localhost"
port = 59000

• localhost is the safest default for shared machines.
• Use a non-localhost bind address only when you have already planned the network boundary.
• State and logs are stored under the home directory of the account running gflowd; see Configuration.

Standardize One Local Endpoint

Every user should point their CLI to the same local daemon. The default configuration is already localhost:59000, so no extra setup is usually needed.

Enforce Admin/User Boundaries Outside gflow

Because gflow has no built-in roles, treat administrator privileges as an operating-system and network concern:

• Only trusted users should be able to reach the daemon endpoint.
• Only administrators should manage the daemon lifecycle (gflowd up, gflowd down, gflowd restart).
• Only administrators should use runtime control commands such as gctl set-gpus and team-wide reservation workflows.
• Avoid exposing gflowd directly on 0.0.0.0 unless you also add external access control.

Standardize Team Metadata

If multiple teams share one scheduler, require project labels:

[projects]
known_projects = ["ml-research", "cv-team"]
require_project = true

Then users submit with:

gbatch --project ml-research python train.py

This makes gqueue --project ..., gstats, and notifications more useful.

Coordinate Scarce GPUs

Use runtime restrictions and reservations when you need to protect capacity:

gctl set-gpus 0-3
gctl reserve create --user alice --gpus 2 --start '2026-01-28 14:00' --duration 2h
gctl reserve list --active

Reservations are especially useful for demos, deadlines, or shared lab time.

Observe All Users

Useful administrator views:

gqueue -u all
gstats --user alice
gctl reserve list --timeline --range 48h

If you need external monitoring or audit hooks, add Notifications.

For Regular Users

Use the Default Local Connection

Submit Jobs as Yourself

• Your job owner is taken from the current shell environment.
• Do not manually override USER or USERNAME when using the shared scheduler.
• Use a separate Unix account for each person instead of a shared account.

Use the Default Per-User Views

The main overview commands already default to the current user:

gqueue
gstats

Use gqueue first when you need to find your own job IDs.

When your team uses project labels, add them consistently:

gbatch --project ml-research python train.py
gqueue --project ml-research

Respect Shared Capacity Rules

• If administrators configured required projects, always pass --project.
• If GPUs are reserved for another user or restricted with gctl set-gpus, your job may remain queued until capacity is available.
• Ask an administrator before using reservation commands for team-wide scheduling changes.

Know When to Contact an Administrator

Contact an administrator when:

• you cannot connect to the shared daemon;
• you need an exclusive GPU window for a demo or deadline;
• jobs are blocked by reservations or runtime GPU restrictions;
• the team wants to change shared project or notification policy.

Common Patterns

Shared Workstation

• All users log in to the same machine.
• gflowd listens on localhost.
• Each user runs gbatch, gqueue, and gjob from their own Unix account.

See Also

• Configuration
• Job Submission
• Tips
• gctl Reference
• gqueue Reference