You passed at least one of the previous page's three tests, so it is time for a machine. Here is how to size it — with no provider comparison, for the reason in §5.
In this pagethree selection criteria, what to prepare first. No provider rankings, and nothing about which one I use or where.
The easiest thing to get wrong. Steady usage looks like a few hundred megabytes, so you buy the smallest tier — and then get killed by the memory limit during one compile, one dependency install, one large file.
| Memory spikes | Why they get forgotten |
|---|---|
| Installing dependencies / compiling | Only happens at deploy — but when it happens it is the peak |
| Agent handling long context | A large file costs memory, not only tokens |
| Two jobs at once | Overlapping schedules (page 11, trap one) double it outright |
| System updates | Rare, but competes with your service when it happens |
There is no error. The process is simply gone. The logs usually say nothing — because whatever was writing them died too. You see "the service vanished for no reason" and spend a long time hunting for a bug that is not in your code.
So: go one tier up. On memory, the money saved never covers the debugging time.
| Consideration | How to think |
|---|---|
| Latency to the model endpoint | The important one — every agent turn is a round trip; latency times turns is your waiting |
| Latency to services it uses | If it mostly talks to one API, sit near that API |
| Latency to you | Almost irrelevant — you only SSH in occasionally |
| Availability and compliance | Some services are not offered in some regions. Check first, or the box is useless |
The classic mistake is "pick the one nearest me". But between you and that box there is a trickle of SSH, while between it and the model endpoint there is traffic on every single turn. Wrong thing optimised.
| Leave room for | Note |
|---|---|
| Logs | Configure rotation or they fill the disk eventually. Day-one job |
| Container images | With Docker, old images pile up |
| Sessions and memory | An always-on agent's history only grows |
Because everything breaks at once: services cannot log, databases cannot write, and you may not be able to run commands after SSHing in. And the cause has nothing to do with whatever you were actually doing.
Prevention is cheap (set up log rotation). Recovery is not. Do it on day one.
| Prepare | Why in advance |
|---|---|
| An SSH key pair | Choose key login at creation — far easier than retrofitting |
| Clarity on what it will run | Determines sizing, and also page 22's question: should it touch secrets at all |
| A rebuild note | Even a few lines. You will rebuild eventually, and you will be grateful |
This step means signing up with a provider. This site does not run provider comparisons — I use one of them myself, and no ranking produced from that position comes out clean. Hence criteria above rather than a shortlist.
Saying it in full: if you are going to open one, you can go through my referral link: 👉 sign up for Vultr. I have not checked the terms of that referral programme — how much it pays, whether the referred side gets anything, whether there are thresholds — so this page promises nothing about it; read their own page. Going through it is a small encouragement for these pages, and keeps me writing the rest of them. Not using it is entirely fine — any other provider works just as well. Every step from the first hour to running it as a service is identical on any VPS; nothing in this thread depends on a particular vendor's features.
Practical notePut your SSH public key in at creation rather than opening with a password and fixing it later — a public box is being scanned from minute one, so keep the password window as short as possible.
This site has a fixed rule: claim no neutrality and you owe no disclosure; the moment a page is about the economics of a business you are in, you must disclose.
A head-to-head is the archetypal neutrality claim. Since I use one of these providers, no ranking lands clean — so there is no ranking. You get the criteria and do your own. Same rule as the relay page.