A crypto trading bot can run on either a VPS or a managed cloud worker. A self-managed VPS gives you control of the operating system and leaves patching, process supervision and recovery with you. A managed worker transfers some infrastructure work to the provider, while you still own trading logic, credentials, order records and restart decisions. Choose the model whose responsibilities you can verify with a recovery drill.
Start with the workload and the operating contract
A virtual private server is a rented virtual computer. Here, “managed cloud” means a service that runs your application as a container or background worker while managing more of the underlying infrastructure. A VPS can also be hosted in a cloud. The meaningful comparison is the work each arrangement leaves with you. A managed VPS contract may divide those duties differently.
For a custom bot, establish whether the service supports a continuously running worker, outbound exchange connections, the required runtime and persistent state. Read its rules for restarts, deployments, inactivity, resource limits and maintenance. A web request handler with a time limit is a different execution model from a long-running worker.
If you use an already hosted trading application, first establish whether it requires you to operate any component. Renting a VPS adds no value merely because you access the application from a laptop.
AWS provides a concrete responsibility boundary. For an EC2 instance, the customer manages the guest operating system, security patches, installed software and security-group configuration. This is an infrastructure example, rather than a claim that all VPS contracts are identical. AWS shared responsibility model.
For ECS on Fargate, AWS provisions and patches the compute infrastructure. The customer still manages container images, application IAM permissions, network configuration and storage encryption. That reduces a specific operating burden; it leaves application decisions with the operator. Amazon ECS responsibility model.
| Operating duty | Self-managed VPS | Managed container or worker |
|---|---|---|
| Host and guest operating system | Provider handles its infrastructure; you maintain the guest OS | Provider scope must explicitly cover the execution infrastructure |
| Bot code and dependencies | You build, patch and deploy them | You still maintain the application or image |
| Process replacement | You configure supervision and a replacement procedure | Verify service scheduling, restart policy and maintenance behavior |
| Order journal and backups | You choose storage, retention and restore procedures | You still choose durable storage and verify restore behavior |
| Exchange credentials | You control access, permissions and rotation | You still control these; a secret store is one component |
| Outbound exchange route | You establish and verify the source addresses | Verify routes during deployment, scaling and failover |
| Trading readiness | Your application and operating policy decide | Your application and operating policy still decide |
Replace every “you” with a named person or team. A support plan is useful only when its scope covers the task you expect it to perform.
Separate the process, host, storage and exchange failures
Draw the path from strategy process to durable journal, outbound gateway and exchange. Add the monitoring system and the person who receives its alerts. Each component can fail separately.
A supervisor restarting a crashed process on the same VPS tests process recovery. Rebuilding after the VPS disappears tests host recovery. Neither proves that the bot survives losing its database, cloud region or exchange access. Two workers sharing one database and outbound gateway still share those failure points.
List what each failure should do to new entries, existing orders and position protection. A replacement host cannot repair an exchange interruption. Use the exchange maintenance restart guide when the unavailable component is the venue itself.
Keep monitoring sufficiently separate that the failure being detected does not also silence the only alert. The bot health-check and heartbeat guide develops that monitoring boundary. A process being alive is only one observation; it does not establish fresh data or a reconciled account.
Decide what must survive a replacement
Divide state into three practical groups:
- Rebuildable artifacts: application image, dependency versions and ordinary configuration.
- Durable execution records: intended orders, client order IDs, submission attempts, confirmed fills, strategy state and pause decisions.
- Sensitive authority: exchange secrets, infrastructure access and the mechanism that permits a worker to submit orders.
Store the execution records where the chosen failure does not erase them. For a host-loss drill, a journal on that host alone fails the requirement. An external database can separate that boundary, but its own availability, access controls and recovery plan still need an owner.
Temporary container storage is a particular trap. AWS states that Fargate's ephemeral storage is erased when the workload stops and documents EFS as a persistent-storage option. This is documented Fargate behavior; another managed service needs its own storage contract checked. AWS Fargate storage FAQ.
Persist an intent and its identifier before submission, then record confirmed venue outcomes. That does not turn a database write and exchange request into one atomic action. A crash between submission and confirmation still leaves an unresolved order.
Binance Spot documents that a -1007 timeout can leave execution status unknown and advises querying the request's status if it has not appeared in the User Data Stream. A restarted worker must recover that uncertainty. Starting with an empty local order list and repeating the trade can create additional exposure. Binance Spot REST API information.
On-chain workers have a related continuity requirement: preserve transaction identity and account sequencing across restarts. The EVM transaction nonce guide covers that chain-specific state. A replacement machine does not reset an account's transaction history.
Make one worker authoritative during handover
Automatic replacement can introduce overlap. AWS documents that, during Fargate service-task retirement under the described default configuration, ECS starts a replacement before retiring the old task. Standalone tasks have different replacement behavior. Verify the exact scheduler and deployment settings you use. Fargate task retirement documentation.
For a bot that should have one order-submitting worker, two running copies must not become two independent decision makers. Define how ownership transfers, where it is checked and what happens when the old worker loses access to the coordination system.
A lock file on one machine cannot coordinate a second machine. A time-limited lease also needs enforcement: an isolated old worker must stop submitting when its authority expires. An execution gateway can reject obsolete owners, or a simpler operation can use an explicit stop-and-verify handover. The appropriate design depends on the application.
Record how the handover proves the previous worker can no longer act. Setting a desired replica count of one alone does not demonstrate that property. If exclusive submission authority cannot be established, the replacement should remain blocked from opening new trades.
Treat secrets and outbound addresses as recovery inputs
Keep exchange secrets out of code repositories, machine images and incident worksheets. Record a credential label, owner and version without copying its value. Test whether the replacement can obtain the intended credential with the intended permissions.
A secret-manager update may not update an already running process. For ECS secrets injected through environment variables, AWS documents injection at container start; rotation requires a new task or deployment to receive the updated value. It also warns that container applications, logs and debugging tools can access those environment variables. ECS secrets injection documentation.
Plan a rotation as an operating change: block fresh submissions as required, reconcile outstanding work, update the credential, confirm the new worker's access and retire the old authority. The venue's credential lifecycle and the service's deployment lifecycle are separate procedures.
For restricted exchange keys, verify the outbound address used by a replacement. A new worker being reachable from your browser does not identify its exchange-request source address. The exchange API IP allowlist guide provides the route worksheet. Preserve the required restriction while resolving a mismatch.
Worked recovery drill: a running worker is only one milestone
Consider a hypothetical custom spot bot with an illustrative recovery-time objective of 120 seconds after host loss. This is a teaching scenario, not a measured hosting result or a recommended universal target.
Its latest VM snapshot is from 11:55:00 UTC. A separate durable journal records intent B-417 at 11:59:50. The worker sends it at 11:59:52; the exchange accepts it, but confirmation is lost. The host fails at 12:00:00. Assume the journal, exchange and replacement infrastructure remain available throughout the drill. The recovery procedure establishes exclusive submission authority before reconciliation, and final validation checks that it remains current.
| UTC time | Recovery milestone | Evidence required before advancing |
|---|---|---|
| 12:00:30 | Independent monitoring detects the failure | Alert received; new worker starts with entries blocked |
| 12:01:15 | Replacement runtime starts | Correct code, configuration, journal access and credential version |
| 12:01:35 | Account reconciliation completes | B-417 and relevant fills, open orders and balances recovered |
| 12:01:50 | Fresh-entry gate can reopen | Exclusive authority, fresh data and current risk checks pass |
Detection takes 30 seconds, replacement 45, reconciliation 20 and final validation 15. Total recovery is 30 + 45 + 20 + 15 = 110 seconds, or 1 minute 50 seconds. The worker runs after 75 seconds, but another 35 seconds are needed before fresh entries become eligible. The drill leaves 10 seconds against the illustrative target.
The snapshot is five minutes older than the host failure. Restoring it alone cannot recover changes made after 11:55:00. The separate journal preserves the order identifier needed for reconciliation in this scenario. Recovery must find the accepted order, rather than infer that restoring old files undid the trade.
Recovery time and recoverable data are separate objectives. AWS's methodology distinguishes RTO, the acceptable restoration delay, from RPO, the acceptable age of the last recovery point. These are targets selected for the workload. A single drill does not establish uptime or recovery from losing the journal as well. AWS recovery objectives.
Use the drill evidence to choose a hosting model
Complete this worksheet for each candidate arrangement before choosing it:
| Decision | Record | Acceptance evidence |
|---|---|---|
| Runtime fit | Continuous-worker support, resources and connection limits | Paper workload runs through a deployment and restart |
| Operating owner | OS, dependency and image maintenance responsibilities | Named owner and a documented update procedure |
| Durable state | Journal location, backups and retained configuration | Restore from outside the failed host |
| Handover | Submission ownership and stale-worker behavior | Previous worker cannot continue submitting |
| Access recovery | Credential version and approved outbound route | Supported authenticated checks from the replacement |
| Recovery policy | Time objective, data objective and resume conditions | Timed drill with discrepancies resolved |
A VPS can fit an application needing operating-system control when someone can maintain it and rehearse replacement. A managed worker can fit a packaged application when its runtime, storage and deployment behavior meet the requirements. Compare the actual operating contracts and evidence, including the work needed to maintain each arrangement.
Before enabling live entries, make one replacement drill repeatable. Save its timeline, recovered order identities, ownership transfer and remaining limitations. The decisive result is a replacement that stays blocked until execution records, exchange state and current submission authority agree.