OCI Container Instances: Containers Without Kubernetes

Kubernetes has become the default answer to the question of how to run containers, and for large fleets of interdependent services it is the right answer. But the default has a cost. A Kubernetes cluster is a piece of infrastructure in its own right, with a control plane to version, worker nodes to patch, networking add ons to configure, and an operational learning curve that is real even on a managed service. Teams routinely stand up a cluster to run three containers, and then spend more effort caring for the cluster than for the containers. For a surprising number of workloads, the honest requirement is much simpler: run this image, give it this much CPU and memory, put it on this subnet, and restart it if it dies.

OCI Container Instances is the service built for that requirement. You hand OCI a container image and a resource specification, and the service runs the container on dedicated, isolated compute that it provisions and manages for you. There is no cluster to create, no node pool to size, no operating system to patch, and no orchestrator to upgrade. The container starts in seconds to a couple of minutes, gets a real network identity in your virtual cloud network, and runs for as long as you need it to, whether that is twenty minutes of batch processing or months of serving an internal API. This article is a practitioner guide to the service: what it actually is, how it compares to OCI Functions and OKE, how to size, network, and automate it, and where it earns its place in an application platform. It is part of our wider series on application development and serverless on OCI, which maps the full set of compute choices for modern applications.

What Container Instances actually is

A container instance is a unit of serverless container hosting. When you create one, OCI allocates dedicated compute capacity sized to your request, pulls your container images, and runs them. The capacity is isolated at the hypervisor level, which means your containers are not sharing a kernel with other tenants, a meaningful security property that distinguishes the service from container platforms that pack many customers onto shared hosts. From your point of view there is no virtual machine to see or manage. You never receive an operating system login, never apply a patch, and never think about the host at all. The compute exists only to run your containers and disappears when the instance is deleted.

One instance can run a single container or several containers as a unit, sharing the same network identity, the same allocated resources, and the same lifecycle. This grouping behaves much like a Kubernetes pod and supports the same patterns: an application container alongside a logging agent, a proxy in front of a service, or an initialization container that prepares state before the main process starts. What you do not get, deliberately, is anything above that unit. There is no scheduler placing workloads across a fleet, no service discovery layer, no rolling deployment controller, and no horizontal autoscaler. The service runs the unit you define and nothing more, which is precisely why it is so simple to operate.

How it differs from Functions and from OKE

OCI gives you three main ways to run application code in containers, and they sit on a clean spectrum of management overhead versus capability. OCI Functions is event driven and scales to zero: code runs only when invoked, you pay per execution, and the platform imposes constraints on execution duration, memory, and runtime shape in exchange. OKE, covered in depth in our guide to microservices patterns on OKE, is full Kubernetes: maximum capability, service discovery, autoscaling, rolling deployments, and the operational weight that comes with all of it. Container Instances sits between them, and the comparison is easiest to see side by side.

The contrast with Functions deserves one more sentence because it trips people up. Functions looks cheaper for everything because idle code costs nothing, but the moment a workload runs continuously or near continuously, the per execution model loses its advantage and the duration and runtime constraints start to hurt. Container Instances has no scale to zero scheduler, so an instance left running is an instance being billed, but in exchange it accepts any container, runs it for any length of time, and gives it a real network identity. We work through that economic crossover in detail in serverless versus containers on OCI.

Shapes and sizing

Container Instances uses flexible shapes, which means you choose an exact OCPU count and memory allocation rather than picking from a menu of fixed sizes. You can allocate fractions of the resource envelope to individual containers within the instance, so a main application container can receive most of the CPU while a sidecar logging agent receives a sliver. This granularity matters for cost because you pay for what you allocate, and a service that genuinely needs one OCPU and four gigabytes should be provisioned at exactly that rather than rounded up to the nearest large size.

The shape choice includes both x86 processors and Ampere ARM processors, and the ARM option is worth taking seriously. For most containerized workloads, interpreted languages, JVM services, Go binaries, and Node applications among them, ARM delivers equivalent performance at a meaningfully lower price per OCPU, and building multi architecture container images is now a routine part of any competent pipeline. If your images already build for ARM, running them on Ampere shapes is one of the cheapest wins available on OCI, and we cover the mechanics and the benchmarking approach in our guide to ARM and Ampere compute on OCI.

Images, registries, and pull secrets

A container instance can pull images from the OCI Registry, known as OCIR, or from any public or private registry reachable over the network. OCIR is the natural home for private images because it lives inside your tenancy, integrates with IAM policy, and keeps pulls on the Oracle network. For private registries, including private OCIR repositories, you attach image pull secrets to the instance, credentials stored in an OCI Vault that the service uses at pull time. The practical advice is simple: keep production images in OCIR in the same region as the instances that run them, version images with immutable tags rather than reusing a floating tag, and treat the pull secret as a managed credential with rotation, not a password pasted into a console once and forgotten.

Networking: a real address in your subnet

This is the feature that most clearly separates Container Instances from lighter weight container runners. Each instance receives a VNIC in a subnet you choose, which means the container has a genuine IP address inside your virtual cloud network, subject to the same routing, security lists, and network security groups as any compute instance. You decide whether the instance gets a public IP or stays private. A private instance can sit behind a load balancer, reach databases over the internal network, and resolve names through your VCN resolver. An instance in a public subnet can serve traffic directly, though for anything beyond a quick test you will want a load balancer in front of it anyway.

