Container as a service: how it works and what it costs

Container as a service, or CaaS, means running containerized applications on infrastructure a provider operates. You supply an image or source code that becomes an image. The service handles some combination of scheduling, networking, scaling and host maintenance. You still own your application, its configuration and its data requirements.

The term covers several operating models. A managed Kubernetes cluster, a serverless HTTP container and an always-running application service can all appear in CaaS comparisons, but they leave very different work to your team.

This guide comes from Lizard. Product references were checked on 9 September 2026.

What happens when you deploy a container

A typical deployment has four parts: build the image, store it in a registry, start an instance, and route traffic to it. The provider then observes the instance and handles restarts or scaling according to its rules.

Your image must start the right process, listen on the expected interface and port, and provide configuration in the form the application understands. The platform cannot infer whether a successful HTTP response means the application can write to its database.

For a worker, routing may not be needed at all. The important checks become queue access, process lifetime, retries and graceful shutdown. Treat web and worker runtimes as separate requirements.

CaaS, PaaS, FaaS and IaaS compared

These labels overlap. A PaaS can build a container for you. A function service can accept a container image. Image support alone does not tell you whether a queue consumer can run continuously. Our PaaS guide compares the complete application workflow.

Three ways providers run your image

An application service

Use this model when you want to run a conventional web process or worker. Lizard is one option; Railway and Render are others. Compare their lifecycle, deployment controls and data services rather than assuming every implementation is identical.

On Lizard, you can deploy from source or supply a Dockerfile. Use the deployment documentation to choose the path. Configure non-HTTP services using the worker guide.

A request-driven container

This model starts or scales instances around incoming work. It can suit APIs with uneven traffic. Check concurrency, request timeouts, idle settings and how the provider bills memory as well as CPU.

Cloud Run separates Services, Jobs and worker pools. Match the resource type to the process. A batch program that exits and a web server that receives requests should not use the same deployment assumptions.

A managed scheduler or cluster

ECS and managed Kubernetes give you more control over how several workloads run. You may still need to design networking, permissions, deployment policies and observability.

For AWS, Fargate removes the need to manage the worker machines for supported ECS or EKS workloads. It does not remove the need to understand the surrounding AWS resources. If cluster operation is the problem you want to avoid, read the Kubernetes alternatives guide.

What container hosting leaves with you

Data: decide which data belongs in a database, object storage or an attached volume. A writable filesystem is not proof that files survive replacement of an instance. Test the exact persistence behaviour you rely on.

Secrets: give each service only the values it needs. Confirm that the application reads those values and fails clearly when one is missing.

Release safety: a new image may require a schema migration. Plan the order and compatibility of application and database changes, including rollback.

Recovery: a restart can recover a process. It cannot reconstruct a lost database or repair a bad migration. Test backups and restoration separately.

Capacity: resource limits prevent one service from consuming everything available to it, but they do not establish throughput. Measure latency, errors and queue depth under representative load.

How to estimate CaaS cost

List every billed component: runtime CPU and memory, image storage, builds, persistent storage, internet transfer, load balancing, logs and databases. Include the plan or control-plane fee where one applies.

Then identify the meter. Some products bill allocated capacity for the time an instance runs. Others measure consumption or active request time. A published hourly CPU rate is not comparable until you know what creates a billable hour.

For example, ten containers running concurrently for one hour produce ten container-hours. Ten one-hour runs executed in sequence produce the same runtime total, but they need different concurrency limits. The application may also experience different queue delays. A cost estimate should state both runtime and peak concurrency.

Use AWS Fargate pricing, Cloud Run pricing, Railway billing and Lizard pricing for the relevant meters. Do not reuse one provider's memory or transfer allowance in another provider's calculation.

A short evaluation plan

Deploy a representative service with its real start command. Check its health endpoint, database connection and one meaningful user flow. Restart it and confirm how temporary and persistent files behave. Run enough traffic to observe resource use and latency.

Repeat those checks for a worker if the app has one. Then calculate the bill from the observed meters and the plan your team can use. Choose the model that satisfies the lifecycle and recovery requirements with an operating process you understand.

FAQ

Does CaaS require Kubernetes? No. Kubernetes is one way to schedule containers. Application platforms and services such as ECS or Cloud Run can run containers through other interfaces.

Is CaaS the same as Docker hosting? The terms often overlap. Read the runtime contract: image support, process lifetime, networking, persistent storage and operational responsibility matter more than the label.

Can a container keep uploaded files? Only if the storage setup provides the durability you need. Use a database, object storage or a suitable attached volume and verify behaviour across redeploys.

Can I deploy without writing a Dockerfile? Some providers build an image from source. Lizard supports that path through lizardpack. Check the supported language and project layout in the current documentation.