Containers
Run container images without operating schedulers yourself—scaling, routing, and upgrades included.
Pricing
Plans bundle compute, memory, and persistent storage the same way as our other compute products, plus registry capacity when you store images with Tower. Pick a SKU row that matches your workload, then refine with the technical reference below if you need sign-off from security or finance.
Loading SKUs...
Ship images faster.
Keep operations small.
Many teams do not need to own a full orchestration stack for every service. They need a stable place to run a container image with clear CPU and memory boundaries, persistent disks where required, and a load balancer that understands health checks.
Container Instances sit in that middle ground: more control than a pure PaaS, far less operational surface than running schedulers and ingress yourself. You bring the image and configuration; Tower enforces isolation, routes traffic, and keeps the control plane current. The trade-off is fit—workloads that need deep kernel customisation or non-containerised stacks may still be better on Virtual Machines.
Pricing maps to compute, memory, and storage SKUs so you can model cost alongside performance, without surprise charges from hidden control-plane or networking fees.
Built like infrastructure,
priced like infrastructure.
Workloads land on enterprise-grade AMD EPYC hardware with ECC memory. The CPU and memory numbers in your SKU are what the scheduler reserves for you—so dashboards reflect real silicon, not nested emulation.
Persistent disks use the same replicated block service Tower uses for databases and VMs: predictable latency for stateful services, automatic healing behind the scenes, and attach flows exposed through the volume APIs. Registry storage stays on Tower Registry with deduplicated layers so image pulls stay fast.
Load balancers, rolling updates, and health checks work together so new revisions only receive traffic after probes succeed, reducing the risk of partial or broken rollouts in production.
What you get on Day One
Opinionated defaults with escape hatches: registries, traffic, storage, and secrets in one product surface.
Multi-registry deploys
Pull from Docker Hub, GHCR, or Tower's private registry. Standard docker push / pull workflows, with no proprietary image format.
Traffic & health checks
HTTP, HTTPS, WebSockets, and gRPC-friendly paths behind a managed load balancer, riding the same public and private bandwidth envelopes we publish for Advance instances (including high private-lane headroom on larger plans).
Stateful & stateless
Run stateless apps on ephemeral storage, or attach durable block volumes for databases, search indexes, and file-heavy workers—still upgraded through the same revision history and health-checked rollouts.
Secrets & config
Inject environment variables and secrets at deploy time. Rotate credentials without rebuilding images, and keep sensitive values out of your registry layers.
Configuration & Platform Details
A concise map of how Container Instances behave, useful for architecture reviews, security questionnaires, and sizing exercises.
Platform specifications
Values reflect the Container Instances product line; exact limits may vary by region and account tier.
- Runtime & images
- Standard container images from Docker Hub, GitHub Container Registry (GHCR), or Tower Registry. Linux workloads with conventional entrypoints and health check commands.
- Compute platform
- Dedicated vCPU and memory per deployment, backed by enterprise-grade AMD EPYC hardware. Resource limits match the SKU you purchase so neighbours cannot steal cycles from latency-sensitive services.
- How it runs
- Tower operates the control plane, scaling, routing, and upgrades—you supply the image, environment, and scaling policy. You never patch our orchestration layer; you focus on application releases.
- Persistent storage
- Optional attachable block disks use the same replicated storage service as databases and VMs. Data survives redeploys and restarts; attach and detach through Tower APIs.
- Networking
- Managed load balancing with HTTP, HTTPS, WebSocket, and gRPC-friendly paths. TLS terminates on the edge; private connectivity options follow regional Tower networking guides.
- Scaling & availability
- Horizontal scaling with configurable replica bounds and health-check-driven traffic shifting—new revisions only receive traffic after probes succeed.
- Deployments
- Rolling updates with surge control, revision history, and safe rollback when post-deploy health checks fail.
- Secrets & configuration
- Environment variables and secrets injected at deploy time without baking credentials into image layers—rotate keys without rebuilding images.