12 November 2026 · VRAMfarm team

Is my data safe on a rented GPU? Who can see it, where it runs, GDPR

Other customers can’t see your data. The host who owns the machine technically could while your server is running, as on any cloud where someone else holds the hardware. After you stop, the server disk is deleted. For most AI work (public models, your own images, training runs, test datasets) that is a reasonable level of safety. For secrets, client data or other people’s personal data, it calls for the precautions described here.

Who runs the machine, and where it is

VRAMfarm doesn’t own data centres. The catalogue brings together machines from vetted hosts, which is how the prices stay low. Three things about each machine are visible before you launch:

• The country. It is shown on every machine in the catalogue and in the picker, where you can also filter by region. “Europe” there is geography, not the EU: it can include the UK, Switzerland or Norway, so check the country code if EU location matters to you. A few machines show “Country not specified”; skip them if location matters.
• Verified or not. By default, the catalogue shows only verified machines. Unverified ones appear only if you tick “Show unverified machines”.
• Reliability, the share of time the machine has run without failures, along with its driver and CUDA version.

So you choose where your job runs. One detail: if the machine you picked is rented by someone else in the seconds before your launch, we take a similar machine of the same type, which can be in another country. The server card in My servers shows the country it actually runs in, so check it before you upload anything sensitive.

What protects your data by default

Your own container. Each server runs in a separate container with its own disk and the GPUs you rented. A large machine can host several customers at once, each in their own container, and none of them can see the others’ files, processes or GPU memory.

Keys, not passwords. SSH accepts only the public key from your settings; there is no password to guess. SSH and scp are encrypted all the way from your computer to the server. The Jupyter link in My servers carries a long token, which works like a password: don’t post screenshots of it. You connect through our address, with a separate port for each server.

The disk is deleted on stop. When you stop, the container and its disk are deleted, and we keep no copy apart from a folder you chose to save. Support can’t restore it either, which is the other side of the same coin. What we can’t give you is a certificate that every physical block of the host’s drive was overwritten. If that level matters, encrypt the data, as described below.

The saved folder is yours only. If you click Save and stop, /workspace goes to storage that isn’t tied to any host. Each customer’s folder has its own access key that opens only that folder, and those keys are stored encrypted in our database. The folder is deleted when you delete it in the dashboard, when you delete your account, or after 30 days at zero balance, with a notice first.

What a host could technically see

A container separates customers from each other. It doesn’t separate you from the owner of the machine. Someone with administrator access to the physical server can, in principle, look into the containers running on it: their disk, their memory, the GPU memory, network traffic leaving the machine. This is true on every cloud where you don’t own the hardware. On marketplace-style clouds with many independent hosts, it is simply more visible.

Vetting hosts, verified machines and reliability scores lower the chance that anyone does this. They don’t make it impossible, and we won’t pretend otherwise. There is hardware that hides a running job even from the machine’s owner (confidential computing on some data-centre GPUs), but we don’t offer it. If your contract requires that guarantee, you need a provider who does.

What our own service sees: connection counts, GPU load and traffic volume, used for billing and for idle auto-stop. Our automation also connects to your server to install a ready-made app, restart it if it crashes, and save your folder when you ask. We don’t sell data, and the ready-made apps run their models on your server, so your prompts are not passed to an outside AI service.

Six ways to lower the risk

1. Don’t upload secrets. No production API keys, cloud admin credentials, .env files from live systems, or SSH private keys. If a job needs a token, create one just for it: a read-only Hugging Face token, an S3 key limited to one bucket, a separate VRAMfarm API token. Revoke it when the job is done. The Last used column in Settings → API tokens shows whether a token is in use.

2. Encrypt datasets for storage and transfer. Keep sensitive data encrypted at home and in your bucket, and decrypt it only on the server, ideally into a folder you won’t save. With age:

# on your computer
tar czf - dataset | age -p > dataset.tgz.age

# on the server (apt-get install -y age)
age -d dataset.tgz.age | tar xzf - -C /root

On Windows, a 7-Zip archive with AES-256 and encrypted file names (7z a -p -mhe=on data.7z dataset) does the same job. Be clear about what this buys you: the data is protected in your bucket, in transit and in leftovers after the stop. While the job runs, the decrypted files exist on the server, so encryption doesn’t protect against a host who inspects a running machine.

3. Keep chats and prompts on your own server. For confidential documents, a private chat on Qwen3 or another ready-made app runs the model on the GPU you rent. Nothing goes to an outside AI API, and the conversation is deleted when you stop, unless you save the folder.

4. Choose the country. If your data should stay in the EU, pick a machine in an EU country, and check the server card after launch to confirm where it ended up.

5. Copy results off, then stop without saving. For a sensitive project, download what you need with scp or rclone and click Stop, not Save and stop. If you saved a folder earlier, delete it in the dashboard when the project ends. The difference between the two buttons is in what happens to your files when you stop a GPU.

6. Send less real data. Debug on synthetic or anonymised samples, strip names and IDs from records, crop faces out of images you don’t need for the task. Data that isn’t on the server can’t leak from it.

On personal photos for LoRA training, a common worry: training on your own face for an afternoon on a vetted machine is a small risk for most people. If you would be upset to see the photos leak, use the smallest set that works (15–25 images is typical), choose the country, and stop without saving. Photos of other people need their permission, which is also a GDPR question.

GDPR in plain words

When you upload other people’s personal data (customers, patients, employees, users of your app), you are the controller and you decide why it’s processed. Whoever processes it for you is a processor, and GDPR expects a written contract with them, the data processing agreement (DPA) of Article 28. We can’t offer one yet: our company is still being set up, and there is no DPA to download. Until there is, don’t process other people’s personal data on these servers unless your own data protection adviser says it’s fine for your case. Anonymised and synthetic data are not personal data and don’t have this problem.

Location. Machines can be outside the EU, and we don’t promise EU-only processing. You see the country before launch and can stay inside the EU by choosing EU machines. Legal questions such as which foreign laws can reach a given host depend on who runs that machine and where. We’ll answer them properly when the DPA exists, not in a blog post.

Certifications. If your contract requires ISO 27001 or similar certified data centres for every machine, a catalogue of many hosts is not the right tool for that project today.

Your account data (email, payment history, SSH key, support chat) is covered by our privacy policy. You can ask to see, correct or delete it. Deleting your account removes your email, name, SSH key and saved folder.

For most work people do on rented GPUs (generating images, training on their own data, testing open models), the default protections plus steps 1, 4 and 5 are enough. For client data, decide before you upload, not after, and if you’re unsure, ask us which part of this applies to your case.