Serverless overview
This page explains what a serverless service is on the Crusoe AI Platform. You get a 30-second mental model of scale-to-zero, plus a comparison with equivalent serverless container products on AWS, GCP, and Azure.
What a serverless service 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 next request has to start a copy before it can be answered. That wait is a cold start, and it takes a few seconds. Every request after it is fast.
- Scale up automatically. Under load, the platform adds copies of your container. Each copy is called an instance. You set the ceiling on how many it may add.
- Revisions never change. Every deploy or edit creates a numbered snapshot of your service:
myservice-00001, thenmyservice-00002, and so on. That snapshot is a revision, a frozen copy of your image and settings. Once created, a revision is never edited. You can split traffic between two of them, so 90% of requests go to the old one and 10% to the new one while you test it. Rolling back is the same move: point 100% of traffic at the 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. TLS — the encryption behind the padlock in your browser — is handled for you.
When to use a serverless service
Reach for one when you already have a container image that speaks HTTP and you want an endpoint without running servers. That covers an API, a web app, a model-serving backend, or 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 Agents.
That image can come from any public registry, or from Crusoe Container Registry (CCR) for your private ones — including the repository the platform builds into when you deploy from source. A public image needs no setup. Anything in CCR has one prerequisite: your project must be connected to Crusoe Cloud, or the pull fails minutes later and the service never turns ready. The same connection is what lets a source deploy build at all. See Crusoe Cloud integration.
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 is automatic: routing, TLS, and adding instances under load. If a cold start is unacceptable for your use case, you can keep one instance always warm.
Behind the scenes, the platform stores your service as a spec — the settings you asked for. A background process called a controller then keeps working until reality matches that spec. That is why a deploy returns "accepted" straight away and the service turns ready a little later. The service tells you where it has got to in two fields that sit right at the top of it: state, one lowercase word for a human to read, and ready, a plain true/false for a script to branch on.
How it compares
Every major cloud sells the same job: give me a scale-to-zero HTTPS endpoint from a container. GCP Cloud Run, AWS Lambda, and Azure Container Apps each spread that job across two to four overlapping products. Here there is exactly one.
| Crusoe AI Platform Serverless | GCP Cloud Run | AWS Lambda + App Runner | Azure Container Apps | |
|---|---|---|---|---|
| What you give it | A container image | A container image or source code | Lambda: a handler function. App Runner: an image or a repo — and App Runner is closed to new customers | A container image |
| Scale to zero | Yes, by default (min instances 0) | Yes | Lambda: yes — it runs one invocation at a time, per request | Yes, via KEDA-based scale rules |
| Revisions and traffic splits | Yes — same concept and behavior as Cloud Run | Yes | Different model (Lambda versions and aliases) | Yes — same revision concept |
| Product decisions to make first | None — one product | Cloud Run vs. Cloud Run functions | Lambda vs. App Runner vs. Fargate, plus API Gateway for HTTP | Container Apps vs. Functions vs. Functions-on-Container-Apps |
The platform's serverless service streamlines container deployments by providing automated scale-to-zero compute, zero-configuration HTTPS endpoints, and seamless traffic-splitting across revisions.
You deploy through the web console, the REST API, or platformctl serverless create. If you know Cloud Run, you already know our revision and traffic model. The service mapping has the full translation table.
In this section
- Deploy a service — full walkthrough: image, console, API, readiness, and quota math.
- Autoscaling and scale to zero — min/max instances, concurrency, cold starts, keeping one warm.
- Public endpoints and domains — publishing, URLs, and TLS.
- Troubleshooting — real error messages and their fixes.
- Crusoe Cloud integration — required before deploying a private image from your own registry.