Bring the Dockerfile. Skip the rest.
A single container runs on a dedicated instance the same way any other app does. Multiple services wired together with Compose — an app, a worker, a cache, a database — get designed and quoted flat instead of squeezed into one fixed tier that doesn’t fit.
When this isn't the right fit If the whole point of the container is a static site build step, running the built output on Static Starter is cheaper than a dedicated instance to serve files that never change at request time.
What it needs to run
The shape of the workload, before any hosting decision gets made.
- Runtime
- Whatever’s in the image — we run it, not re-package it
- Build step
- Image build from your Dockerfile, on every push
- Standing process?
- Yes — one container, or several under Compose
- Data store
- Whatever the Compose stack declares — often Postgres or Redis
- Verdict
- Dedicated for one container · Quoted for multi-service Compose
How it runs here
The same management as every other tier we run, written in Docker's own terms.
Provisioning
A dedicated instance (or a small fleet, for a Compose stack) with the container runtime already installed and wired to restart on crash or deploy.
Deploys
Push to main, the pipeline builds the image from your Dockerfile and restarts the container — we run the images you have, not a re-packaged version.
Data + backups
Volumes and any attached managed database back up nightly, the same as every other stack we run — a container doesn’t change the backup story.
TLS / DNS / monitoring
Certificates auto-renew, DNS is managed end to end, and monitoring restarts a crashed container before a health check fails twice.
Moving it in
Already running somewhere else? See the full migration playbook — here's what's specific to Docker.
- 1
Point us at the images
Read access to the Dockerfile or Compose file and the registry is the whole ask.
- 2
We stand up a copy
The stack is provisioned as code from your existing images, checked on a staging mirror before anything is live.
- 3
Cutover on your schedule
DNS and TLS switch over with little-to-no downtime, rollback ready if anything looks wrong.
- A `docker-compose.yml` written for a laptop often assumes local volume paths and a shared network that don’t exist on a fresh instance — worth a read-through before the first deploy, not after.
- Secrets baked into an image instead of passed in at runtime need to be pulled out before the first deploy here — this is a security fix we’ll flag, not silently ship.
- Multi-service stacks with more than a couple of containers usually cost less as a right-sized custom quote than as several separate dedicated instances — we’ll say so rather than upsell.
The loop, on Docker
A containerised app changes the same way any other one does — the loop briefs against the code that builds the image, not against the container runtime itself.
- 01Build
CustomLabs
Bring the Dockerfile or Compose file you already have, or have CustomLabs design and containerise the first version.
- 02Iterate
CodeHerder
Brief a change to the app inside the image in plain language — an agent opens a pull request against the real repo, the image rebuilds on merge.
- 03Run
CustomHosted
A dedicated instance for one container, or a right-sized custom quote for a multi-service Compose stack, patched and backed up either way.
- Brief
- Briefed: add a health-check endpoint to the app inside the image and wire it into the container’s existing readiness probe.
- Pull request
- CodeHerder’s agent added the endpoint and the probe config against the real repo, opening a pull request the same day.
- Shipped
- Reviewed, merged, and the image rebuilt and redeployed on the next push — no manual `docker build` on anyone’s laptop.
One container is not a platform
"It's Dockerised" describes two very different hosting problems, and pricing them the same way would be dishonest in one direction or the other.
A single image — one Dockerfile, one process, maybe a health-check endpoint — is a dedicated instance with extra packaging. The container runtime does the same job an init system would otherwise do: start the process, restart it on crash, expose a port. We price this exactly like any other single-process app, because that's what it is.
A docker-compose.yml wiring together an app, a worker, a cache, and a database is a different shape entirely — it's several services that need to find each other on a network, share or isolate storage correctly, and come back up in the right order after a restart. That's the point where "just run my containers" stops being a fixed tier and becomes a design problem, which is exactly what a custom quote is for: we work out how many instances the stack actually needs, whether the database should be a managed tier instead of a container, and price the result flat.
The tell is usually the compose file's service count. One or two services with no inter-service dependencies still fits a dedicated instance comfortably. Three or more, or anything with its own internal network topology, is worth describing on the quote form before assuming it maps to one line item — we'd rather size it right once than resize it after it's live.
A starting configuration
A larger Compose stack: a dedicated instance sized for the workload, plus the iteration add-on — a multi-service stack gets a flat custom quote instead.
- Base plan
- Dedicated L
- Iteration — CodeHerder loop
- +$25/mo
- Estimated total
- $124/mo
Docker questions
The questions this stack raises on its own. General hosting questions live on the homepage.
01Do you support Compose stacks, or just single containers?
Both — a single container runs on a dedicated instance at a fixed tier; a multi-service Compose stack gets designed and quoted flat, sized to what it actually needs.
02Do we need to change our Dockerfile to move here?
Usually no — we run the images you have. We’ll flag anything that assumes a local-only setup (bind mounts, a shared laptop network) before the first deploy.
03Where do secrets live?
Passed in at deploy time, not baked into the image — if we find secrets in an existing image during a move, we’ll flag it and help pull them out.
04Can CodeHerder change the Dockerfile itself?
Yes — a briefed change to the base image, an added dependency, or a new build stage comes back as a pull request, reviewed before the image rebuilds.
05What container registry do you pull from?
Whatever you already use — point us at it with read access, no requirement to switch registries to move in.
Keep exploring
- Custom stacks
Multi-service Compose stacks live here — designed and quoted flat, not squeezed into one tier.
- Dedicated compute
A fixed-price instance for a single container, with a static IP and full control.
- Migrations
Already running your images somewhere else? A rehearsed cutover with little-to-no downtime.
Ready to start?
Tell us what you're running — one fixed monthly rate, within a business day.