Because the instance is a first class network citizen, the security model is familiar rather than novel. Use network security groups to scope exactly which sources can reach the container port, keep egress rules as tight as the workload allows, and place instances in private subnets by default. There is no special container networking layer to learn, no overlay, and no ingress controller. The flip side is that there is also no service mesh and no built in service discovery: if instance A needs to find instance B, you wire that up yourself with DNS, a load balancer, or configuration. For two or three services that is trivial. For thirty it is the signal that you have outgrown the service.

Storage, configuration, and restart policies

Storage on a container instance is ephemeral. Containers get scratch space that lives and dies with the instance, and there is no native attachment of block volumes. Anything the workload needs to keep must go to Object Storage, a database, or another external service. This constraint is healthy for the use cases the service targets, since stateless services and batch jobs that read from and write to durable stores are exactly what it is built for, but it rules out workloads that need a persistent local filesystem.

Configuration follows familiar container conventions. You pass environment variables per container, override the image entrypoint and command if needed, and set working directories at creation time. Secrets should come from OCI Vault and be injected at startup rather than baked into images. The restart policy is the closest thing the service has to self healing: set it to always for long running services so a crashed container is restarted in place, set it to never for batch jobs that should run once to completion, or restart only on failure for jobs that should retry when they exit badly. It is a deliberately small set of options, and within its scope it works exactly as you would hope.

Observability

Container standard output and standard error flow into the OCI Logging service once you enable a log for the instance, giving you searchable, retained container logs without an agent to install. Metrics for CPU and memory utilization per instance flow into OCI Monitoring, where you can chart them, set alarms, and feed notification topics. This is enough to answer the operational questions that matter for this class of workload: is the container up, is it crashing and restarting, is it approaching its memory allocation, and what did it print before it died. Application level telemetry, traces and custom metrics, is your application's job to emit, exactly as it would be on any other platform.

Lifecycle and automation

Everything you can do in the console you can do with the CLI, the SDKs, and Terraform, and the service really comes alive when it is automated. A container instance is a small, declarative object: image, shape, subnet, environment, restart policy. That makes it an excellent target for infrastructure as code, where the entire definition fits in a short Terraform resource, and for pipelines, where a CI job can create an instance to run integration tests against a freshly built image and delete it when the suite finishes. Start and stop operations are first class, so dev and test instances can be stopped outside working hours on a schedule and started again in the morning, cutting their cost by two thirds without anyone touching the console. Batch workloads follow the same pattern: a scheduler or pipeline creates the instance, the job runs to completion under a restart policy of never, the results land in Object Storage, and the instance is deleted.

Pricing: pay for what you allocate, while it runs

The pricing model is the same as flexible compute: you pay for the OCPUs and memory you allocate, for the time the instance is running, and nothing else. There is no per cluster fee, no orchestration premium, and no per request charge. Stopped instances stop billing for compute. This makes cost modeling refreshingly easy. A service that needs one Ampere OCPU and six gigabytes around the clock costs what that allocation costs per month, full stop, and you can read it straight off the rate card. The corollary is that the model rewards two habits: sizing allocations honestly, because every OCPU is billed whether the container uses it or not, and being aggressive about stopping or deleting instances that do not need to run. A forgotten instance is the closest thing the service has to a cost trap, and a tagging discipline plus a periodic sweep keeps it from happening.

Where Container Instances fits, and where it does not

Strong use cases

The service shines for APIs and web applications with steady, predictable load, where one or two right sized instances behind a load balancer serve traffic around the clock and the absence of autoscaling costs you nothing because the load does not spike. It is excellent for batch and ETL jobs, which get clean isolation, unlimited run duration, and a natural create, run, delete lifecycle. Dev and test environments suit it well, since each branch or tester can get a disposable instance without anyone budgeting cluster capacity. It also handles the long tail of operational tooling: an internal dashboard, a webhook receiver, a message consumer, a sidecar style utility that does not justify a cluster, and CI runners that build and test inside containers on capacity that exists only while the pipeline runs.

Weak use cases

The service is the wrong tool for large microservice fleets. Once an architecture has many services that need to discover each other, scale independently with demand, deploy with rolling updates, and share cluster wide concerns like ingress and certificates, you are describing Kubernetes, and pretending otherwise leads to rebuilding orchestration badly in scripts. That estate belongs on OKE, and our Kubernetes on OKE practice exists for exactly that build. It is also wrong for spiky event driven work that idles most of the day, where Functions and its scale to zero economics win, and for anything needing persistent local storage, which wants a proper compute instance or a stateful platform.

A decision view in one paragraph

Choose Functions when work arrives as events, executions are short, and idle time dominates, because scale to zero is unbeatable for that profile. Choose Container Instances when you have a container that needs to run continuously or to completion, the service count is small, the load is steady, and you want zero infrastructure management without Functions style constraints on duration and runtime. Choose OKE when the number of services, the deployment cadence, or the autoscaling requirement makes orchestration itself the feature you need. Many real estates use all three, and the boundaries between them are the architecture decision that matters most in this layer of the platform.

From image to production: a six step path

Bringing it together

Container Instances fills a gap that every cloud platform eventually has to fill: the space between event driven functions and full Kubernetes, where most ordinary applications actually live. Its value is in what it refuses to make you do. No cluster, no nodes, no patching, no orchestrator, just a container with real resources and a real network address, billed plainly for what you allocate while it runs. Used for the right workloads, steady services, batch jobs, dev and test, and operational tooling, it is often the simplest and cheapest correct answer on OCI. Used as a substitute for orchestration it will disappoint, and recognizing that boundary early is the skill. If you are modernizing an application estate and working out which workloads belong on Functions, Container Instances, or OKE, that placement exercise is the heart of our app modernization work on OCI, and it is a conversation worth having before the first cluster gets built rather than after.