Separate where the code runs from where the keys live
Self-hosted versus managed is really two questions: whose machine runs the process, and who holds the exchange API keys. A managed tool can still use keys you control and inject in a restricted way, while a self-hosted server can leak keys if operators share one login. Settle key custody first, then decide on hosting.
Alerts, backtests and dashboards rarely need trading permission
Alerts and backtests need market data only, and dashboards need at most read-only account access. Managed hosting is low risk here because a leaked key cannot place orders or withdraw. The concerns that matter are data source stability and log retention. If a tool asks for a trading-enabled key, first check whether it truly places orders instead of granting full permission by default.
Once order placement is involved, self-hosting draws clearer lines
With trading permission, the question becomes who can read the key and who can revoke it during an incident. On your own server, the key file, environment variables and access accounts sit under your control, and the developer needs deployment rights rather than plaintext keys. Managed hosting can work, but you need clear answers on whether the provider can reach the runtime, how keys are encrypted at rest and how they are destroyed. If those answers are vague, lean toward self-hosting.
Split operations by failure type, not by a blanket promise
An agreement should separate process crashes and restarts, dependency upgrades, adapting to exchange API changes, OS patching, disk and log cleanup, and alert handling. For each, state who responds, whether response time is committed and whether it costs extra. API change adaptation is the one most often missed: the exchange triggers it, it is not a defect in the tool, yet it can stop the tool completely.
IP allowlisting decides whether managed hosting is viable
Most exchanges let you bind an API key to an IP allowlist. A self-hosted server has a stable egress address that is easy to bind. Some managed environments rotate egress IPs or share them across customers, so the allowlist either cannot be set or is too broad. Confirm the egress IP is dedicated and stable, and that changes come with notice. If it cannot be fixed, do not combine it with trading permission.
Signals that mean you should stop and re-plan
Pause if anyone asks you to send plaintext keys in chat, cannot say where keys are stored or who can access them, logs print full keys or signature parameters, or the tool keeps trading after the key is revoked. Any one of these means the key boundary does not really exist. Fix it before going live. Available permission options and allowlist rules depend on the exchange's current console.