Self-hosted AI on a VPS: check model rights and provider terms

Identify what is being used and by whom

“Self-hosted AI” describes a deployment choice, not one rights package. A single service can combine a base model, a converted or quantized file, adapters, runtime code, a web interface, prompts, private documents, generated responses and a network provider. Each may have a different author, license, contract or rule. Start with an inventory that names the thing and the activity; a model family name or a VPS label is too broad to review.

Product and artifact inventory

Record each component independently. A model repository can contain multiple revisions, files and license notices. A quantized conversion may have a different maintainer and provenance from the original weights. A runtime may have its own source-code license, while an adapter, tokenizer, projector, evaluation set or UI plugin has separate terms. Do not assume a software license grants rights to the weights it loads, or that access to a repository means every downstream activity is permitted.

Include the data path as well as software: training or fine-tuning inputs, retrieval documents, prompts, uploaded files, logs, feedback and outputs. Note whether the service only runs for the operator, serves employees, accepts public requests, or is resold or embedded in another product. Those uses can raise different questions even when the binary stays on one server.

Keep identity precise enough that another reviewer can retrieve the same material: a URL plus revision or file digest where available, capture date, and the exact notice text or document version. If a hosted service or third-party API participates, add it as its own service and data recipient; “local model” does not mean every part of the workflow is local.

Entity and intended use

Terms often depend on who contracts, where they operate, what they do, and whether a service reaches other users. Write down those facts before asking a broad question such as “Is AI allowed?” The answer may differ for an internal prototype, a commercial customer-facing feature, redistribution of weights, or providing access to a hosted service. This article does not determine the legal significance of those distinctions.

Use one row per materially different use rather than a single broad description if the same model serves different audiences or handles different data. Preserve what is undecided as undecided. If you change the model revision, add a public API, accept new data categories, or begin resale, reopen the relevant rows instead of treating the first review as permanent.

Review rights in each artifact and data set

Make a rights map across the whole chain. The model’s license or access agreement may be different from the runtime’s code license, the dataset’s terms, the uploader’s rights in a converted file, the terms for user prompts, or the rules governing generated output. Provider terms govern the hosting relationship; they do not supply missing rights to a model, dataset or customer content. Conversely, a model license does not establish that a particular VPS product or workload complies with its service terms.

Repository hosting documentation can help locate license information and repository-level metadata. Hugging Face’s documentation describes how licenses are represented in repositories and model cards; it is a discovery aid, not a certification that an artifact is correctly labeled or that your use falls within its terms. Inspect the exact repository revision, linked license text, access conditions and any separate notices. Where provenance is unclear, record that gap rather than inferring a grant from a familiar model name.

For each row, capture the license or contract title and version, exact source URL, the date reviewed, relevant notice or section, and the question still to answer. Consider separate entries for:

• Base weights and associated files: repository, revision, license, gated access, use restrictions, attribution or notice requirements, and any stated conditions on distribution.
• Conversion and quantization: source artifact, converter and conversion file provenance, who created the derivative, and whether downstream terms or attribution notices are documented. Do not assume a file format settles copyright or license questions.
• Adapters, tokenizers and projectors: the component’s own source, license and relationship to the base model. Identify the exact combination you intend to run.
• Runtime, UI and extensions: code license, included dependencies, plugin terms, and any separate commercial or hosted-service conditions. A permissive code license is not a blanket rights grant for model files or data.
• Datasets and retrieval content: source and collector, access terms, redistribution limits, confidentiality, personal information, retention, and authority to index or transform. A document that can be read is not automatically a document you may republish or expose in responses.
• Prompts, uploaded material and logs: who supplied them, what the service does with them, who can access stored copies, and the agreed retention or deletion path. Do not assume a self-hosted process resolves obligations to users or data subjects.
• Outputs and marks: identify what the artifact terms say, if anything, about outputs, and separately review any applicable user, customer, confidentiality or trademark obligations. Avoid claiming an output is unencumbered solely because a model generated it.

