Docker — isolated containers for stable websites

What a container is — and why it matters for your site

A container is a standardised package containing the application and absolutely everything it needs to run: runtime, libraries, configuration. The container runs isolated from the rest of the server, but uses the host's Linux kernel directly — no separate operating system per application. Docker, launched in 2013, turned this technology into an accessible standard; the image format is now standardised as OCI (Open Container Initiative) and runs identically on any Linux server or cloud.

The classic analogy is the shipping container: whatever cargo it holds, it has the same standard shape and can be moved onto any ship, train or truck. Likewise, the 4buildsite services that build and deliver your site — the editor, the FastAPI API, the rendering engine — are packaged into standard images that run the same on the test server and in production. For you, as a site or shop owner, that means predictability: what you saw in preview is exactly what your visitors get.

• Container = the application + its dependencies, in one isolated package
• Standard OCI format — the same image runs on any server or cloud
• No separate operating system per service — starts in seconds, not minutes
• On 4buildsite, containerisation is handled by the platform — you just publish

Isolation: your site does not depend on its neighbours

On classic shared hosting, hundreds of sites share the same server, the same processes and often the same PHP installation. If a neighbour gets a traffic spike or a badly written script eats all the CPU, your site slows down — the "noisy neighbour" problem. 4buildsite attacks this from two directions. First: published sites are rendered statically — no per-site code (PHP, plugins, scripts) runs on the servers delivering them, so there is no neighbour's badly written script to eat the CPU. Second: the platform services each run in their own container, with separated processes and files (via namespaces) and the option of CPU and memory limits (via cgroups, the Linux kernel's mechanisms).

Isolation matters just as much for security. On shared hosting, one compromised site can become a gateway to neighbouring sites on the same server. On 4buildsite, a published site is a set of static files — there is no per-site code to compromise through plugins or themes — and the platform services that process data (orders, payments, the editor) live in separate containers: the filesystem is isolated, and an incident stays contained inside that container.

• Published site = static files — zero per-site code to slow down or compromise
• Platform services: separate filesystem and processes per container
• Predictable performance: static delivery, just as fast at 3 a.m. and at campaign peak

The same version everywhere: zero "works on my machine"

The most common source of defects on the classic web is the gap between the environment where a site was tested and the server where it runs live: a different language version, a missing extension, a different configuration. A Docker image eliminates this entire class of problems: the image is built once, with all dependencies pinned, and the exact same artefact runs in testing and in production. There is no "manually configured on the server".

For you, this translates directly into stability. When you edit your site in the visual editor at panel.4buildsite.net and hit publish, the version that reaches visitors has gone through the same steps, through the same containerised services, every single time. Fewer surprises after publishing means fewer nights with the shop down — and for an online shop, every hour offline means lost orders.

Zero-downtime publishes and rollback in seconds

On 4buildsite, publishing does not mean "take the site down, copy files, hope". Every publish generates a new, complete version of your site — rendered statically, separate from the one that is live — and the switch to it is atomic: in a single operation, the delivery service starts serving the new version. Visitors see no interruption — not even mid-order, with items in the cart. The same principle applies to the platform services: a container's new version starts alongside the old one and takes traffic only after health checks.

Just as important is the road back. Every published version of the site is kept intact, so returning to the previous version simply means switching back — an operation of seconds, not an hours-long backup restore. If a publish introduces a problem, your shop is not stuck on the broken version. The one honest nuance: data (orders, products, content) lives in the database, separately from published versions — which is why it is managed on persistent volumes, separate from the site files.

• Every publish = a new, complete version, switched atomically — no interruption
• Rollback = switching back to the previous version, in seconds
• Publish changes any time, even in peak sales season, with no downtime risk

Efficiency and cost: more performance for the same money

A classic virtual machine runs a complete operating system for every application — gigabytes of memory and minutes of boot time spent on "packaging" alone. Containers share the host kernel, so far more sites fit on the same server, each with its own isolation. This density is the reason 4buildsite can include hosting and SSL in the subscription, with no separate per-site infrastructure cost.

For your published site, traffic scaling is even simpler: being static files, serving them is extremely cheap — a visitor spike means more files delivered, not extra processes stepping on each other. And the platform services, being containers that start in seconds, can get additional instances when needed. You pay a predictable subscription, not an infrastructure permanently sized for the busiest day of the year. For how we actually operate these containers — orchestration, proxy, CI/CD, monitoring — see the Cloud & DevOps page.