# Bring the Dockerfile. Skip the rest.

> Managed hosting for containerised apps. One image runs on a dedicated server at a fixed rate. A Compose stack gets a flat quote. CodeHerder ships image changes.

Source: https://customhosted.com/host/docker/

№ 01 What we host

A single container runs on a dedicated instance like any other app. A Compose stack of several services gets a flat custom quote instead of one fixed tier.

When this isn't the right fit Does the container only run a static site build? Then serve the built output on Static Starter. It costs less than a dedicated instance serving files that never change.

№ 02 The requirements

## What it needs to run

The shape of the workload, before any hosting decision gets made.

- **Runtime**: Whatever is in the image. We run it as it is.
- **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

№ 03 How it runs

## 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. The container runtime is installed and restarts a container on a crash or a deploy.
- Deploys — Push to main. The pipeline builds the image from your Dockerfile and restarts the container. We run your images as they are.
- Data + backups — Volumes and any attached managed database back up every night, the same as every other stack. A container does not change that.
- TLS / DNS / monitoring — Certificates renew on their own and we manage DNS end to end. Monitoring restarts a crashed container and alerts a person if it keeps failing. — [What a visitor sees during a restart →](https://customhosted.com/what-visitors-see)

№ 04 Moving it in

## Moving it in

Already running somewhere else? The full [migration playbook](https://customhosted.com/migrate) covers the general steps. Below is what is specific to Docker.

1. 1 — Point us at the images — We need read access to the Dockerfile or Compose file, and to the registry.
2. 2 — We stand up a copy — We provision the stack as code from your existing images. We check it on a staging copy before anything goes live.
3. 3 — Cutover on your schedule — DNS and TLS switch over with little-to-no downtime. A rollback stays ready if anything looks wrong.

The real gotchas

- A `docker-compose.yml` written for a laptop often assumes local volume paths and a shared network. A fresh instance has neither, so read it through before the first deploy.
- Secrets baked into an image must come out before the first deploy here and be passed in at run time. We flag this as a security fix.
- Past a couple of containers, one custom quote usually costs less than several dedicated instances. We tell you when that is true.

№ 05 The loop

## The loop, on Docker

A containerised app changes like any other app. The loop briefs against the code that builds the image, not against the container runtime.

1. 01 — Build — CustomLabs — Bring the Dockerfile or Compose file you have. Or CustomLabs designs and containerises the first version.
2. 02 — Iterate — CodeHerder — Brief a change to the app inside the image in plain language. An agent opens a pull request against the real repo, and the image rebuilds on merge.
3. 03 — Run — CustomHosted — A dedicated instance for one container, or a custom quote for a multi-service Compose stack. We patch it and back it up either way.

An example brief

- **The brief**: A health-check endpoint added to the app inside the image, wired into the container’s existing readiness probe.
- **What the pull request holds**: The endpoint and the probe config, in one pull request the agent opens against the real repo.
- **What happens next**: [A human reviews and merges](https://customhosted.com/review). [It ships through the same pipeline](https://customhosted.com/deploys).
- **A real one**: [The site is blinding at night](https://customhosted.com/case-files#cf-01) (+751 −258 · 19 files · merged 2026-07-31).

№ 06 Container vs. stack

## One container is not a platform

"It's Dockerised" can mean two different hosting problems. One price for both would be wrong for one of them.

A single image (one Dockerfile, one process, maybe a health-check endpoint) is a dedicated instance with extra packaging. The container runtime does an init system's job. It starts the process, restarts it on a crash and exposes a port. We price it like any other single-process app, because that is what it is.

A `docker-compose.yml` that wires an app, a worker, a cache and a database together is a different shape. The services must find each other on a network and share or isolate storage. After a restart, they must come back up in the right order. At that point, "just run my containers" is a design problem, and a custom quote exists for design problems. We work out how many instances the stack needs. We also check if the database should be a managed tier instead of a container. Then we price the result flat.

The service count in the compose file usually tells you which shape you have. One or two services with no dependencies between them still fit a dedicated instance. Three or more, or a stack with its own internal network, is worth describing on the quote form first. We would rather size it right once than resize it after it is live.

№ 07 A starting configuration

## 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

[Get this quoted →](https://customhosted.com/contact?plan=DD-L&addons=AD-CH&src=docker) [Size it differently on the estimator →](https://customhosted.com/#estimate)

№ 08 FAQ

## Docker questions

The questions this stack raises on its own. General hosting questions live on the homepage.

1. 01 Do 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 a flat quote, sized to what it needs.
2. 02 Do we need to change our Dockerfile to move here? Usually no. We run the images you have. We flag anything that assumes a local-only setup, such as bind mounts or a laptop network, before the first deploy.
3. 03 Where do secrets live? We pass them in at deploy time. They are not baked into the image. If we find secrets in an image during a move, we flag them and help take them out. See Configuration for where a value lives after that.
4. 04 Can CodeHerder change the Dockerfile itself? Yes. A brief can change the base image, add a dependency or add a build stage. It comes back as a pull request. Someone reviews it before the image rebuilds.
5. 05 What container registry do you pull from? The one you already use. Give us read access. You do not need to switch registries to move in.

№ 09 See also

## Keep exploring

- [Custom stacks Where multi-service Compose stacks live: designed and quoted flat.](https://customhosted.com/custom)
- [Dedicated compute A fixed-price instance for a single container, with a static IP and full control.](https://customhosted.com/dedicated)
- [Migrations Already running your images somewhere else? A rehearsed cutover with little-to-no downtime.](https://customhosted.com/migrate)
- [Configuration Where a value goes once it leaves the image, and who can read a setting or a secret back.](https://customhosted.com/configuration)

## Ready to start?

Tell us what you're running — one fixed monthly rate, within a business day.

[Get a quote →](https://customhosted.com/contact)