For an unclear scope, formulate a narrow question using the actual facts: “For entity X, in jurisdiction Y, using artifact revision Z for internal summarization of documents we are authorized to process, which clause governs this activity?” Send it to qualified counsel when it asks for a legal interpretation. Preserve the answer, date, assumptions and reviewer; a short email without scope is not a general license. This page cannot decide fair use or any other jurisdiction-specific exception. That analysis depends on facts and law outside these captured sources.

Also record acceptance history. Note who accepted gated terms, what version was presented, the account or organization involved, date and scope, and where evidence is stored. Acceptance by one person or account may not answer whether the correct entity accepted the terms or whether they cover later changes. Do not place credentials or private account tokens in this register.

Review provider AUP and service terms

Provider review is a separate track. Select the actual contracting entity, product and region, then read the applicable acceptable-use policy (AUP), service terms, product description and any incorporated terms together. Capture the version or effective date, URL and retrieval date. A marketing label such as “AI-ready,” “unmanaged,” “GPU,” or “root access” describes neither every contractual condition nor an answer to a specific use question.

Read the selected product terms

Do not stop at a general help page if the order is governed by a contract, product-specific schedule or later policy. Record the legal provider entity and customer entity; product/SKU, region and billing arrangement; applicable AUP and service-term links; effective dates; and any order-specific agreement. Add the support boundary, abuse-notice process, suspension or termination provisions, appeal or response process, data handling after termination, traffic conditions, and rules for customer-facing or resale activity.

Read policy language in context and keep its limits visible. A term may describe prohibited content, network conduct, excessive resource use, reporting, or the provider’s response to complaints. Those are distinct issues. The provider’s ability to suspend a service is an operational risk to record, not a conclusion that a particular use violates the policy. Likewise, a term that does not name your workload is not affirmative permission.

Ask the provider a scoped question when the written material does not address the planned pattern. Include the product and region, whether inference is interactive or batch, approximate traffic shape if known, who can call the endpoint, and whether you will expose or resell access. Ask which terms govern and retain the response, date, respondent role and stated scope. If the response is conditional, preserve the condition as an acceptance item. The provider can clarify its own product terms; it cannot decide model-license ownership or give your business a legal opinion.

Use examples only as examples

The evidence packet contains two bounded provider examples. They illustrate why the exact clause and product matter; neither resolves every AI workload.

Contabo’s captured General Terms and Conditions state an effective date of December 2025. A separate captured Contabo help article says servers are generally unmanaged root servers and describes use as subject to German law and Contabo’s terms; it also describes an abuse-notice process that can lead to suspension if specified action is not taken by the stated deadline. This is a dated statement in those captures, not a legal conclusion or blanket approval of self-hosted AI. Confirm the current contract, selected product and applicable policy before relying on it.

A Contabo traffic help capture says there is no default bandwidth limit for the named VPS, VDS and dedicated-server categories, while a fair-use policy applies and unusually high or disruptive use can lead to discretionary throttling. Its described product scope and captured wording do not establish a universal unlimited-transfer entitlement, a price, or an AI-specific allowance. If traffic is material, ask about your selected product, measurement and operational pattern. Send any resulting billable assumptions to the storage and egress worksheet.

The Vultr AUP reading record retrieved on November 6, 2026 reports March 11, 2026 as the page’s “Last Modified” date. It is a reader-produced, limited excerpt; the direct HTML capture was unavailable. It describes an AUP incorporated with applicable service terms, gives examples that are not exhaustive, and reserves policy-change and enforcement powers. Its sample list includes cryptocurrency mining. That item is not evidence that AI inference is equivalent to mining, and the excerpt does not establish categorical permission or prohibition for self-hosted AI. Recheck the complete current policy and exact product terms at the canonical page before drawing a product-specific conclusion.

Provider-owned product pages belong to the provider comparison pages and should be linked only for current product facts. Do not infer model rights from an AI product page, service permission from a GPU listing, or free unlimited AI traffic from a fair-use summary. Unknown terms stay unknown until the selected provider answers them.

Questions requiring provider clarification

Send a concise, factual request tied to the planned service. Avoid asking for an abstract “AI approval” that leaves the provider unable to identify the product or traffic pattern. For example, adapt this question set:

