Use case · Web & apps
Docker hosting
Docker packages applications with their dependencies into containers that run consistently anywhere, more efficiently than virtual machines. Running containers with Docker — and Docker Compose for multi-container apps — is often simpler than Kubernetes and enough for many workloads. Bare metal avoids double virtualisation. Dedicated, EU-hosted infrastructure gives containers full performance, control, and European sovereignty.
Key points
- Docker packages an application with its dependencies into a container that runs consistently anywhere.
- Containers are more efficient than virtual machines, sharing the host's kernel.
- Docker Compose runs multi-container apps simply, without the complexity of Kubernetes.
- For many workloads, Docker alone is enough — you don't always need orchestration.
- Bare metal avoids double virtualisation, and EU hosting keeps containers' data sovereign.
What is Docker, and what are containers?
Docker is a platform for building and running containers — packaged units that bundle an application together with its dependencies, so it runs consistently wherever the container runs. A container holds the application and everything it needs to run — its code, libraries, and dependencies — isolated in a unit that behaves the same regardless of the environment it runs in, which solves the long-standing problem of applications behaving differently across different systems. Docker made containers widely accessible and has become the common way to build and run them, so that packaging an application as a container is now a standard approach.
Containers matter because they make applications portable, consistent, and efficient to run, which is why they underpin so much of modern deployment. An application packaged as a container carries its dependencies with it, so it runs the same on a developer's machine, a test system, and production, removing a common source of problems; and containers are efficient, as the next sections describe. Hosting containers means providing infrastructure to run them — the servers, resources, and container platform they need. This page focuses on running containers with Docker, including where simple Docker suffices and where fuller orchestration such as Kubernetes is warranted, which is covered on its own pages.
Why containers: consistency, portability, and efficiency
Containers offer consistency and portability, because a container runs the same wherever it goes, carrying its dependencies with it, which removes the differences between environments that otherwise cause problems. When an application is packaged as a container, it behaves the same across development, testing, and production, since it brings its own dependencies rather than relying on what happens to be installed on each system. This consistency makes deploying and moving applications more predictable, and the portability lets a container run on any infrastructure that runs containers, which is much of why containers are so widely used.
Containers are also more efficient than virtual machines, because they share the host's operating-system kernel rather than each running a full guest operating system. A virtual machine includes an entire operating system, which consumes resources; a container shares the host's kernel and includes only the application and its dependencies, so it is lighter, starts faster, and lets more containers run on given hardware than virtual machines would. This efficiency means a server can run many containers, using its resources well. These advantages — consistency, portability, and efficiency — are why containers have become a standard way to package and run applications, and why hosting them well matters.
Running containers with Docker
Running containers with Docker involves images and containers: an image is the packaged template of an application and its dependencies, and a container is a running instance of an image. Images are built to package an application, and containers are started from images to run it, so that the same image can be run as containers wherever needed, consistently. The Docker engine runs on a server and manages running containers from images, providing the environment in which containers execute. This model — build an image, run it as containers — is the foundation of using Docker.
Hosting Docker means providing servers running the Docker engine with the resources the containers need. The containers run on the server's compute, memory, and storage, so the server must be resourced for the containers it runs; and because containers are efficient, a well-resourced server can run many. For a single server running containers, this is straightforward — the Docker engine on a suitably-sized server runs the containers. We provide servers running Docker, sized for the containers they host, so that containerised applications run on infrastructure resourced for them, whether a single server running several containers or part of a larger setup. The infrastructure gives the containers the resources they need to run.
Docker Compose: multi-container apps without Kubernetes
Many applications consist of several containers — an application container, a database, a cache, and so on — and Docker Compose provides a simple way to define and run such multi-container applications on a single host, without the complexity of Kubernetes. With Compose, the several containers that make up an application, and how they connect, are defined in a file, and Compose runs them together as a unit, handling their coordination on the host. This is a far simpler way to run a multi-container application than a full orchestration platform, suited to running an application's containers together on one server.
For a great many applications, Docker Compose on a server is enough, and reaching for Kubernetes would add complexity without need. An application whose containers run together on a single server, or a modest setup, is well served by Compose, which coordinates the containers simply. Kubernetes becomes worthwhile at larger scale, across many servers, with needs for automated scaling and resilience that Compose does not provide; but below that, Compose is simpler and sufficient. We host multi-container applications with Docker Compose for those whose needs it meets, providing the server and resources the composed containers run on — a simpler path than Kubernetes for applications that do not need full orchestration.
When Docker alone is enough — and when you need orchestration
The honest position is that for many workloads, running containers with Docker, perhaps with Compose, is enough, and full orchestration such as Kubernetes is more than is needed — its power suits larger, more demanding cases. If an application's containers run comfortably on one server, or a few, and do not need automated scaling across a cluster, self-healing at scale, and the other capabilities orchestration provides, then Docker and Compose serve well with far less complexity. Adopting Kubernetes for such a case adds substantial complexity for benefits the workload does not need, which is a poor trade.
Orchestration becomes worthwhile when scale and needs grow: running many containers across many servers, needing automated scaling, resilience, and management that a single host and Compose cannot provide. At that point Kubernetes earns its complexity; below it, Docker is the simpler, sufficient choice. The right approach depends on the workload, and we will not push orchestration where it is not needed. We host both — simple Docker and Compose for workloads they suit, and Kubernetes for those that warrant it — matching the approach to the need. Being honest about when Docker alone is enough saves organisations the complexity of orchestration they do not require, which serves them better than defaulting to Kubernetes.
Bare metal and resource efficiency for containers
Containers run well on bare metal, which gives them full performance and avoids the double virtualisation of running containers on virtual machines. Like Kubernetes, containers already provide a layer of packaging and isolation; running them directly on bare metal, rather than on virtual machines, avoids adding a virtualisation layer beneath, so the containers get the hardware's full performance without that overhead. On bare metal, a server's full resources are available to the containers, and their efficiency means many can run, using the hardware well.
This combination of containers' efficiency and bare metal's full performance makes bare metal attractive for running containers where performance and density matter. Containers already let many applications share a server efficiently; on bare metal, without a virtualisation layer consuming resources, that efficiency is greatest, and the containers get full performance. For running containers at any scale where getting the most from the hardware matters, bare metal suits them. We host containers on dedicated bare-metal servers, so that they run with full performance and the greatest efficiency, avoiding the double virtualisation that running containers on cloud virtual machines would impose, and making good use of the hardware.
Sovereignty, and where VV Internet Hosting fits
Containers run an organisation's applications and handle their data, so where the containers run governs that data, making sovereignty a consideration, and hosting on EU infrastructure keeps it European. VV Internet Hosting is incorporated in the Netherlands, within the EU, so containers hosted with us run under European jurisdiction and outside the direct reach of the US CLOUD Act, keeping the applications and their data under European law. For containerised workloads handling data subject to European protection, running them in the EU keeps that data sovereign.
We host dedicated infrastructure for running containers with Docker: servers running the Docker engine, sized for the containers they host, with support for multi-container applications via Compose and the option of fuller orchestration where warranted — on bare metal for full performance and efficiency, in EU datacenters under European jurisdiction. This suits organisations running containerised workloads that want performance, control, and European sovereignty, at whatever scale their needs call for. We are clear about our limits: we provide the dedicated infrastructure you run containers on, not a managed container platform that operates them for you; and we are honest about when simple Docker suffices versus when orchestration is warranted. We are the dedicated, sovereign infrastructure for running containers — and if that fits your workloads, we can host them well.
See also
Questions
Docker, answered plainly
Common questions about hosting for Docker.
What is a container, and how does it differ from a virtual machine?
A container packages an application with its dependencies into an isolated unit that runs consistently anywhere. Unlike a virtual machine, which includes a full guest operating system, a container shares the host's kernel and includes only the application and its dependencies — so it's lighter, starts faster, and lets more run on given hardware. Docker is the common platform for building and running containers.
Do I need Kubernetes, or is Docker enough?
For many workloads, Docker — perhaps with Docker Compose for multi-container apps on a single host — is enough, and Kubernetes would add complexity without need. Orchestration like Kubernetes becomes worthwhile at larger scale: many containers across many servers, needing automated scaling and resilience. Below that, Docker is simpler and sufficient. The right choice depends on the workload.
Why run containers on bare metal?
To get full performance and avoid double virtualisation. Containers already provide packaging and isolation; running them on virtual machines adds a virtualisation layer beneath. On bare metal, containers run directly on the hardware with full performance, and their efficiency is greatest since no virtualisation layer consumes resources — so a server runs many containers, using the hardware well.
Planning Docker infrastructure?
We host dedicated, EU-sovereign infrastructure sized to your workload — and we will tell you plainly when something else fits better. Tell us what you're building.