Can multiple people share one GPUwerk DGX Spark?

Yes, but a Spark is root SSH into a single container, not a managed multi-tenant platform with built-in user roles. Sharing it well means setting up Linux users and SSH keys yourself, or putting a gateway like LiteLLM or Open WebUI in front so most of the team accesses it over HTTP instead of SSH.

Does GPUwerk provide team accounts or user roles?

GPUwerk's console handles billing and instance control for the account that deployed the instance. It doesn't manage per-teammate access inside the container; that's configured by whoever holds root, the same as any server you'd administer yourself.

What's the easiest way to give a team access without sharing SSH keys?

Run a gateway such as LiteLLM or Open WebUI on the Spark and give each teammate their own login or virtual API key to that gateway instead of an SSH key to the machine itself. Most day-to-day usage, chatting with the model or calling the API, never needs a shell.

Docs analysis

DGX Spark/Team and multi-user access to a shared DGX Spark

Team and multi-user access to a shared DGX Spark

By Samuel Seidel · Published September 9, 2026

A Spark instance is one container with root SSH access, not a managed platform with team seats and roles baked in. If more than one person needs to use it, that's a setup decision you make, not a switch GPUwerk flips. There are two reasonable patterns, and which one fits depends on whether your team needs a shell or just needs the model.

What you're actually starting from

Whoever deploys an instance gets root over SSH into /workspace, per GPUwerk's SSH keys documentation. There's no concept of a second GPUwerk account with scoped access to that same instance; the console and billing are tied to the account that deployed it. Anything resembling team access, separate logins, permission levels, usage limits per person, is something you configure inside the container, the same way you would on any Linux box you administered yourself.

Pattern one: separate Linux users with SSH access

If your team genuinely needs shell access, the standard approach works fine on a Spark: create a Linux user per teammate (adduser), add their public key to that user's ~/.ssh/authorized_keys rather than sharing the root key, and use sudo selectively if they need elevated commands. This keeps a per-person audit trail in auth.log and means revoking one person's access doesn't mean rotating a key everyone uses. The tradeoff is that everyone is still on one machine competing for the same GPU, so a teammate running a heavy fine-tune can slow down someone else's inference session; there's no cgroup-level GPU isolation set up by default; you'd add that yourself with tools like nvidia-smi's MPS or manual scheduling if contention becomes a real problem.

This pattern makes sense for a small team of engineers who all need to poke at the filesystem, install packages, or debug the model server directly.

Pattern two: a gateway in front, no SSH needed

For a team that mostly wants to use the model, not administer the box, put a gateway between them and the GPU so SSH access stays limited to whoever maintains the machine. Two options that run well on a single Spark:

LiteLLM as an API gateway in front of your inference engine. It issues virtual API keys per person or per service, so each teammate gets their own sk- key instead of an SSH credential, and you can set per-key rate limits and budgets from its admin UI without touching the machine's user accounts.
Open WebUI as a chat interface in front of the model, for teammates who want a ChatGPT-style UI rather than an API. It handles its own login and user list, so onboarding someone is a web signup, not an SSH key exchange.

These two combine well: LiteLLM as the API layer, with Open WebUI or any OpenAI-compatible client pointed at it. Most of the team never touches SSH; only the person maintaining the deployment does.

Choosing between them

Ask what the team actually needs to do. Debugging model servers, installing new inference engines, or inspecting logs on disk needs a shell, so pattern one. Sending prompts, building on the API, or using a chat interface doesn't, so pattern two is both simpler to onboard and safer, since it limits how many people hold a credential that can affect the whole machine. Most teams end up with a hybrid: one or two admins with SSH access running pattern one, and everyone else on a gateway.

Practical checklist

Default to a gateway (LiteLLM, Open WebUI, or both) for anyone who only needs to use the model, not administer the machine.
Reserve SSH access, with individual Linux users and keys, for people who need to touch the filesystem or install software.
Never hand out the root SSH key itself to more than one person; create per-user accounts instead so access can be revoked individually.
Remember contention is real on a single GPU: a heavy job from one teammate affects everyone else's latency, since there's no isolation set up by default.
If usage genuinely needs strict per-person isolation, GPUwerk's two-node cluster or a second instance is a cleaner separation than trying to enforce it inside one container.

See the LiteLLM setup guide and Open WebUI guide for the actual install steps, or a first engagement if you want help designing access for a specific team.