Self-Hosted vs Managed Volume Bots

The short answer

Choose managed if you do not already run production infrastructure and get woken up when it breaks. Choose self-hosted if you already operate hosts, secrets and monitoring, and you want a vendor out of the signing path. Self-hosting does not delete the cost of running a volume engine; it converts an invoice into your own hours, your own machines and your own on-call time.

Both routes are defensible and neither is the grown-up choice. The failure mode of a managed service is that you pay a margin and see less than you would like. The failure mode of self-hosting is a half-finished install nobody documented, running against a rate-limited endpoint, owned by one person who is unreachable.

What self-hosting actually removes

Four things genuinely go away. The recurring price disappears, or converts into a licence plus an endpoint bill. The vendor stops being a party to your custody arrangement, assuming the engine you run keeps keys locally. Their uptime stops being your uptime. And their reporting stops being the only account of what happened, because you hold the raw logs and can reconcile them against the chain yourself.

That last point is the one buyers underrate. On a managed console you see what the operator chose to display, which usually means completed orders and rarely every failed send with its error attached. When the engine runs on your own host, you can count retries, see which call timed out, and work out whether a quiet hour was the market or your configuration.

What self-hosting adds

An engine needs an RPC endpoint to see the chain and to send transactions. Public endpoints are rate limited and shared, which is fine for a wallet checking a balance and unsuitable for software that sends continuously, so a paid provider is usually required. Quote that recurring line at the request rate your run needs rather than at the cheapest advertised tier; the Solana documentation sets out what an endpoint serves.

Keys arrive next. On a managed console, key handling is a policy question you put to the vendor; self-hosted, it is a procedure you write and then have to keep. The keypair file sits on a host you secure, patch and back up, and every snapshot and archive of that host now contains a secret.

Upgrades follow, and after them the unglamorous half: monitoring, restart behaviour and log retention. When a venue changes its program your build stops working until you patch it, and much of that history is visible in public repositories such as the Solana Labs organisation on GitHub. A managed service hands you none of those jobs, and none of that visibility.

The skills the self-hosted route assumes

Most comparisons of this kind go straight to price and never state the assumption sitting underneath the self-hosted column, which is that somebody in your setup can do all of the following without looking it up. Read the list as a gate. If you cannot honestly tick most of it today, managed is not a compromise; it is where the arithmetic and the risk both point.

• You can bring up a host, keep it patched, and control who can log into it.
• You can run a process under supervision, and know what it does when it restarts mid-run.
• You can store a signing key outside any repository, chat, screenshot or cloud note, and have restored one from backup.
• You can tell a send failure from an on-chain failure, and read the error an endpoint returns.
• You can read a venue's change announcement and work out whether it affects your routing.
• You can write down what you did well enough that a colleague could run it without you.

Only one of those six is about trading. Self-hosting a volume engine is an infrastructure job with a trading application attached, and the gap tends to appear in the third month, once the interesting part is finished and the patching is not.

The total-cost frame

The comparison becomes tractable the moment you stop measuring a subscription against zero. A subscription is one visible number, while the self-hosted alternative is several invisible ones, and self-hosting looks cheaper on a first pass mainly because nobody wrote the invisible ones down. Write them down and the two columns become comparable, whichever way the result falls.

Total cost of ownership here means the recurring price, plus infrastructure, plus the hours valued at a rate you actually bill or pay, with setup amortised across the months you will genuinely operate. Amortisation is where most comparisons quietly cheat. Setup hours spread over two years look trivial, while the same hours spread over the two months you really run will dominate every other line in the sheet.

The cost lines side by side

Below is the sheet itself. Read it as a template to fill in rather than a verdict already reached: the middle columns describe how each line behaves under each model, and the last column tells you how to put a number on it. A line you cannot estimate is not worth nothing; mark it unknown and treat it as a reason for caution.

Filling in the managed column is the easier half of the exercise, because a console publishes its parameter list and its fee expression where you can read them: opening a volume bot for Solana and working through its settings gives you a figure for the first row in minutes, while the self-hosted rows still need estimates that only you can make. Do that side first, so the comparison contains one firm number instead of two soft ones.

