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
A container is an always-on process, billed for every hour it runs whether or not anyone is using it. Choose one when the process genuinely has to stay up: a request can take longer than 30 seconds or streams its response, the app holds connections open (websockets, server-sent events), a worker consumes a queue all day, or the runtime does not fit a function package. Files on local disk that must survive a restart also point here, with a Volume attached.
A web app or an API that answers a request and then waits for the next one does not need a container. Start it as a serverless function and move to a container when one of the reasons above shows up. Having a Dockerfile is not by itself a reason; the shape of the work decides.
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
Serverless is the starting point for most applications. A function serves HTTP when you connect a domain to it, so a web app or an API that answers requests and waits for the next one runs here and costs nothing while idle. It is also the shape for anything on a schedule: fetching data every hour, a daily report, cleaning up expired sessions.
The tradeoffs are a cold start (a brief pause on the first request after idle time), about 30 seconds per request when serving HTTP, and no persistent connections. When an app hits one of those, it moves to a container and nothing else about the project changes.
What should I use locally?
Write a function that does what you need and run it manually during development. When you want to deploy, make sure to structure it as an AWS Lambda handler:
def handler(event, context):
# your code here
return {"statusCode": 200}Add it to your project as a Function component, connect a domain to it for HTTP or set a schedule, and Spawned provisions it on deploy. An existing web app runs as a function without code changes: keep its Dockerfile, add the AWS Lambda Web Adapter to the image, and the app keeps listening on its port while the adapter turns gateway events into requests. Rewrite the entry point as a handler (Mangum for ASGI apps, serverless-wsgi for Flask and Django) only if you prefer a zip package.
Kubernetes
Kubernetes is an orchestration platform for running many containers together. When you choose Kubernetes for a project, Spawned generates the full set of manifests for it (Deployments, Services, Ingress, and more) from the same components you would use on any other platform. You describe your app once, and Spawned compiles it to Kubernetes for you.
When to use Kubernetes
Choose Kubernetes when you want your workloads on a cluster: to standardize how your team runs services, to stay on infrastructure you control, or to run alongside existing Kubernetes resources. For projects that don’t specifically need a cluster, plain containers are simpler and do everything you need.
Connecting your cluster
Spawned uses a pull-based GitOps workflow. It writes your generated manifests to a Git repository that your cluster syncs from with ArgoCD, so you never share cluster credentials and Spawned never needs direct access. See Kubernetes for setup.
What should I use locally?
Build your app the same way you would for containers. You don’t write Kubernetes manifests yourself. Spawned generates them from your project.