# Offer Your GPU Server Without Relocating It

Describe a GPU server offered from its existing location: remote access, physical maintenance, schedule, network and responsibilities.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/gpu-owner-no-relocation-brief/
Language: en

To discuss renting out your own GPU server without relocating it, prepare a record of the existing site and operating responsibilities. Describe connectivity, power, cooling, available hours and who can physically reach the equipment. Remote access alone does not make a host ready for another team's workloads.

This is an initial assessment format, not a claim that any particular operator accepts every location or configuration.

## Describe the current placement

Record where the machine is operated at the level needed for a technical discussion, its ownership, permitted uses and existing workloads. Exact entry instructions and sensitive addresses do not belong in a public enquiry.

Vast.ai's hosting documentation illustrates that operating a host involves more than installing a model. An independent operator may use different requirements, so a marketplace checklist should be treated as background rather than automatic acceptance by another team.

## Separate remote and physical tasks

Remote administration can inspect services and perform agreed software changes. It cannot replace someone authorised to inspect a failed cable, supply power or replace a component. State who handles those situations and when they are reachable.

| Responsibility | Proposed party | Evidence or restriction |
| --- | --- | --- |
| Remote administration | Named operator | Defined account and permissions |
| Physical access | Owner or site staff | Available hours and procedure |
| Network incident | Site contact | Support route |
| Data ownership | Relevant project owner | Agreed storage boundary |
| Return to owner | Receiving person | Readiness check |

These entries are proposals for discussion. Do not silently assign work to a third party that has not accepted responsibility.

## Define access without handing over secrets

OpenSSH documentation describes key-based authorisation and its options. For an initial assessment, describe the proposed access method and restrictions; do not send a private key or a shared administrator password.

Agree on which actions require further approval and how access ends. Existing data and unrelated workloads should have explicit boundaries. An operator's ability to log in does not establish permission to alter every service on the machine.

## Present the actual schedule

Separate external availability from research reservations, maintenance and uncertain periods. Include a time zone and a return deadline if the owner needs the machine again. Continuous operation should be stated only when it is actually supported by the site and schedule.

The next step can be a small agreed compatibility check rather than immediate production use. A clear division between remote work and physical support helps determine whether a pilot is practical.

Continue with [GPU Colocation Power Budget: Check the Site Limit](/journal/gpu-site-power-budget/) and [GPU Operator Handover: Issue and Revoke Access Keys](/journal/gpu-operator-key-handover/).

## Official references

- [Vast.ai — hosting overview](https://docs.vast.ai/host/hosting-overview)
- [OpenSSH — sshd](https://man.openbsd.org/sshd)