# Self-Hosted MCP vs a Smithery Gateway

**Short answer:** A gateway handles credentials, OAuth, and sessions for you and sits in the call path; a self-hosted server runs on your own infrastructure with no intermediary. Use a gateway when you want managed auth and discovery; self-host when you control the service and want no third party in the path.

## What a gateway takes off your plate

Managed OAuth, token storage, session handling, and a connection UI are real work, and a gateway does them once for many services. That is the strongest reason to use one for third-party integrations.

## What self-hosting keeps

| Property | Gateway | Self-hosted |
| --- | --- | --- |
| OAuth / credentials | Managed | Your responsibility |
| Call path | Through the gateway | Direct to your server |
| Data exposure | To the gateway | Only your systems |
| Cost model | Per call / tier | Your infrastructure |

## When self-hosting is the clear choice

If the service is yours, the contract is in your repo, and you already run the backend, adding a generated server is a small step and keeps every call inside your own systems. There is no third party to trust and no per-call meter.

## When a gateway wins

Connecting to many third-party services that each need OAuth is where a gateway is worth it. Rebuilding that yourself is a project, not a setup.

This is part of the [Powerduck vs Smithery comparison](https://www.powerduck.com/blog/powerduck-vs-smithery/). Next, read [generation vs registry](https://www.powerduck.com/blog/generate-mcp-from-openapi-vs-registry/).