Container runtimes
oblako isn’t hard-wired to Docker. Every service runs through a pluggable
ContainerBackend, chosen with the OBLAKO_CONTAINER_BACKEND environment
variable, so the same oblako up works on Docker, Podman, Colima, a Kubernetes
cluster, or Apple’s container.
|
Runtime |
How it’s reached |
|---|---|---|
|
Docker Engine |
the Docker socket |
|
Podman |
the Podman socket (auto-detected) |
|
Colima |
the Colima Docker socket (auto-detected) |
|
a Kubernetes cluster |
pods + |
|
Apple |
lightweight per-container VMs |
DOCKER_HOST always takes precedence for the Docker-API runtimes.
Docker (default)
Nothing to configure:
oblako up
Podman / Colima
Both speak the Docker Engine API, so they share the Docker backend, oblako
auto-detects their socket (or honour DOCKER_HOST):
export OBLAKO_CONTAINER_BACKEND=podman # or: colima
oblako up
Kubernetes
Each service becomes a Deployment + Service in a namespace, and a
kubectl port-forward makes localhost:PORT reach the in-cluster Service, so
your boto3 code is unchanged. Needs kubectl and a cluster (minikube, kind,
EKS, …).
export OBLAKO_CONTAINER_BACKEND=kubernetes
export OBLAKO_K8S_NAMESPACE=oblako # optional, defaults to "oblako"
oblako up
The per-task compute paths (Lambda exec, Glue jobs, SageMaker local) need a real Docker daemon; under Kubernetes they fall back to the ambient Docker context.
Apple container (macOS 26+)
Runs Linux containers in lightweight VMs. container run -p publishes to
localhost just like Docker, so oblako’s fixed-endpoint contract holds, boto3
still hits localhost:9000, etc.
export OBLAKO_CONTAINER_BACKEND=apple
oblako up
Limitations
No Docker socket, so the services that spawn containers, Lambda (moto-managed), SageMaker local, and Glue, aren’t available on this backend.
Apple
containerdoesn’t emulate amd64, so amd64-only images won’t run: oblako’s own images (e.g. Redshift) are multi-arch; third-party amd64-only images need a Docker backend.host.docker.internalisn’t provided; oblako substitutes the vmnet gateway automatically.