Compute settings
Everything you deploy here — an agent, a function, a serverless service or an MCP server — is sized and scaled the same way, with the same four settings and the same defaults.
You can leave every one of them alone. The defaults are chosen to work.
| Setting | What it decides | Default |
|---|---|---|
| Instance size | CPU and memory for each instance | medium |
| Minimum instances | How many stay warm when nothing is happening | 0 — except MCP servers, which default to 1 |
| Maximum instances | How far it can scale under load | 10 |
| Concurrent requests per instance | How many requests one instance handles at once | 80 |
| Request timeout | How long one request may run | 60 seconds |
Where to find them:
- Console — open the workload, then Compute settings
- CLI —
platformctl agents config <name>(functions use the same command) - API —
PATCH /v1/agents/{name}/config, orPATCH /v1/projects/{id}/mcpservers/{name}/config
Changes take effect on a new revision. The instance already running keeps its old settings until the new one is ready, so nothing is interrupted mid-request.
Instance size
One value instead of four. Each size sets CPU and memory together:
| Size | CPU | Memory |
|---|---|---|
small | 0.5 | 512Mi |
medium | 1 | 1Gi |
large | 2 | 2Gi |
xlarge | 4 | 4Gi |
Memory is guaranteed. Each instance is reserved exactly the memory its size names, so it is never killed for using the memory it was given. Ask for more than you need and you pay for it; ask for less than your workload uses and it will be stopped when it exceeds the limit.
CPU is shared. Your instance can burst above its share when the machine is quiet, and is throttled — never killed — when it is busy.
:::tip Picking a size
Start at medium. Move up if you see out-of-memory restarts in your logs; move down if you are paying for memory that graphs flat.
:::
Custom CPU and memory
If you have a specific requirement, choose Custom and set the quantities yourself: 500m is half a CPU, 2 is two CPUs, and memory is written as 512Mi or 2Gi.
A custom choice sets memory the same way a named size does — request equals limit — so it is never quietly less safe than a named one.
Scaling
Minimum instances
0 means your workload uses nothing while idle. The first request after a quiet period waits for it to start; everything after that is fast.
Set 1 or more to keep instances warm. You pay for them continuously and no request waits for a cold start.
Maximum instances
The ceiling. This is your protection against a traffic spike or a runaway loop consuming the whole project quota.
Unlimited means unlimited. It is offered, and it will do exactly what it says.
Concurrent requests per instance
How many requests one instance handles at the same time before the platform starts another.
- Lower it to
1if your code keeps per-request state that is not safe to share. - Leave it at
80otherwise.
Request timeout
How long a single request may run before the platform gives up on it.
The default is 60 seconds. You can raise it as far as 15 minutes.
:::caution A longer timeout is not free
The request budget also bounds how long a credential fetched with crusoe.secret() stays valid. Raising the timeout lengthens the window in which that credential can be used.
Raise it because your work genuinely takes that long, not as a precaution. :::
If your work takes longer than 15 minutes, a single synchronous request is the wrong shape for it. Split it: have the request start the work and return, and collect the result separately — a Pub/Sub topic or a trigger is usually the right seam.
Streaming is different
POST /v1/agents/{name}/invoke/stream is not bound by the request timeout in the same way — the stream lives as long as your connection does. The timeout applies to the buffered invoke.
MCP servers default to one instance
Every other workload defaults to scaling to zero. MCP servers default to one warm instance, and this is deliberate.
An MCP server is a thing other people call. A tool client running on someone's laptop, in another cloud, or inside a third-party agent runtime opens a connection and expects an answer. It has no way to wake a sleeping server.
You can set it to zero. Agents on this platform will still reach it — they wake it before connecting, and the first tool call after idle waits for it to start.
:::caution Before you choose zero Anything calling your MCP server from outside this platform will get a connection failure while the server is asleep, with no way to wake it.
Keep minimum instances at 1 if anything off-platform consumes this server.
:::
Seeing what is set
The console shows the resolved settings on each workload's page. platformctl agents config <name> prints the same thing.
A setting you have never touched shows as platform default rather than a number, so you can tell the difference between "I chose this" and "this is what everyone gets". That matters: a default you have not pinned follows the platform when it changes, and a value you set does not.