Your CrewAI crew runs great on your laptop. The agents talk to each other, the researcher hands off to the writer, the whole thing hums — right up until you close the lid and it all stops. Or your wifi drops mid-task. Or you reboot and forget to restart it.
A crew that only runs while you're watching isn't automation. It's a demo. Moving it to a VPS is what turns it into something that actually works while you sleep.
Why a server, not your machine
The pitch is simple: a VPS is a computer that never closes its lid. It has a fixed IP, it doesn't sleep, and if the process dies it can bring itself back. For a multi-agent crew — which by design runs long, chatty, multi-step jobs — that's the difference between "it worked once" and "it's been running for three weeks."
There's a second reason that trips people up in a good way: you don't need a powerful machine. More on that next, because it's the question everyone asks first.
No, you don't need a GPU
This is the part people get wrong about hosting agents. CrewAI is an orchestrator. It decides which agent acts, in what order, with what context — and then it asks a language model to do the actual reasoning. That model almost always lives behind an API: you send a request to OpenAI or Anthropic, they run it on their GPUs, you get text back.
So your server does three things: run Python, hold the crew's state, and make HTTPS calls. None of that touches a GPU. A plain CPU VPS is exactly right. The only time that changes is if you also want to run the model locally — but that's a separate, heavier project, and most crews don't.
Practically: a 1–2 GB plan runs a small crew without breaking a sweat. Go to 4 GB if you're running several crews at once, holding big conversation histories in RAM, or bolting on a vector database for long-term agent memory.
The actual setup
Fresh Ubuntu box, root in about a minute after ordering. Here's the whole thing:
Python + venv
apt update && apt install -y python3-venv python3-pip
python3 -m venv ~/crew && source ~/crew/bin/activate
CrewAI
pip install crewai crewai-tools
your project
mkdir ~/mycrew && cd ~/mycrew
copy your crew.py and .env up here (scp / git clone)
Your .env holds the one secret that matters — the LLM API key:
OPENAI_API_KEY=sk-...
or ANTHROPIC_API_KEY, etc.
Then a normal python crew.py runs it. That's the manual version. It works, but it dies the moment your SSH session closes — which brings us to the actual point of a server.
Keep it alive with systemd
tmux is fine for a quick test. For anything real, use systemd — it restarts the crew if it crashes and brings it up on reboot. Drop this in /etc/systemd/system/mycrew.service:
[Unit]
Description=CrewAI crew
After=network-online.target
[Service]
WorkingDirectory=/root/mycrew
ExecStart=/root/crew/bin/python /root/mycrew/crew.py
Restart=always
RestartSec=5
EnvironmentFile=/root/mycrew/.env
[Install]
WantedBy=multi-user.target
systemctl daemon-reload
systemctl enable --now mycrew
journalctl -u mycrew -f # watch it work
Now the crew runs on boot, restarts on failure, and logs everywhere you can read them. Close your laptop — it doesn't care.
Paying for it
Signup is an email and a one-time code — no card, no ID. You fund a balance with USDC or USDT on Base, Ethereum or Polygon (Base is cheapest on fees), and orders draw from it. For a crew that mostly makes outbound API calls, the default NAT plan is fine and cheaper; pick a -ip plan only if the crew needs its own public IPv4 for inbound services.
One nice trick: EQVPS has an MCP server at mcp.eqvps.com/mcp. If provisioning is itself one of your crew's jobs, an agent with a funded balance can call order_vps and stand up a box on its own — no human at the checkout.
What's honest to say
You bring the LLM API keys. We host the crew, not the model. Your OpenAI/Anthropic bill is separate and, for a busy crew, usually the larger cost — the VPS is the cheap part.
It's CPU-only, one datacent``er in Germany. No local GPU inference, and latency is best if your users or APIs are Europe-adjacent. For a crew hitting US-hosted LLM APIs the extra hop is milliseconds — irrelevant next to model latency — but worth knowing.
Size for your memory, not your model. The thing that actually grows your RAM use is conversation history and any vector store you add, not the number of agents. Watch journalctl and htop for a day and resize if you need to.
The takeaway
A CrewAI crew belongs on something that doesn't sleep. The move is short: a CPU VPS, pip install crewai, a systemd unit, your API key in a .env. Ten minutes and your crew is running 24/7 instead of "whenever the laptop's open." Root in about a minute, pay in crypto, resize when the memory tells you to — and let the agents get on with it.
Top comments (2)
Great questions — both come down to the same thing: it's a memory and I/O story, not a compute one.
On concurrency: CrewAI's default sequential process runs one agent at a time, so a single crew is mostly I/O-bound — it spends its life waiting on the LLM API, not burning CPU. Where it gets interesting is running multiple crews in parallel, or CrewAI's hierarchical/async paths. Since each agent call is a blocking HTTPS request, concurrency scales with how many you can hold in flight, and the real ceiling is RAM per worker + your LLM provider's rate limits — not VPS cores. On a 2 GB box I've comfortably had several small crews running side by side; the CPU sits near-idle while everything waits on tokens.
On conversation history: this is the one that actually grows your footprint. CrewAI keeps context in memory during a run, so a long multi-step job with agents passing large outputs back and forth is what eats RAM — not the agent count. Two practical levers: (1) trim/summarize context between steps so histories don't grow unbounded, and (2) if you add a vector store for long-term memory (Chroma, Qdrant), that's a separate RAM/disk line — budget for it. That's exactly why the article says "size for your memory, not your model": a 5-agent crew with short handoffs is lighter than a 2-agent crew shuffling 50k-token contexts.
Rule of thumb from watching real crews: start at 2 GB, run journalctl + htop for a day under your actual workload, and let the memory curve tell you when to resize. The nice part with crypto-funded hosting is resizing is just a balance top-up — no re-quoting, no card.
Curious what your crews look like — heavy RAG pipelines, or more tool-calling orchestration? The memory profile differs a lot between the two.
I appreciate the clarification on not needing a GPU for running CrewAI, as it's an orchestrator that relies on external APIs for the actual reasoning. The fact that a plain CPU VPS can handle the tasks of running Python, holding the crew's state, and making HTTPS calls is a significant simplification. I've had similar experiences with other API-driven projects, where the focus is on managing the workflow rather than performing computationally intensive tasks. The suggestion to use a 1-2 GB plan for a small crew and scaling up to 4 GB for more demanding scenarios seems reasonable, and I'm curious to know more about the performance characteristics of CrewAI on a VPS, such as how it handles concurrent agent interactions and large conversation histories.