Docker for Business Applications: Why Containerisation Matters

Docker is often introduced as a developer convenience: “it works on my machine” becomes “it works in this image.” For a business application, that slogan is incomplete. The reason to containerise is operational: you want to deploy the same artefact twice, restore a database without folklore, and let a second person take over when the original installer is on leave.

Palmate Solutions uses Docker and Docker Compose as a default runtime shape for many cloud and DevOps engagements. We do not treat Kubernetes as a maturity badge. If Compose on a VPS matches the load and the team, that is a complete answer. The sample study containerised delivery on a VPS is that pattern written down — a sample architecture, not a named-client uptime claim.

What a container is (and is not)

A container is a packaged process with its own filesystem view, isolated enough to run alongside other containers, sharing the host kernel. An image is the immutable recipe; a container is a running instance. Compose is a file that names the app, worker, database, networks, and volumes so you are not typing docker run from memory.

A container is not a virtual machine. It will not save you from a full disk, a bad secret, or an application that stores uploads in an ephemeral layer. It is not “the cloud.” You can run Compose on a laptop, a VPS, or a cloud VM. Hosting choice is a separate article: choosing between a VPS and cloud hosting.

A container is also not a substitute for securing a Linux production server. The host still needs users, SSH policy, a firewall, and patching. Docker running as root on an unhardened box is a neatly packaged target.

The business problems containers actually address

Production was edited live. Files changed over SSH. Staging does not match production. A dependency update requires tribal knowledge. Images plus a compose file make the runtime declared. You review a pull request instead of reconstructing what someone typed at 2am.

Deploys are copy-and-hope. Building an image in CI, pulling it on the server, and running compose up with a previous image still on disk is a rollback story. Copying a zip onto a VM is not.

“It works locally” uses different versions. The Dockerfile pins the runtime. Developers and production stop arguing about whose Node or PHP patch level is real.

Onboarding is a scavenger hunt. A new engineer runs Compose and gets the app, worker, and database — not a wiki page of apt commands from 2023.

What containers do not automatically give you: high availability, correct backups, or a secure app. Those remain design work.

A shape that fits most business apps

For a typical internal or customer-facing application:

• Edge — Nginx or Caddy terminates TLS and routes to the app container. Health checks fail closed.
• App and worker — same image, different command. They share an internal network. They do not publish the database port to the internet.
• Database — named volume, backups as a job or sidecar, not “the volume is the backup.”
• Secrets — environment files or a secret store that is not committed to git.
• Uploads — a mounted volume or object storage. Putting user files in the image layer is how they vanish on the next deploy.

That is the architecture in the containerised VPS sample: photograph the current VM, compose locally until tests pass, stand up staging, restore a backup into staging before touching production, then cut over DNS with a documented rollback.

# Illustrative only — names and versions are yours to pin.
services:
  proxy:
    image: caddy:2
  app:
    image: registry.example.com/app:git-sha
    env_file: /etc/app/production.env
  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data

Pin tags. latest is how Friday’s deploy becomes Monday’s mystery.

Staging that is not a rumour

The operational win is parity. Staging should run the same compose graph, with anonymised data, on a second VM or a namespace. If staging is “SQLite on a laptop” and production is “MySQL tuned by a contractor in 2021,” containers will not save you. They will only package the lie more neatly.

Use staging to:

• Restore last night’s backup and time the restore.
• Run migrations once, on purpose.
• Test TLS and hostnames that are not production.
• Practise a rollback by pinning the previous image tag.

If you cannot restore into staging, you do not have a backup. You have a file.

Compose versus orchestrators

Docker Compose is the right default when one or two machines run a known set of services, deploys are serial, and you can tolerate a short window or a simple rolling restart. It is readable. A competent engineer can follow it.

Swarm or Kubernetes earn their keep when you need scheduled rescheduling across nodes, richer rolling updates, or many teams sharing a cluster. They also add APIs, networking models, and failure modes you must staff. Moving a five-container business app onto Kubernetes because a blog post said so is how you buy a second full-time job.

We will recommend an orchestrator when the load, team, and failure requirements demand it — not as a prestige layer.

Pitfalls we see on real VMs

• Bind-mounting the whole project into production so “deploys” are git pulls inside a container. You have reinvented live edit with extra steps.
• No resource limits, so a runaway worker starves Postgres on the same host.
• Logs only inside the container, gone after restart, so incidents cannot be reconstructed.
• Root containers and docker.sock mounted into random tools “for convenience.”
• Skipping the website launch checklist — DNS, TLS, backups, and who gets paged are still the launch, whether the process is containerised or not.

What Palmate implements

Cloud hosting and DevOps for us means Compose files that match how you actually run staging and production, a reverse proxy with automatic TLS, monitoring, and a pipeline that is not SSH-and-hope. The goal is an environment a competent engineer can understand at 11pm.

Containerisation matters because it turns a pet server into a described system. It does not remove the need to secure the host, test restores, or choose VPS versus cloud on purpose. Do those jobs, package the app, and keep the topology as small as the business allows.

When a second person on the team can deploy and restore, the containers have done their job. Until then, you still have a snowflake — it just starts with docker.