Skip to main content

Serverless overview

This page explains what a serverless service is on the Crusoe Agent Platform, gives you a 30-second mental model of scale-to-zero, and shows how it compares to the equivalent products on AWS, GCP, and Azure.

What it is​

You hand the platform a container image — a packaged copy of your app and everything it needs to run. The platform gives you back a running web endpoint. You never see or manage servers.

Four ideas do most of the work:

  • Scale to zero. When nobody is calling your service, it runs zero copies and costs nothing in compute. The first request after an idle period "cold-starts" a copy — that request takes a few seconds — then requests are fast.
  • Scale up automatically. Under load, the platform adds copies (called instances), up to a ceiling you set.
  • Immutable revisions. Every deploy or edit creates a numbered snapshot of your service (myservice-00001, myservice-00002, ...). A revision never changes after it is created. You can split traffic between revisions — for example, send 90% of requests to the old one and 10% to the new one to test it — and roll back by pointing 100% of traffic at an older revision.
  • Private by default. A new service is reachable only from inside your project. Turn on publish and the platform gives it a public HTTPS URL like https://checkout-api-acme.apps.codyhill.dev, with TLS (the encryption behind the padlock in your browser) handled for you.

When to use it​

Use a serverless service when you have a container image that speaks HTTP and you want an endpoint without running servers: an API, a web app, a model-serving backend, an internal tool. If you have a single Python function rather than a full container, Functions may be a better fit. If you are deploying an AI agent, use the Agent Engine.

The 30-second mental model​

A request to your service takes this path:

When your service sits idle for about 90 seconds, the platform drains it to zero instances. The next request waits a few seconds while a fresh instance starts, then gets its response. Everything in between — routing, TLS, adding instances under load — is automatic. If a cold start is unacceptable for your use case, you can keep one instance always warm.

Behind the scenes, the platform records your service as a spec (the settings you asked for) and a controller continuously works to make reality match it. That is why deploys return "accepted" immediately and the service becomes Ready a little later — you can always check where things stand in the service's status.

How it compares​

Every major cloud sells this same job — "give me a scale-to-zero HTTPS endpoint from a container" — but spreads it across two to four overlapping products. Here there is exactly one.

Crusoe Agent Platform ServerlessGCP Cloud RunAWS Lambda + App RunnerAzure Container Apps
What you give itA container imageA container image or source codeLambda: a handler function. App Runner: an image or a repo — and App Runner is closed to new customersA container image
Scale to zeroYes, default (min instances 0)YesLambda: yes, per-request modelYes (KEDA-based)
Revisions and traffic splitsYes — same concept and behavior as Cloud RunYesDifferent model (Lambda versions and aliases)Yes — same revision concept
Product decisions to make firstNone — one productCloud Run vs. Cloud Run functionsLambda vs. App Runner vs. Fargate, plus API Gateway for HTTPContainer Apps vs. Functions vs. Functions-on-Container-Apps

Honest caveats: the big clouds offer many regions, formal SLAs, and mature per-request billing. This platform is in alpha — one environment, no SLA yet, and deploys happen through the web console or the REST API (the CLI is read-only for serverless today). If you know Cloud Run, you already know our revision and traffic model; see the service mapping for the full translation table.

In this section​