Compute
Containers

A container is a packaged version of your app that includes everything it needs to run. Think of it like shipping your entire laptop setup to the cloud, not just the code. This means your app runs the same way in the cloud as it does on your machine.
When to use containers
Containers are the default choice for most applications. Use them when you have a web app, an API, or anything that needs to stay running and respond to requests. They are also the right pick for background jobs that run continuously, like processing a queue.
If you have a Dockerfile or docker-compose.yml, you are already set up for containers.
What should I use locally?
Build your app any way you want. You don’t need to think about containers or Docker at all. Spawned analyzes your source code and handles containerization for you automatically.
Serverless

Serverless functions are small pieces of code that run only when something triggers them. Instead of a server that is always on, the cloud spins up your function when a request comes in, runs it, and shuts it down. You only pay for the time your code is actually executing.
When to use serverless
Use a serverless function when you have a task that needs to run on a schedule. For example: fetching data from an external API every hour, generating a daily report, or cleaning up expired sessions. If your workload mostly sits idle between runs, serverless is significantly cheaper than keeping a container running 24/7.
The tradeoff is that serverless functions have a cold start delay (a brief pause the first time they run after being idle) and are not suited for long-running tasks.
What should I use locally?
Write a function that does what you need and run it manually during development. For Spawned to detect it as a serverless function, structure it as an AWS Lambda handler:
def handler(event, context):
# your code here
return {"statusCode": 200}
Spawned will detect and provision it with schedule configuration on deploy.
Kubernetes

Kubernetes is an orchestration platform for running many containers together. You define your services, networking, and scaling rules in configuration files, and those definitions are portable across cloud providers. Larger companies often use it to standardize how they run services across teams and providers.
When to use Kubernetes
If your team already has Kubernetes manifests or Helm charts, Spawned can deploy them directly. This is useful when migrating existing infrastructure or working within an organization that has standardized on Kubernetes.
For most projects, plain containers are simpler and do everything you need.
What should I use locally?
If you already have Kubernetes configuration, bring it as-is. Spawned currently supports uploading existing manifests and Helm charts. It does not generate Kubernetes configuration from source code yet.