DeployStack – Open Source MCP Hosting for AI Workflows

TL;DR

TL;DR: DeployStack is an open source platform that turns any stdio-based MCP server into an HTTP endpoint by connecting to a GitHub repo. Deploy in 30 seconds, self-host with Docker.

Source and Accuracy Notes

⚠️ This section is MANDATORY. All links must be verified from actual source, not guessed.

• Project page: deploystack.io
• Source repository: github.com/deploystackio/deploystack
• License: AGPL-3.0 (verified via README badge)
• Documentation: docs.deploystack.io
• GitHub stars: 62 (verified via GitHub API)

What Is DeployStack?

Most MCP servers run over stdio — a local, process-bound communication channel that works fine for single-user desktop tools but breaks completely when you need to connect an MCP server to a workflow automation platform running on a server.

DeployStack bridges this gap. It hosts MCP servers as HTTP endpoints that any platform can reach over the network.

From the README:

Deploy MCP servers from GitHub to HTTP endpoints in 30 seconds. Works with n8n, Dify, Voiceflow, Langflow, Claude Code, Cursor, and any MCP client.

The Problem

The README frames it clearly: most workflow automation platforms need HTTP endpoints for MCP servers, but the standard MCP SDK uses stdio which cannot be used over a network.

| Platform | What it needs | The limitation | |---|---|---| | n8n | HTTP URLs for MCP Client node | stdio does not work | | Dify | HTTP/SSE endpoints (v1.6+) | No stdio support | | Voiceflow | Remote MCP endpoints | “Local MCP NOT supported” | | Langflow | HTTP/SSE for production | Local processes will not scale |

The workarounds each have real costs: mcp-remote needs local Node.js setup on every machine, Docker containers demand DevOps knowledge, and DIY hosting on Fly.io or Railway takes hours.

Who It Is For

DeployStack targets four audiences (verified from README):

1. AI Automation Builders — n8n, Dify, Voiceflow, and Langflow users who want HTTP endpoints for MCP servers without self-managing infrastructure.
2. Automation Agencies — Teams deploying MCP servers for multiple client projects with team isolation and credential management.
3. Platform / DevOps Teams — Organizations moving API keys from Slack DMs and .env files into a centralized credential vault.
4. Developers — Anyone who wants zero-setup MCP access: add one URL to your MCP client and get access to all team tools.

Setup Workflow

Option 1 — Deploy from GitHub

# There is no CLI install required
# The entire workflow is web-based:
# 1. Connect your GitHub account at cloud.deploystack.io
# 2. Select a repository containing an MCP server
# 3. Receive an HTTP endpoint that works immediately

Auto-deploys trigger on every git push. Branch deployments are supported for testing.

Option 2 — Curated MCP Catalog

Browse a catalog of pre-configured, tested servers and install with one click.

Option 3 — Self-Host

DeployStack is open source and can be run on your own infrastructure.

docker-compose up

Full self-hosting instructions are in the Self-Hosted Documentation.

Key Features

All verified from the README:

• Deploy from GitHub — point at any MCP server repo, get a working HTTP endpoint in 30 seconds
• Auto-deploy on push — new commits automatically redeploy the endpoint
• Curated catalog — pre-configured servers ready to use without setup
• Credential vault — encrypted storage for API keys, injected into MCP server requests
• Role-based access — control which team members can use which MCP servers and tools
• Team isolation — separate workspace per team or client
• Token optimization — hierarchical routing designed to reduce token overhead

The platform claims significant token reduction through context optimization. The exact percentage varies by workload, so treat that figure as directional rather than a guaranteed benchmark.

Practical Evaluation Checklist

• [ ] Does your workflow platform require HTTP endpoints? (n8n, Dify, Voiceflow, Langflow all do in their current versions)
• [ ] Is the MCP server you want to use stdio-only?
• [ ] Do you need team credential sharing without exposing keys to each developer?
• [ ] Do you want auto-deploy on git push?
• [ ] Are you comfortable with AGPL-3.0 licensing for self-hosted deployments?

Security Notes

• Credentials are stored in an encrypted vault and injected at runtime — not stored in environment files or Slack messages
• Role-based permissions govern which servers and tools each team member can access
• Audit logging tracks which tools accessed which data
• Team isolation keeps client workspaces separate

FAQ

Q: Does DeployStack work with any MCP server? A: Any MCP server that uses the standard stdio interface can be deployed. The server must be hosted in a GitHub repository to use the one-click deploy flow.

Q: What is the license for self-hosting? A: AGPL-3.0. The cloud service is a separate commercial offering.

Q: How does the credential vault work? A: API keys and secrets are stored encrypted in DeployStack’s vault. When an MCP server makes a request that needs credentials, the vault injects them at runtime — they never appear in environment files or chat logs.

Q: Does this require a credit card? A: The open source self-hosted version has no cost. The cloud service at cloud.deploystack.io has its own pricing.

Conclusion

DeployStack solves the MCP hosting problem for anyone running workflow automation platforms that cannot use stdio-based tools. Connect a GitHub repo, get a URL, done. The open source AGPL-3.0 license means you can self-host it without vendor lock-in, and the credential vault addresses the real-world problem of credential sprawl across teams.

If you are running n8n, Dify, Voiceflow, or Langflow and want to connect an MCP server that only speaks stdio, DeployStack is purpose-built for that gap.

Source: github.com/deploystackio/deploystack — 62 stars, AGPL-3.0, TypeScript/Node.js + Vue.js stack.