naveedharri Rented Server Setup
The cloud counterpart to scan-my-machine. That skill tells someone what their laptop can run. This one runs what it cannot, and it carries two builds because "run a big model in the cloud" has two honest answers depending on usage shape and what "private" means:
- Route A, the EU endpoint. OVHcloud AI Endpoints: a per-token OpenAI-compatible API run by a French company in Gravelines, France. Cents per million tokens, zero idle cost solo. Two shapes: solo, where each user's own app points at the endpoint, and team, where one shared Open WebUI runs on a small OVH VPS for about €5 a month. Multi-tenant either way.
- Route B, the private pod. One RunPod Secure Cloud pod in a region the user picks, two locked doors: Open WebUI behind its login for the team, vLLM's API behind a generated key for Claude Code and other apps. Single-tenant, any model with a vLLM recipe, one shared URL for a team. Bills every hour it exists, used or not.
The order is: questions first, then two named recommendations with prices computed from the answers, then the user picks a provider and everything after is yours: token, wire, prove, report. Beyond creating their own credential they should not have to open a dashboard, paste a URL, or copy an endpoint ID.
Two things are never automatic. The spend, in references/cost-gate.md. And on Route B the region, which the user chooses and you never default.
1. Before you start
Run the check in references/environment-check.md. It is deliberately short: nothing here runs on the user's machine, so do not scan their hardware and do not report on it.
If a local model would do the job, they should be in local-ai-setup instead. Say that in one line and move on.
2. The questions
One AskUserQuestion, three questions, no provider named yet. Full option text in references/model-picker.md section 0.
- What should the model be best at. Show the categories from the open-model leaderboard at https://onyx.app/open-llm-leaderboard — overall, coding, math, chat, reasoning — plus a "name a specific model" option. The recommended default is Qwen3.6-27B: A-tier overall at only 27B, cheap on both providers. Verify whatever they pick live: the OVH catalog (
ovh-endpoints.mdsection 2) for Route A,model-sources.mdfor Route B. - Who will use it. Solo, or a team on one shared URL.
- Usage rhythm. Spiky and on-and-off, or heavy and sustained. This decides the whole cost story, which is why it is asked before any price is shown.
If the user already said any of this, pass it through instead of re-asking. Region and storage are not asked here; they only exist for one route and come after the pick.
3. The recommendation
Read live prices from both providers first: the OVH catalog price for the chosen model or nearest fit, and the RunPod Secure rate for the GPU that model needs. Then show two named options side by side, with links so the user can explore the companies, costs computed from their three answers, and the trust inversion stated plainly:
OVHcloud AI Endpoints — https://www.ovhcloud.com/en/public-cloud/ai-endpoints/ · model catalog: https://www.ovhcloud.com/en/public-cloud/ai-endpoints/catalog/. French company, runs in Gravelines, France. Pay per token: for your usage, roughly $ a month<, plus about €5 a month for the shared team interface>. OVH states data is not stored. Multi-tenant.
RunPod — https://runpod.io. US company, single-tenant GPU in a region you pick, every door locked with its own key, including an API URL Claude Code can use directly. $ per hour, about $ a month always on, billing whether anyone chats or not.
Neither is simply more private. OVH is EU-owned but shared; RunPod is single-tenant but US-owned, and the CLOUD Act follows the company, not the datacenter.
Every number real and read today: the two options differ by two orders of magnitude and the user cannot choose without seeing that. Wait for the pick, and do not relitigate it afterwards.
Three exits at this step:
- The model is not in the OVH catalog (DeepSeek, GLM class): say so in one line; the recommendation collapses to RunPod alone.
- Their words already picked: "pay per use" is Route A; a single-tenancy requirement is Route B. Skip the menu.
- The double requirement, EU ownership and single tenancy at once: neither option qualifies. Name Hetzner, Verda or Scaleway and stop rather than fudge.
4. The token
Guide them to the credential for the provider they picked, and only that one. Give the exact URL as a clickable link, never just the click path. Both verified 6 August 2026:
- OVH: https://www.ovh.com/manager/ (redirects to their regional manager) → Public Cloud → AI & Machine Learning → AI Endpoints → API keys. The keyless trial at 2 requests/min can prove the route before they create anything; raw curl only, since Open WebUI cannot use it.
ovh-endpoints.mdsection 3. - RunPod: https://console.runpod.io/user/settings → API Keys, needs read/write since it creates a pod.
deploy-steps.mdsection 1.
Never show the user shell commands or export lines. These are non-technical people. Say: "paste the key here and I will handle the rest." You hold the key from there and put it into each command that needs it yourself.
Same rules either way: never written to a file, never in the report. Echoing it is fine, and usually necessary: shell state does not persist between commands, so the key has to stay readable in order to be reused in the ones that follow. It therefore sits in the transcript, so if that transcript, a screenshot or a pasted log is ever shared, tell the user to rotate the key.
If the key is no longer in context, ask the user to paste it again. A long provisioning run can be summarised, and the key goes with it. One short re-ask costs a moment. Reconstructing it from memory costs a run: a wrong key fails every call, and 401s partway through a deploy read as a broken pod rather than a bad credential. Never continue on a guess.
Then continue with the picked route below.
Route A: the EU endpoint
The runbook is references/ovh-endpoints.md. The model and prices are already settled from steps 2 and 3; the token from step 4. Track progress:
Task Progress:
- [ ] A1. Cost and residency statement
- [ ] A2. Prove it with a real reply
- [ ] A3. Wire the interface
- [ ] A4. Render the report
A1. Cost and residency statement
Run the Route A gate in cost-gate.md section 0: today's per-token prices for the chosen model, one monthly anchor at their stated rhythm, and the idle line, zero solo or ~€5/mo with the team VPS. It is a statement, not a blocking confirmation, except the team shape, which confirms before the user orders the VPS.
A2. Prove it with a real reply
ovh-endpoints.md section 4. Set max_tokens generously; the gpt-oss models spend budget on reasoning before answering, and an empty reply with finish_reason: length is a budget problem, not an outage. Capture the real prompt and reply verbatim.
A3. Wire the interface
Solo: point the app the user already has at the endpoint, table in ovh-endpoints.md section 5. Team: one shared Open WebUI on a small OVH VPS, runbook in ovh-team-interface.md; the user creates the VPS in the Manager, you do everything after. The team shape needs the real API key, because Open WebUI cannot use the anonymous tier.
A4. Render the report
Build it from report-template.md, Route A layout. It carries the endpoint, the model with today's prices, the real prompt and reply, the wiring per app, the rate-limit table, and the Route A trust section from trust-boundary.md section 7. No teardown card solo; the team shape gets a real one for the VPS.
Route B: the private pod
What it builds:
┌─ RunPod Secure Cloud Pod, chosen region ──────────┐
│ vLLM 0.0.0.0:8000 exposed, Bearer key │
│ ↑ localhost │
│ Open WebUI 0.0.0.0:8080 exposed, own login │
│ Network volume, same region │
└──────────┬───────────────────────┬────────────────┘
HTTPS 8080, login HTTPS 8000, API key
people in a browser Claude Code and apps
Two doors, both locked. The chat sits behind Open WebUI's own login with signup off. The inference API sits behind a key generated on the pod, and that second door is the point: it gives the user a real URL that Claude Code and any OpenAI-dialect app can use directly, with a paste-and-run block in the report. Nothing on the pod answers an unauthenticated request, and the no-key probe proving that is a mandatory step, not a suggestion.
There is deliberately no serverless variant and no second host for the interface. One provider, one region, one volume, one teardown. Open WebUI is a FastAPI app that owns a disk at /app/backend/data, so it needs persistent storage and a process that stays up. It gets both from the pod, beside the model. If the user asks for it on Vercel, say in one sentence that Vercel functions are ephemeral and cannot hold that disk. If the user asks for pay-per-use, that is Route A, not RunPod Serverless; the ephemeral fleet and control-plane hop make Serverless's data flow paragraph unwriteable.
A pod bills from creation until teardown, whether or not anyone is chatting. Say that at the gate, because it is the single most common surprise.
The model, users and rhythm are settled from step 2; the key from step 4. If the user skipped straight to Route B without seeing the recommendation, state the jurisdiction once, as a statement, not a question:
RunPod is Runpod Inc., a US company. That is fine for saying where your data is processed, and they do that well: six EU regions, a signable DPA, SOC 2 Type 2. It cannot satisfy a requirement that names the CLOUD Act, SecNumCloud, BSI C5, or EU ownership, because no configuration changes who owns the company. If your requirement names one of those, Route A's processor is French, and for EU-owned single tenancy I will point you at Hetzner, Verda or Scaleway instead.
Track progress:
Task Progress:
- [ ] B1. Install the RunPod skills
- [ ] B2. Ask the two remaining questions: region and storage
- [ ] B3. Run the cost and residency gate, get a yes
- [ ] B4. Build the pod
- [ ] B5. Confirm the trust boundary
- [ ] B6. Prove it with a real reply
- [ ] B7. Render the handover report
B1. Install the RunPod skills
Do not reimplement RunPod's API. They ship official agent skills, better maintained than anything written here.
npx skills add runpod/runpod-plugins-official
That gives a router plus runpod-mcp, runpodctl, flash, companion-clis and runpod-usage, all authenticating on RUNPOD_API_KEY. Prefer runpod-mcp for plain infrastructure CRUD when its tools are connected, and runpodctl for the terminal, SSH setup and file transfer.
Install only what is missing, then confirm auth before provisioning: a key that fails at the build wastes a GPU that is already billing.
Verify subcommands with --help before running them, including the ones in this skill's references. The CLI moves.
B2. Ask the two remaining questions
One AskUserQuestion. Full option text in references/model-picker.md section 1. Model, users and rhythm came from step 2; only the pod-specific answers are left.
- Where should it run. Ask this. Never pick a region for the user. The right answer depends on a customer contract you cannot see. Say that pinning a region shrinks the available GPU pool, then confirm with
runpodctlthat the chosen model's GPU is actually rentable there today; if not, say so before the gate, not after. - How much history it holds. Sets the network volume, which must also fit the model weights.
When they pick the region, show the coverage line from trust-boundary.md section 5: SOC 2 Type 2, GDPR for EU regions, a signable DPA on Standard Contractual Clauses, an Article 27 EU representative, data subject rights, 72-hour breach notification, deletion on request. Every line is verified.
Show it here and once more in the gate. Nowhere else. Repeating caveats at every step trains the user to skip them, which is how the one that matters gets missed.
B3. Run the cost and residency gate, get a yes
Go to references/cost-gate.md and run it in full. It runs four residency refusals first, then computes the hourly rate, the monthly projection and the teardown commands, then stops.
It refuses a defaulted region, Community Cloud, and a volume in a different region than the pod. That last one slips through most often: the GPU holds a prompt for milliseconds, the volume holds every conversation forever.
State the honest contractual limit in the same message. RunPod's DPA commits to reasonable efforts to allocate a geographically proximate server. It does not guarantee residency. Read trust-boundary.md section 3 and do not soften it.
One consolidated gate, and it is before the first dollar.
B4. Build the pod
Follow references/deploy-steps.md section 2.
The critical flag is --api-key on vLLM. Port 8000 is public through the proxy, so a vLLM without a key is refusal 1 in the cost gate. Expose 8080 and 8000, nothing else, and never start vLLM on this pod without the key.
Three rules that decide whether the pod ever starts. All three were learned on billed GPUs and each one presents as a pod that hangs with no error:
- Validate every vLLM flag and the tool-call parser name against the vLLM source before creating the pod. The commands are in
troubleshooting.mdsection 0. An unknown argument makes vLLM exit during argparse, before it opens a port or writes anything reachable.--disable-log-requestsis the one that has already cost an hour: it no longer exists. - Do not override the container entrypoint. Pass vLLM's arguments with
--docker-argsand let the image start normally. Noapt-get, nopip install, no venv before the server is up. Install Open WebUI afterwards, on the running pod. - Verify CLI flag names with
--helpfirst. runpodctl 2.8.1 uses--image,--cloud-type,--data-center-ids,--gpu-id,--container-disk-in-gb,--docker-args. Older camelCase forms fail. There is no--volumePath; volumes mount at/workspace.
Judge readiness by the port code, never by runtime or SSH. 404 no route, 502 live pod with nothing listening, 401 serving with the key enforced, 200 serving. runtime: null and SSH container not found are both non-diagnostic on an inference image, and treating them as failure signals sends you chasing the wrong problem.
Print the teardown command as soon as each resource exists, before moving on.
Report a real checkpoint at least every 3 minutes while waiting. Silence during a paid wait is the thing users abandon runs over, and it is indistinguishable from a stuck run.
B5. Confirm the trust boundary
Do not skip this. Run the three probes in deploy-steps.md 2c-bis: with the key from inside the pod it answers, without the key from outside it returns 401, with the key from outside it returns 200.
If the no-key probe returns 200, the key is not enforced and the build is wrong; if it refuses to connect, the API door is missing and Claude Code cannot reach the pod. Fix either before writing the report. Never fill the data flow table without having run this.
B6. Prove it with a real reply
Three generations, because the report makes three different promises and each one must have happened:
- The chat door. A real prompt through Open WebUI's chain, with the reply shown.
- The Anthropic door. A real prompt to
/v1/messageson the public URL with the key. - Claude Code itself. Run the CLI against the pod with
env -iso the operator's own credentials cannot produce a false pass. The exact command is inreport-template.md, Route B card 4.
Do not report success on an HTTP 200, and do not report success on the model list endpoint alone: both can pass while generation fails. Capture every prompt and reply verbatim; never paraphrase or invent model output.
If anything fails, go to references/troubleshooting.md before improvising.
B7. Render the handover report
Deliver the result as a rendered HTML page, not chat text. Build it from references/report-template.md. It carries the chat URL, the real prompt and reply, the running cost, the teardown commands, the admin account instructions, and the Claude Code launch block with every value filled in. A user who wants this in Claude Code pastes that block from the page and is running; they never assemble it themselves.
Copy that block from deploy-steps.md section 3, never from memory. The pod is an LLM gateway in Claude Code's own terms and has a documented variable set (https://code.claude.com/docs/en/llm-gateway-connect); writing it from recall reintroduces ANTHROPIC_SMALL_FAST_MODEL, which is deprecated, and omits the alias and beta-suppression variables a one-model pod needs.
It also carries the ten-row data flow table and the reviewer paragraph from references/trust-boundary.md sections 4 and 6, with the user's real region in every cell. Row 9, control-plane metadata, stays "unconfirmed" until RunPod answers in writing. Never fill a cell with an assumption; "unconfirmed" is a legitimate value a reviewer respects, and an invented one destroys the document the first time it is checked.
Keep the chat summary to three lines and the file path. The page carries the detail.
Teardown
Treat /rented-server-setup teardown as a first class entry point. Follow references/teardown.md. On Route B it lists every billing resource in the order that stops the money soonest, and verifies each is gone rather than trusting the delete call. On Route A there is nothing that bills at idle; teardown is revoking the key.
Money keeps running until teardown on Route B. That makes it part of the skill, not an afterthought.
Human checkpoints
- At the fork: the user picks the route, with the cost anchors visible. Never pick for them unless their own words already did.
- Before provisioning anything on Route B (step B3): the cost and residency gate, with hourly and monthly figures. Wait for an explicit yes.
- Before deleting anything in teardown: list what will be destroyed and what data dies with it, then wait.
Never delete a RunPod resource the user did not ask you to remove, even if it looks orphaned.
Self-improvement
If a CLI flag or endpoint in references/ turns out to be wrong, fix the reference file in the same session and say you did. Both providers ship fast and these files will drift.