Most local AI demos assume a simple setup: one person, one machine, one model and one request at a time.
That assumption disappears when a team starts sharing the hardware.
Now the system has to answer harder questions:
- How do multiple users share compute without sharing identities or private files?
- How do long-running jobs survive a browser refresh or a dropped connection?
- How do you expose a virtual machine in a browser without treating it like a normal web page?
- How do you keep an ARM64 appliance reproducible when models, containers, guest systems and licenses all have different boundaries?
This article documents the constraints we encountered while turning a single AI computer into a predictable, multi-user system. For current implementation details, the source repository is the reference.
The appliance is the real unit of deployment
An AI workstation may look like a collection of containers, but the useful mental model is an appliance with several layers:
Browser clients | v Authenticated workspace | +--> AI jobs: inference, image generation, OCR, transcription, translation +--> Collaboration: accounts, chat, files and permissions +--> Virtualization: Android and ARM64 Windows/Linux guests +--> Shared storage, model caches and task state | v Ubuntu ARM64 + Docker/NVIDIA runtime + KVM | v NVIDIA DGX Spark hardware The browser is the control surface. The Spark is where the work, state, storage and hardware access live.
That boundary matters. A browser refresh should not erase a running job. A virtual machine should not depend on one tab staying open. File permissions should not change simply because a document moved from one application to another.
While building Team AI Box for NVIDIA DGX Spark, we found that the hard part was not adding another chat screen. The hard part was making the appliance behave like a small distributed system rather than a collection of demos.
ARM64 changes the default assumptions
DGX Spark is an ARM64 system with unified memory and an NVIDIA GPU runtime. The host environment is therefore part of the application contract:
- Ubuntu 24.04 ARM64
- Docker Engine and Compose v2
- NVIDIA drivers and container support
- KVM for virtual machines
- Git and Python 3.10+
- Sufficient temporary storage for models, build inputs and generated packages
The build should run on the Spark, not on a developer laptop:
git clone https://github.com/weerocksllc/teamaibox.git cd teamaibox sudo bash install/from-source.sh A successful git clone is not an installation. The source workflow downloads inputs, builds runtime images, prepares a package and installs it. This is why architecture-aware checks and reproducible build inputs matter before the workspace is exposed to a team.
Readiness and task state are part of the UX
“Container is running” is not the same as “application is ready.” A model may still be loading, OCR may not have a usable runtime, or KVM may be unavailable.
A useful system distinguishes between:
process alive -> dependencies reachable -> runtime ready -> accepts work The same principle applies to long-running AI work. Image generation, OCR and transcription should not be represented as a request that either returns immediately or times out. They need durable, visible states:
queued -> running -> completed | | v v failed artifact For supported tasks, the browser can display progress, reconnect after an interruption and recover the current result. The user sees what happened instead of guessing from a stopped spinner.
Files and virtual machines need shared boundaries
Files are part of the AI workflow, not just an upload feature. A document may begin in team storage, become an OCR input, produce Markdown or JSON and then move into translation or an AI assistant. Requiring a new upload at every step creates duplicates and loses provenance.
That workflow only works when applications share a consistent account and permission model. “The service can read this file” is not the same as “the current user is allowed to read this file.”
Virtual machines require another kind of boundary. A browser-based monitor needs to support boot screens, operating-system installation, keyboard and pointer input, audio, reconnection, ISO selection and control handoff. The guest system must also match the host architecture.
The supported path is user-provided ARM64 installation media. Windows licensing remains the user's responsibility, and the project does not claim general x86 guest support.
Local-first does not mean completely offline
“Local” can mean different things:
- Model inference runs on the appliance.
- Files and results stay on the appliance unless an external provider is enabled.
- Installation can happen without network access.
These are separate properties. External model providers are optional, but the first source build still needs network access for dependencies and build inputs. An offline target needs a complete package prepared through a connected workflow.
The same clarity is needed for licensing. The original Team AI Box code and documentation are MIT licensed, but model weights, third-party code, NVIDIA components, firmware, Google services and Windows retain their own terms. The repository does not include signed-in accounts, model weights, guest disks or operating-system ISO files.
The main lesson
Building a shared local AI workstation is not primarily a UI exercise. It combines an ARM64 host, GPU-aware containers, durable AI jobs, shared storage, permissions, KVM virtualization and browser-based control in one appliance.
The browser makes the system feel like one workspace. Underneath, it is a small distributed system running on one physical computer.
That is the useful mental model: define durable state, make readiness visible, treat architecture as a constraint and document the boundaries honestly.
Explore the implementation on GitHub, or read the deployment notes for the current installation requirements.
AI disclosure: AI was used to help structure an early draft. The technical scope should be read alongside the project documentation and source repository.
