Docker containerization
Docker conversations usually start with one of three complaints. It works on my machine. The release takes an afternoon and two people. Nobody can reproduce production locally to debug it.
01Capabilities
Four places a container earns its keep
Containers turn up as the layer that makes a release repeatable, not as a goal in themselves, which is why this work sits inside DevOps consulting and cloud engagements rather than beside them. The published example below is a containerized migration for a hospitality booking platform.
- Packaging
An application that already runs, made reproducible
Pinned base image, no build tooling left in the runtime layer, configuration and secrets moved out of the image. The hard part is never the Dockerfile. It is finding every piece of state the current server holds by accident.
- Pipeline
Build, scan, tag and promote
Wired into a pipeline so the artifact that passed testing is the artifact that reaches production. We do that in whichever tool you already run, including Azure DevOps and GitHub Actions.
- Parity
Local and test environments that match
Compose files and seeded data, so a developer or a test suite gets the same dependency versions as production, minus the scale. This is where containers pay for themselves fastest, and it is the part teams most often skip.
- Runtime
Somewhere operable to run the images
A managed container service, or a cluster where the load justifies one. That sits inside cloud infrastructure work rather than being a separate exercise.
02Case studies
A booking platform we containerized and moved
One published build in hospitality, where the migration and the containers were the same piece of work.
See all case studies
03Fit
Reproducible builds and orchestration are two different asks
Containers are close to a default now, which is exactly why the question is worth asking out loud. Docker earns its keep when reproducibility is the actual problem. Orchestration is a separate ask with a separate bill, and the two get merged into one decision more often than anything else here. Each row below names the fix that fits, from Docker itself to an automated pipeline or a managed database.
| Your situation | What we recommend |
|---|---|
| Several services, more than one environment, and deploys that behave differently between them | Use DockerReproducibility is the problem it genuinely solves, and the payback arrives early. |
| What you actually want is scheduling, scaling and self-healing across hosts | Different pageThat is a cluster question, not a container one. Our Kubernetes page covers when the weekly operational cost is worth paying and when a managed container service is enough. |
| One small application, one environment, and deploys that are already boring | Keep your deploysYou would be adding an image build, a registry and a new failure mode to fix nothing that is currently costing you. |
| Releases are slow and manual, and somebody suggested containers | Fix the pipeline firstOur Azure DevOps page. A container does not make a manual release automatic, it gives the manual release a tidier artifact. |
| A Windows desktop application, or anything bound to specific hardware or a screen | A repeatable installerContainers buy you very little here. Put the effort into a repeatable build and an installer instead. |
| You were planning to run the production database in a container | A managed databaseUse a managed database service. Containers are good at stateless workloads and mediocre at the backup, restore and upgrade obligations a database brings. |
Scope
What we own on container work is the operational consequence, not the file. That means what the image contains and why, how configuration and secrets reach it, how a bad release gets rolled back, and whether your team can rebuild and ship it without us in the room. unicrew has been running delivery pipelines for clients since 2012, with 100+ senior in-house engineers across six countries. We work under an ISO 27001:2022 certified information-security management system. Containers go where they measurably improve those things, and the first read shows where that is.
Docker makes an application run the same way in every environment. Most of the security work is knowing what is inside the image. We start from a pinned base image chosen on purpose, include only what the application uses, and scan it in the pipeline.
Ihor PrudyvusDelivery Director, unicrew04Delivery
Containerizing something that is already serving traffic
The order matters. Steps one and two are where the surprises live, and both are cheaper before an image exists than after.
- Inventory the state and the configurationLocal files, cron jobs, uploaded assets, certificates, environment variables someone set by hand three years ago. Each of these needs an answer before an image is worth building, because a container will quietly lose the ones you miss.
- Build an image you would defend in reviewPinned base image, multi-stage build so compilers and test tooling never reach production, non-root user, no secrets baked in, and a health check that means something. A working image and a safe image are different achievements.
- Run both, compare, then cut overThe containerized version runs beside the current one against real traffic shapes until parity is boring. The old path stays available until it is provably unnecessary, because a rollback nobody has rehearsed is not a rollback.
- Hand over the pipeline and the runbookRegistry access, tagging convention, how to roll back, how to get a shell into a running container, and who rebuilds the base image when a vulnerability is published. Handover is part of the work, not an email at the end of it.
05Stack
Where these images get built and where they run
The four neighbours of a container decision, each with its own page if that is the call you are really making.
06Questions
What teams ask before the first Dockerfile
Answered the way we would answer them on a call, starting from the setup you already have.
Yes, and on container work it often makes sense, because your people hold deployment history no document captured. Our engineers own the design as well as the containers: an architect outside the delivery team reviews the image and deployment design, and the work goes through the same QA and test automation practice as our own projects. Team extension is managed teams; handing us the outcome is DevOps consulting.
No, and treating the two as one decision is the most expensive mistake in this area. Docker gives you the artifact and the reproducibility. Kubernetes gives you orchestration, and it charges for it in operational attention every week. A managed container service runs the same images with a fraction of that surface, and for a handful of services that is usually where we land.
Usually yes, and the work is archaeology more than engineering. We look for state written to the local filesystem, hardcoded paths, assumptions about the hostname, jobs living in crontab, and configuration that exists only on the running server. Those findings decide whether this is contained work or the wrong first step, and sometimes the answer is modernization first.
In development, yes, and we do it as standard so everyone gets the same version and the same seed data. In production we default to a managed database service. Running a database yourself means owning backups, restore rehearsals, failover and version upgrades, and a container removes nothing from that list. We make exceptions where data residency or licensing genuinely forces it.
A scoping call with an engineer rather than a salesperson. For an existing system we ask for read access to the repository and a description of how a release happens today, because half an hour reading the deploy script beats an hour of discussion. You get back a written read on what to containerize, in what order, and what to keep as it is. Most engagements start within two to four weeks.
Three shapes, and which one fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based and quoted per project, and we offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Deciding where containers fit your release?
Send us the deploy process as it exists today, however embarrassing. You will get an engineer's read on what containers would fix, what needs a different fix, and what we would sequence first. The delivery side of that sits in DevOps consulting.