Northflank vs Thunder Compute

Northflank

OpenAPI 3.0 with over 100 paths, enums and per_page, page and cursor on every list. No scale to zero for services; minimum instances must be at least 1.

Thunder Compute

The hosted MCP server signs in with OAuth and separate read and write scopes, and the REST API has a public OpenAPI 3.1 document with keyless price and availability endpoints. No rate limits, SLA or API changelog were found, instance creation has no idempotency key, and instances cannot be stopped, only deleted.

Northflank

1. Issue the agent a team token under an API role limited to one project, not a personal token
2. Read x-ratelimit-remaining and wait x-ratelimit-reset seconds on a 429; the default is 1,000 calls an hour
3. Page lists with per_page up to 100 and the returned cursor instead of numbered pages
4. Use a job, not a service, for anything that finishes; services bill until paused or deleted
5. Fetch any docs page with .md appended to get Markdown

Thunder Compute

1. Call GET /v2/status or the get_availability tool before creating an instance. Availability can change before launch, and creation fails when a type is sold out.
2. List instances before retrying a failed create, because the call has no idempotency key.
3. Pass public_key on create. If omitted, the response carries a generated private key that is returned once.
4. To pause work, create a snapshot, delete the instance and later create a new instance from the snapshot. Snapshot storage keeps billing until deleted.
5. For headless use set TNR_API_TOKEN to a token from the console. The MCP server needs a browser sign-in on first connection.