CaaS: run containers without operating Kubernetes
Declare the image, the resources and the scaling rule. Placement, networking, certificates, rollout and scaling are the platform problem.
What is CaaS?
DevOpsArk CaaS is the containers-as-a-service module that runs container workloads on managed infrastructure without requiring the consuming team to operate Kubernetes directly.
What CaaS is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- A small team needs to run six containers and is told to learn Kubernetes first.
- Every internal tool ends up with its own bespoke deployment arrangement.
- The cluster is over-provisioned because nobody wants to size a workload they do not understand.
- Ingress, TLS and DNS wiring is repeated by hand for every new service.
- Nobody wants to own the cluster for a workload that runs three containers.
CaaS accepts a container image, the resources it needs, the ports it exposes and a scaling rule, and runs it on DevOpsArk-managed capacity. Underneath it is Kubernetes, but the consuming team does not interact with it: ingress, TLS certificates, DNS records, service discovery, log and metric collection and rolling updates are configured by the platform from the declaration. Scaling can be request-driven, CPU-driven or scheduled, including scaling to zero for workloads that are idle most of the time. Because CaaS workloads use the same inventory, monitoring, cost attribution and security scanning as everything else, an internal tool running on CaaS is as visible as a production service running on a dedicated cluster.
What CaaS does
The 6 capabilities that make up CaaS.
Declarative container workloads
Image, resources, ports and scaling rule: the platform derives the rest.
Request, CPU and schedule scaling
Scale on incoming requests, resource usage or a schedule, including scale to zero when idle.
Networking configured for you
Ingress, TLS certificate, DNS record and service discovery wired automatically from the declaration.
Observability included
Logs and metrics collected into the same plane as the rest of the estate, with no per-workload setup.
Per-workload cost
Cost attributed to the workload and its owning team from the first minute.
Same security baseline
Image scanning, policy and secret handling identical to workloads on dedicated clusters.
How CaaS fits together
Outcomes
- A small team ships a container the same day without a Kubernetes project.
- Internal tools stop each inventing their own hosting arrangement.
- Idle workloads cost nothing when scaled to zero.
- CaaS workloads are as visible and governed as everything else.
- No team owns a cluster for the sake of three containers.
Using CaaS, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Declare the workload
Provide the image, resources, ports and scaling rule.
- 2Platform places it
Capacity is selected and networking is configured automatically.
- 3Expose it
Ingress, TLS certificate and DNS record are created.
- 4Scale
Requests, CPU or schedule drive replica count, including to zero.
- 5Operate
Logs, metrics, cost and security posture appear alongside the rest of the estate.
Where teams apply CaaS
Run an internal tool
Deploy a container with an ingress and a certificate without touching cluster configuration.
Host a scheduled job
Run a container on a schedule with resources declared and cost attributed.
Offer a low-friction tier
Give teams a path that does not require Kubernetes knowledge while keeping governance.
Cut idle spend
Scale intermittent workloads to zero instead of paying for reserved capacity.
What CaaS works with
Named integrations link to their own page. The rest are supported runtimes and formats.
CaaS: frequently asked questions
The 6 questions teams ask most often before adopting CaaS.
Containers as a service is a model where a platform runs container workloads on managed infrastructure, so the consuming team declares what it wants to run rather than operating the orchestration layer itself.
CaaS runs on Kubernetes underneath, but the team does not interact with it. Placement, ingress, TLS, DNS, scaling and rollout are derived from a short declaration rather than configured through manifests.
Yes. Request-driven scaling can take a workload to zero replicas when idle and start it again on the next request, which suits internal tools and intermittent jobs.
Yes. They use the same inventory, log and metric collection, cost attribution, image scanning and policy engine as workloads on dedicated clusters.
When the workload needs cluster-level control: custom controllers, specific node hardware, particular networking or service mesh configuration. CaaS covers the common case where none of that is required.
Yes. The workload is a standard container image with a declared configuration, so it can be expressed as ordinary Kubernetes manifests and deployed through ArkCD.
See CaaS against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.