Deployment · in regular use
Docker agency in Nice
The tool that runs an application the same way on a developer's machine and on the production server.
What we do with it
Docker at our clients, concretely
Used across our development and deployment work, with Portainer for supervision. Also used on the infrastructure side, alongside Proxmox and virtualisation.
The limits
When we recommend something else
For a static site, Docker adds nothing: the HTML file is served directly.
Our work
Projects we delivered with Docker
Paradigm
Platform for a Nice business centre: registered address, digitised mail, messaging and assistant.
Docker: Identical development, staging and production environments.
Read the Paradigm case studyHelioneo
Collective self-consumption platform: agreements, allocation keys, Enedis data and billing.
Docker: Application, job worker and cache deployed as containers.
Read the Helioneo case studySilversun — prospection
B2B prospecting tool for renewable energy: geocoded projects and enriched prospects.
Docker: Deployment of the API, front end and services.
Silversun — suivi de chantier
Solar project progress timeline for the end customer, fed by the CRM.
Docker: Containerised service.
LLM Monitor
SaaS that measures how visible brands are in AI answers.
Docker: API, workers and audit engine deployed as containers.
Read the LLM Monitor case studyOrdelya
Restaurant management platform: back office, tablets, kiosks, screens and website.
Docker: One container per service, plus the device fleet management.
Mejid & Co
Installable web app for tracking disbursements for Mejid & Co's clients.
Docker: Application and PocketBase back end deployed as containers.
Read the Mejid & Co case studyJeu-concours Snake
Six-level retro contest game, with quiz and sign-up, for a laptop marketing campaign.
Docker: Application build and serving.
Read the Jeu-concours Snake case studyAngeles Immobilier
Multilingual website for a Côte d'Azur estate agency: listings, search and blog.
Docker: Production image of the website.
Read the Angeles Immobilier case study
Method
How we bring Docker into a project
We write one Dockerfile per service and one Compose file per environment, development and production, differing only where they must: code mounts, logging level, open ports. Images are built in several stages so the final one carries no compiler or development tooling. Each container declares a health check, so a service that hangs gets restarted, not just one that has stopped.
Images are built by the continuous integration pipeline, tagged with the code version and stored in a private registry. Deploying means switching tag on the server; rolling back means returning to the previous tag. Sensitive settings live in an environment file that exists only on the server, never in the repository.
Data stays outside the containers: databases and user-uploaded files sit in named volumes, exported and copied off the machine. On the infrastructure side, the whole stack usually runs inside a Proxmox virtual machine, with Portainer showing the state of every service. We hand over a Portainer login in your name and a sheet setting out, service by service, how to restart it, update it and restore its data.
For your business
What it changes in practice
For your users, Docker means calmer releases. The version installed on the server is the one that was tested, with the same libraries, and if something new causes trouble, the previous version goes back in place without reinstalling anything. A service that hangs overnight restarts on its own instead of waiting for a colleague to report it the next morning.
For the business, the most tangible effect shows on the day of a hardware failure or a change of hosting provider: the application is rebuilt on a new machine from the repository and the data backups, with no detective work on what was installed years ago. Maintenance becomes more routine, since updating a component means rebuilding an image and testing it before deployment. Docker does not remove the operational work, though: the host server, backups and security patches still need looking after, and we set that out in the action plan rather than glossing over it.
Our reading of it
What we take away from Docker
Docker exists to delete one sentence: it works on my machine. The application and everything it depends on — language version, system libraries, environment variables — are described in a versioned file, and the machine running in production starts from the same description as the developer’s laptop.
The real gain shows up at two moments. When a new developer arrives and starts the project with one command instead of a day of setup. And in continuous integration, where the same image is tested and then deployed: our GitLab and GitHub pipelines only ship what has been verified. We also use it for heavy development dependencies, a PostgreSQL database for instance, without installing anything permanently on the machine. In production we will say when a container is needless complication: a static site does not need one.
Decision guide
Should you choose Docker?
Docker or installing the application directly on the server?
Docker, as soon as the application depends on a specific version of a language, a database or system libraries. The image describes the whole environment in a file versioned with the code: production runs what the developer tested, and a new server can be prepared without redoing the installation by hand. A direct install is still acceptable for a single, stable service looked after by someone who knows the machine. For a static site, Docker adds nothing.
Docker Compose on a server, or Kubernetes?
For a small or mid-sized business, Docker Compose on one or two servers covers most needs: a few services, a database and a proxy, restarted automatically if they stop. Kubernetes addresses different constraints, such as spreading many services across a cluster with automatic scaling, and it calls for operational skills few small teams have in-house. Until those constraints are real, we recommend Compose, with Portainer for supervision.
Docker containers or Proxmox virtual machines?
They complement each other more than they compete. A virtual machine isolates a whole system, which suits separating environments, sensitive workloads or applications that need their own operating system. A container isolates one application, starts quickly and uses few resources. We routinely run Docker inside Proxmox virtual machines: virtualisation keeps environments apart, containers make deployments reproducible. Picking one does not rule out the other.
Client questions
What clients ask us about Docker
Does Docker lock us into working with MZ Informatique?
No. Docker is a free, standard tool, and your container configuration lives in plain text files, the Dockerfile and Compose file, kept alongside the source code. Another provider can read them and bring the application up on a different server without piecing the installation back together. If anything it works the other way: without those files, how the server was set up often lives only in one person's head.
Are Docker containers secure?
They are when configured carefully, bearing in mind that a container isolates less strongly than a virtual machine. We start from official, lightweight images, rebuild them regularly to pick up patches, avoid running applications with root privileges, expose only the ports required and keep passwords out of images. The host server must stay up to date too: a well-tuned container cannot make up for a neglected host.
Should we move our existing application onto Docker?
Not necessarily straight away. The benefit shows when you need to move the application, reinstall it after a failure, or give several developers the same working environment. Containerising an older application often uncovers dependencies nobody documented, which is useful but takes time. We usually start with the development environment, then move production across once that setup has proved itself.
How is the data of a Docker-based application backed up?
A container can be deleted and recreated without loss, as long as no data is stored inside it. Databases and user files are therefore kept in separate volumes. For a database, we use its own export tool rather than copying its files while it is running, which would produce an inconsistent backup. The exports are then sent to storage separate from the server, so they survive the loss of the machine.
Does Docker work on our developers' Windows or Mac machines?
Yes. On Windows and macOS, Docker runs inside a small virtual machine managed by a desktop application, invisibly to the developer. Two things are worth knowing: file access to the project is slower than on Linux, which volume configuration can offset, and the official desktop application requires a paid subscription for companies above a certain size. Free alternatives are available.
Going further
Docker sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A Docker project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on