MTGPU provisions accounts and SSH access, enforces isolation, and manages workspaces and jobs automatically. Invited users sign in and start working—
no server addresses, key exchange, port opening, or VPN.
MTGPU Server
Install MTGPU on an existing workstation, rack server, or cloud host running Linux or WSL2—with or without GPUs—and define policy in one reviewable configuration. MTGPU handles day-to-day operation—from user lifecycle and shared resources to workspaces, queues, and resource placement. Add more nodes when you need a cluster; the user experience stays the same. CPU-only hosts provide the same managed SSH access, isolated accounts, workspaces, containers, and jobs; GPU-equipped hosts additionally provide GPU discovery, allocation, and scheduling.
One view of every authorized server: hardware, live usage, SSH access, interactive workspaces, Python environments, and job status.
One pool, two ways to work
The same GPUs support fast experiments during the day and long-running work after everyone signs off.
Open a rootless container in a terminal or attach Microsoft's Dev Containers extension to work on the project as if it were local. Start from an approved template, an image saved from your own customized workspace, an OCI image, or devcontainer.json; MTGPU handles GPU visibility, mounts, and lifecycle—and publishes the ports you choose, so Jupyter, TensorBoard, or your own web UI is one click away.
Use mt-job to run native or containerized commands without keeping a terminal open. Declare GPUs, minimum VRAM, CPUs, RAM, and priority; temporary job workspaces are removed and their resources released when the work is done, while execution logs remain available for later inspection and retrieval.
Submit to one server or the cluster. Queues age fairly, placement follows live resource headroom, and replicated scheduler state lets another member take over if the elected scheduler goes offline.
Multi-tenant without the maze
MTGPU uses ordinary Linux security primitives rather than inventing a parallel identity system. Each authorized user receives a private, unprivileged OS account; containers run rootless under that identity.
Scale without a new user experience
MTGPU's cluster job queue works with either layout: shared tenant storage or an independent tenant home on each member. Submit a job from any member and the cluster runs it wherever capacity fits. CPU-only nodes can join the same cluster and receive jobs that do not request GPU resources. With shared storage, account identities and files stay consistent too, so users can move between GPU computers and find the same home, projects, packages, and results—without a separate directory service. With independent homes, jobs use the files on the selected member. Members don't even need to share a network: cluster coordination travels over DirectLink, so machines in different buildings, cities, or clouds join the same queue and it works the same way—no VPN and no port forwarding.
Shared UID/GID allocation protects ownership across Linux and WSL2 members, while storage preflight checks catch filesystems that cannot preserve tenant isolation.
Each node reports its GPU, VRAM, CPU, and RAM headroom. Jobs take GPUs exclusively, share them with a guaranteed VRAM fit, or share them opportunistically with overcommit. The cluster places each job where it fits — and rejects requests the fleet could never satisfy.
Meet users where they work
Use MTGPU inside VS Code or from a terminal. Both clients discover the same authorized servers and provide the same core access and workspace operations.
Discover servers, compare live usage, and create interactive workspaces. Then launch Microsoft's Remote - SSH or Dev Containers extension to open a host project or workspace project as if it were local; select Python and follow job status from the same MTGPU panel.
Use a keyboard-driven terminal program with similar server discovery, live usage, SSH access, workspace management, Python selection, and job status—without requiring VS Code.
The same job command in either workflow. Run mt-job in an SSH terminal opened by Remote-GPU or remotegpu-cli to submit, inspect, cancel, and automate jobs. Reusable job specifications can stay beside the project that uses them.
Set up in minutes, run headlessly. The guided installer configures Linux and WSL2 hosts, including rootless containers and WSL-specific networking and cgroup requirements. Policy remains in one reviewable configuration file. Want every detail? The user manual covers installation, configuration, workspaces, and jobs end to end.
Connect a host, invite your team, and move from the first interactive experiment to a scheduled cluster job without changing platforms.