agentsclimarketplace

Vps mcp hub skill

Skill Teguhcanggu/vps-mcp-hub-skill

VPS MCP Hub by Jiwa Karya Bali: self-host remote MCP servers for Claude Chat, ChatGPT, and API clients

Install
npx -y skills add Teguhcanggu/vps-mcp-hub-skill

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Plan, deploy, verify, and connect self-hosted remote MCP servers on a VPS-backed hub for Claude Chat, ChatGPT, and API clients. Use this skill when a user wants an end-to-end VPS MCP hub workflow: classify an MCP server, prepare source code, containerize it, handle secrets safely, deploy it as an isolated sidecar or register an npm/STDIO server, expose it through a remote MCP hub, verify tools/list and smoke calls, connect clients, and document rollback/monitoring. Created by Jiwa Karya Bali as a public, reusable production deployment pattern.

SKILL.md

6.9 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

VPS MCP Hub

End-to-end skill for deploying remote MCP servers to a self-hosted VPS hub and connecting them to AI clients such as Claude Chat, ChatGPT, and API integrations that support remote MCP.

This skill is intentionally public-safe. It uses placeholders for domains, hosts, usernames, namespaces, secrets, and paths. Never paste private values into chat, repository files, examples, or commit history.

When To Use

Use this skill when the user says things like:

  • "deploy this MCP to my VPS"
  • "make this MCP available in Claude Chat"
  • "connect this MCP hub to ChatGPT"
  • "host a remote MCP server"
  • "build a VPS MCP hub"
  • "convert my local MCP to a remote MCP connector"

Public Architecture

Recommended baseline:

  • VPS running Linux
  • HTTPS reverse proxy such as Caddy, Traefik, or Nginx
  • Remote MCP hub or gateway such as MetaMCP, a custom FastMCP gateway, or another MCP-compatible aggregator
  • Docker Compose for sidecar services
  • Secret files or a password manager backed deployment flow
  • OAuth or bearer auth for public internet clients
  • Clients: Claude custom connectors, ChatGPT remote MCP connectors/developer mode, and API clients

Use exact product documentation for the target client before claiming support. Availability and setup steps may differ by plan, workspace, beta status, and current platform rules.

Lifecycle

Run the phases in order. Each phase has a gate. Do not skip gates unless the MCP is explicitly trivial and read-only.

Phase 1 - Pre-flight and MCP Type

Decide:

  • MCP source: public npm package, custom Python/FastMCP repo, custom Node.js/TypeScript repo, or upstream fork
  • Runtime type: STDIO registered in the hub, or Streamable HTTP sidecar
  • Risk class: read-only, private read, draft/generate, write, publish/deploy, or destructive/payment
  • Secret needs: env var names only, never values
  • Pinned version: npm version, git commit, image digest, or immutable image tag
  • VPS headroom: RAM, disk, reverse proxy, hub health, existing production boundaries

Gate:

  • Hub health is good
  • Public endpoint has HTTPS
  • Required secrets are identified by name only
  • Risk class is accepted by the user
  • Version is pinned

Details: references/01-precheck.md

Phase 2 - Source Prep

For custom MCP servers, prepare a remote transport:

  • serve_http.py or equivalent Streamable HTTP entrypoint
  • Dockerfile with non-root runtime user
  • .dockerignore
  • GitHub Actions or another CI build that pushes an immutable image tag

For public npm MCP servers that can be safely launched by the hub as STDIO, skip this phase.

Gate:

  • The MCP can run locally
  • The HTTP endpoint responds on the chosen path
  • The container builds
  • The image has a pinned tag

Details: references/02-source-prep.md

Phase 3 - Secret Loading

Secrets must be handled outside chat and outside git.

Allowed approaches:

  • Interactive SSH paste directly into a root-readable secret file
  • Password manager CLI in an authenticated shell
  • CI/CD secret store
  • Encrypted deployment mechanism already approved by the owner

Gate:

  • Secret files exist with restrictive permissions
  • No secret values are printed to chat or logs
  • .env files are ignored by git
  • Only secret references or env var names appear in documentation

Details: references/03-secret-loading.md

Phase 4 - Deploy and Register

Deploy one of two patterns:

  • Streamable HTTP sidecar for custom MCP servers
  • STDIO registration for pinned public packages

Hard constraints for sidecars:

  • Use an immutable image tag or digest
  • Join only the internal hub network
  • Do not expose host ports unless required by your design
  • Disable reverse proxy discovery for private sidecars
  • Keep secrets in env_file or secret manager references

Gate:

  • Container is running and healthy
  • Hub can reach the internal MCP URL
  • MCP is registered in the hub
  • MCP is attached to the intended namespace or endpoint

Details: references/04-deploy-register.md

Phase 5 - Verify

Run server-side verification before connecting user-facing clients:

  • Initialize MCP session
  • Run tools/list
  • Confirm expected tool names
  • Run one read-only smoke call
  • Revoke temporary keys used for tests
  • Redact any private output

Gate:

  • tools/list includes the new MCP tools
  • Smoke test succeeds
  • Temporary credentials are revoked
  • Logs do not expose secrets or sensitive user data

Details: references/05-verify-connect.md

Phase 6 - Connect Clients

Connect the remote MCP endpoint to supported clients:

  • Claude Chat custom connector
  • ChatGPT remote MCP connector or developer mode, where available
  • API client with remote MCP tool support

Gate:

  • Connector is enabled
  • User grants the correct permissions
  • One real chat test succeeds
  • Write or destructive tools require explicit user approval

Details: references/05-verify-connect.md

Phase 7 - Document and Version

Record the deployment in a private operations repo, not in the public skill repo:

  • MCP name
  • source repo/package
  • pinned version
  • risk class
  • tool allowlist
  • secret reference names only
  • rollback plan

Gate:

  • Git diff contains no secret values
  • Deployment notes are reproducible
  • Public repo contains only generic guidance

Details: references/06-rollback-monitor.md

Phase 8 - Rollback and Monitoring

Prepare rollback before calling the deployment done:

  • detach MCP from namespace/endpoint
  • stop sidecar container
  • delete hub registration
  • rotate or revoke provider keys if needed
  • monitor restarts, tool count, auth failures, and error logs

Gate:

  • Rollback commands are known
  • Monitoring exists
  • The next deployment waits if the current one is unstable

Details: references/06-rollback-monitor.md

Safety Rules

  • Never commit .env, credentials, cookies, tokens, key files, or secret-store values
  • Never use latest for production deployment
  • Never expose a sidecar publicly unless it has explicit auth and rate limits
  • Never register destructive tools without user approval and safety policy
  • Never paste secrets into chat
  • Never print secret values for verification
  • Never publish private domains, internal hostnames, private emails, UUIDs, or local filesystem paths
  • Always test with a temporary credential and revoke it

Public Branding Note

This skill is created by Jiwa Karya Bali as a reusable public deployment pattern for builders who want practical, self-hosted MCP infrastructure. Keep examples generic so the repo can be shared safely.

What ships with it: 18 files

35.9 KB alongside SKILL.md, 1 of them executable

assets/

examples/

references/

scripts/

Gives 1 of the 12 instructions most ship operate skills give in ~1.4k tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymenthere, and in 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • Run deployment phases in sequential order
  • Identify MCP runtime type before deployment
  • Get user acceptance for risk class
  • Pin all versions to an immutable tag
  • Keep secrets outside chat and git
  • Run tools/list and a read-only smoke call

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.