A decision tree for the choice

Work through the following in order and stop at the first outcome you reach. There are three destinations, and the third is the honest answer for many readers who arrive convinced it will be the second. Nothing depends on the size of your budget, because capability and budget are unrelated, and confusing them is how half-built setups get funded.

1. Do you already run a production service you are responsible for when it breaks? If not, stop: managed now. A volume engine makes a poor first production service, because it fails in ways that cost money quietly.
2. Can you say where a signing key would live, who else could read it, and how you would restore it tonight? If any part is unclear, stop: managed now, and treat the answer as a gap to close.
3. Can you inspect what the engine does with a signing key? If it is a closed binary with no documented local key path, stop: managed now. Self-hosting it buys the operations job without the custody benefit.
4. Is this a recurring operation rather than one or two runs? If you expect a handful and then a pause, stop: managed now and self-hosted later. Setup hours cannot amortise across two runs.
5. Does your arithmetic put the self-hosted total below the managed price, with setup amortised honestly? If not, stop: managed now. A preference is not an argument against your own sheet.
6. Is there a second person who can act if you are unreachable mid-run? If not, stop: managed now and self-hosted later, and revisit once somebody else can read your runbook.
7. If you are still reading, the route is self-hosted. Write the runbook before the first live run, and treat that run as a test with a stop condition set down in advance.

The middle outcome deserves a defence of its own. Starting managed and moving later is not indecision; it is the only version of this choice in which you learn what your requirement actually is before building for it. The parameters you expect to need before a first run and the ones you keep after five are rarely the same set.

Lock-in exists in both directions

Managed lock-in is the familiar kind. Configuration lives in somebody else's console, history lives in their database, and your operating knowledge is knowledge of their interface rather than of the underlying problem. Worst of all, you often cannot reproduce a run anywhere else, because the parameters that produced it were expressed in their vocabulary and never in yours.

Self-hosted lock-in is discussed far less and is harder to escape. A build accumulates undocumented adjustments, a pinned set of dependencies nobody dares update, helper scripts written for one machine, and a procedure that lives in one person's head. A quieter version is dependence on a single endpoint provider: rely on convenience methods only one of them offers and you have swapped one vendor relationship for another.

A migration path if you change your mind

Assume you will change your mind at least once, in one direction or the other, and build so that changing it stays cheap. The path below moves from managed to self-hosted without opening a window in which neither route works. Run it in reverse if you are travelling the other way; the same discipline about records and keys applies.

1. Record the parameters you actually use. Wallet count, order sizing, spacing, venue selection and stop conditions, written down while the managed console still runs. That set is the requirement your build has to meet.
2. Keep your own record of the chain. Copy the transaction signatures from each run. A record you hold yourself survives an account closure, a pricing dispute, or a console going dark without notice.
3. Keep funds in wallets you control. Avoid leaving a working balance inside a vendor account between runs. Migrations turn difficult exactly when money has to move under time pressure.
4. Build the self-hosted path in parallel. Stand up the host, the endpoint and the engine while the managed route still works. The hours you log here are the real setup figure for your sheet.
5. Dry-run, then run small. Execute at the smallest size that still produces a readable result, and reconcile the output against the chain rather than against the engine's own summary.
6. Complete one unattended cycle before cutting over. Let the engine finish a run without you watching, then inspect what it did on failure and on restart. Cancel the subscription after that run, not before.

The adjacent choices this page does not settle

Hosting is one axis of three, and the other two are decided separately across the rest of this set of class-level comparisons. Treating all three as one decision produces the common error of assuming that self-hosted implies non-custodial, or that a managed console implies a subscription. Each of those pairings is common in practice, and none of them is a rule you can rely on without checking it.

Pricing structure is its own question, since the same engine can be sold as a flat subscription, a share of routed volume or a fee per transaction, and those are modelled in the comparison of volume bot pricing models. Budget is separate again, and the floor below which a run cannot produce a readable result is worked through in the breakdown of what budget a run needs. Interface choice sits alongside both, because a chat interface and a console differ in what you can audit, as set out in the comparison of Telegram bots and web consoles.

Frequently asked questions