We handle
- Cluster operation, node patching, and scheduling
- Manifest authoring, image pull credentials, and secret injection
- Ingress, TLS, and DNS for anything exposed publicly
- Resource limit enforcement and restart-loop alerting
Entry
Container Workload
Your image, running on our cluster, described in a repository.
What this tier is
You have a Dockerfile. You do not have a cluster, and you should not have to build one to run a single service. This tier runs your image on our Kubernetes tier with a manifest kept in a repository, which means the workload can be rebuilt exactly rather than reconstructed from memory.
Resource requests and limits are set explicitly and published to you. If your workload needs more, we tell you what it is actually using rather than discovering it during an incident.
Specification
| Compute | 1 container, 0.5 vCPU request, 1 vCPU limit |
|---|---|
| Memory | 1 GB limit |
| Storage | 10 GB persistent volume if required |
| Registry | Public or private with supplied credentials |
| Exposure | Public hostname with TLS, or internal only |
| Config | Declarative manifest in a repository |
| Logs | Retained and readable on request |
What is included
- One container from your registry, public or private with credentials
- Declarative Kubernetes manifest held in a repository
- Explicit CPU and memory requests and limits
- Public hostname with managed TLS, or internal-only exposure
- Persistent volume where the workload needs one
- Environment variables and secrets injected at runtime
- Restart policy, health checks, and log access
Typical use cases
- A bot, webhook receiver, or integration service
- A small API or microservice supporting a larger product
- A self-hosted open-source tool your team needs internally
- A build agent or scheduled worker that should not live on a laptop
Responsibility split
Written down so there is no argument about it later.
You handle
- Building and publishing the container image
- Application configuration and whatever the container does
- Telling us when the image tag changes, or wiring a webhook to do it
How provisioning works
Operator-provisioned. We need the image reference, the port, and any environment the workload requires. Usually running the same or next business day.
Order
Other tiers in Managed compute and containers
Most common
Managed Virtual Server
A real machine with root, and somebody else responsible for the host.
$32 /mo
- Root access on a real virtual machine, not a container
- Scheduled snapshots with off-host backup copies
- Hypervisor, storage, and network operated by us
View details
More cores, more memory, and dedicated CPU rather than burst.
$72 /mo
- Dedicated CPU allocation rather than burst credits
- 8 GB memory and 200 GB storage
- Priority on capacity when we schedule host maintenance
View details
Cron that somebody notices when it stops.
$9 /mo
- Execution history and exit codes, not silent failure
- Alert on failure or on a missed run
- Runs on maintained infrastructure, not somebody's desktop
View details
Background reading
- Docker for game servers: clarity over hype Reproducible builds, update flow, and where containers stop helping.
- Double NAT and CGNAT: the silent party crashers Symptoms, diagnosis, and when a hosted relay is the honest answer.