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. Next, read generation vs registry.
Top comments (0)