I'm working on a setup where several client machines connect over a local network to a web application hosted on a server. The server also runs the database and the web app in a container, with the whole system installed at customer sites.
I've run into two main issues. First, containers launched with a restart policy such as `always` do not reliably come back after updates. I suspect this is because I remove the old container when deploying a new production image, then create another container with the same name, which may not preserve the original configuration.
Second, the client machines need to reflect application updates without someone manually refreshing each browser. They will run in kiosk mode, so when the hosted application changes, the clients should update automatically. The server can be refreshed manually if necessary, but that is not practical for every client.
Is Docker Desktop the right choice for this environment? Should I use a Linux-based server or another deployment approach, and what is the usual way to make kiosk clients detect a new version and reload safely?
4 Answers
The browser not showing new content immediately is not really a container problem. Browsers keep the current page loaded until it is refreshed or the application tells them that something changed. For kiosk clients, the app can maintain a WebSocket or similar connection to the server. When a deployment occurs, the server can broadcast an update event, and the client can reload after a short delay. A simpler option is periodic version polling, where the client checks a small endpoint every few minutes and reloads when the version changes. Make sure assets are cache-busted so the browser does not reuse old JavaScript or CSS files.
If the main goal is simply to serve one React app to several clients on a local network, Docker may be more infrastructure than you need. A normal web server on a stable server operating system could be easier to maintain. Docker is still reasonable if you already have a team comfortable with it and can standardize deployments with compose files, health checks, image tags, logs, and rollback procedures. The important part is having a repeatable deployment process rather than relying on a graphical desktop tool or manual container replacement.
Docker itself can work, but Docker Desktop is mainly a development convenience and may not be the best production runtime. A dedicated Linux server running Docker or another container runtime is usually more predictable. If you replace containers during deployment, make sure the new container is created from the intended compose or deployment configuration, including its restart policy. In practice, using a compose file and a repeatable deployment process is safer than manually deleting and recreating containers.
That makes sense. This currently runs on the same PC as the database at customer sites, so I need to investigate whether a small Linux server or virtual machine would be more appropriate than relying on a desktop installation.
Before choosing the tooling, plan the deployment and recovery process as a whole. At each customer site you need to account for the operating system, hardware capacity, startup behavior, network access, backups, update rollback, and what happens if the server or application fails. Running the database and web app on one machine may be acceptable, but you should still have a tested backup and a way to restore the previous application version. Containerization does not automatically solve deployment or operations; it mainly makes the application environment more consistent.
I’m an employee and this was proposed as a replacement for an older IIS-based setup, but the deployment plan is not well defined yet. I’m going to push for a documented update, rollback, backup, and recovery process before treating Docker as the complete solution.
A WebSocket notification sounds useful, but version polling may be easier to implement and more reliable for a single local-network React application.