1. Which current AUP, service terms and product-specific conditions govern [named product, region and contracting entity] for [described model-serving task]?
2. Do the terms distinguish internal use from serving external users, embedding access in a paid service, or reselling the underlying infrastructure? Which clause and written permission process apply?
3. What traffic, resource-use or abuse conditions are relevant to the described request and response pattern? What measurement basis, notice process and response deadline apply?
4. Which service components are supported, and what happens to service access and stored customer data if the provider suspends or terminates the product?
5. Does this response address only provider terms for this named product, or does it include another specifically stated scope?

Attach no secrets or customer records. Replace brackets with your real facts, keep the original question and response together, and do not treat silence or a generic sales reply as a binding exception. If the provider cannot answer, mark the row open. Keep endpoint exposure and access control as a separate engineering decision; the private network and bind guide covers caller paths, while this article does not certify an endpoint as safe.

Decision register and pause conditions

Use this register as the handoff record. A row is “closed” only for its named question, artifact revision, use, entity and date; it is not a general legal approval. Keep source documents or stable internal references with the register and limit access where they contain confidential terms or personal data. One reviewer should own each open question, and another responsible person should be able to see why the decision was made.

For each row, include a source link or controlled document reference, retrieval date, relevant clause, exact question, reviewer, response and limitations. Record whether a provider response is written, who gave it and what named product it covers. For license acceptance, retain the presented text or version and the accepting entity’s record. If an answer depends on an assumption, copy that assumption into the register and make it a condition to recheck.

Pause the affected use when you cannot identify the exact artifact or its provenance; a license or gated-use condition is missing; the intended entity, audience or distribution model differs from the reviewed facts; the data source or processing authority is unresolved; provider terms do not clearly cover the selected product or traffic pattern; a suspension or termination condition has no operational owner; or the only answer is a slogan, product label or uncited verbal assurance. “Pause” means do not rely on that unresolved assumption to proceed with the planned hosting or public service; it is not a finding that the use is lawful, unlawful, permitted or prohibited.

Escalate legal interpretation to qualified counsel with the documents and facts, including jurisdiction. Ask the provider about its own product terms and preserve the answer. If either answer changes the architecture, update the component and data inventory, not just a note. Then assess the operational consequences: who can disable service, how users are notified, what data remains accessible, and what the exit plan requires. Article 9’s termination and data-exit checklist helps inventory state and residual cost; it does not supply a provider’s current cancellation terms.

Revisit the register when the model revision, conversion, runtime, dataset, user group, paid use, endpoint exposure, provider product, region, policy version or law changes. Assign a date or event trigger rather than leaving “review later” ownerless. A closed row with a changed input returns to open until the changed scope is reviewed.

Evidence and updates

Source captures checked 2026-11-06. The provider examples below are historical, bounded readings, not current legal advice or universal workload rulings. Recheck the complete current terms for the selected product, exact contracting entity and intended use before procurement or service launch. Artifact licenses and repository contents can also change; retain the exact revision reviewed.

• Contabo General Terms and Conditions — capture stated effective December 2025; historical text for the named provider, subject to current contract and product verification.
• Contabo: restrictions on content allowed on a server — captured help-center example about unmanaged servers, terms and abuse handling; not an AI-specific ruling.
• Contabo: bandwidth and traffic limits — captured fair-use and product-category example; no universal free-transfer or AI allowance inferred.
• Hugging Face Hub documentation: licenses — repository license discovery context; inspect the exact artifact revision and license text.
• Vultr Acceptable Use Policy — canonical current-policy destination. The March 11, 2026 research record is a limited reader-produced excerpt because direct capture returned an access error; verify the complete current policy and applicable service terms.

AI28’s captured Vultr page was rejected as positive evidence because the capture failed; it is not used here. AI22 was also rejected and supplies no rights or provider claim. The Vultr example above relies only on AI51’s limited reading record, with its scope stated. This article provides a decision register, not a legal opinion or confirmation of a provider response. For the wider decision sequence, start at the Local AI VPS hub; use the cost, exposure and exit links above for their separately owned decisions. See Methodology for the site’s evidence approach.