Containerize app with Docker and migrate to Kubernetes
Employer
Andriy
Project parameters
Type of cooperationOne-time project
SectionAdministration
Prepaymentwithout prepayment
Payment methodsCash, Bank transfer
Acceptance of requestsfrom today, 17:28 until Sep 6, 2026
Project description
We run a production web application on a single VPS, and that arrangement has become a liability. Every deploy means SSH-ing into the box, pulling code, restarting services by hand, and hoping nothing breaks; there is no isolation between the app and its dependencies, no way to scale under load, and a single reboot takes the whole service offline. We want to modernise this properly. The goal is to containerize the existing application with Docker and then migrate the workload to a Kubernetes cluster, so we finally get reproducible builds, horizontal scaling, self-healing, and deployments that do not require anyone to stay up at night.
The work starts with authoring clean, production-grade Dockerfiles for each service, using multi-stage builds to keep images small and free of build tooling. From there you will package the deployment as a set of Helm charts covering the application, its configuration, secrets, and supporting services, with values files separated per environment. On the cluster side we need Horizontal Pod Autoscaler rules tied to CPU and memory, sensible resource requests and limits, and proper liveness and readiness probes so Kubernetes can restart unhealthy pods and route traffic only to instances that are actually ready. Persistent data and configuration must be handled correctly through volumes, config maps and secrets rather than baked into images.
Finally, the whole thing has to fit into an automated CI/CD pipeline that builds images, pushes them to a registry, and rolls them out to the cluster on merge. The production rollout itself must be zero-downtime, using a rolling or blue-green strategy with a documented rollback path. Please share your relevant Kubernetes experience and a short plan before you start.
— Dockerfiles for all services with multi-stage builds
— Helm charts with per-environment values, config maps and secrets
— HPA autoscaling plus resource requests, limits, liveness/readiness probes
— CI/CD pipeline building, pushing and deploying images automatically
— Zero-downtime rollout (rolling or blue-green) with a rollback plan
— Short migration runbook and handover documentation
The work starts with authoring clean, production-grade Dockerfiles for each service, using multi-stage builds to keep images small and free of build tooling. From there you will package the deployment as a set of Helm charts covering the application, its configuration, secrets, and supporting services, with values files separated per environment. On the cluster side we need Horizontal Pod Autoscaler rules tied to CPU and memory, sensible resource requests and limits, and proper liveness and readiness probes so Kubernetes can restart unhealthy pods and route traffic only to instances that are actually ready. Persistent data and configuration must be handled correctly through volumes, config maps and secrets rather than baked into images.
Finally, the whole thing has to fit into an automated CI/CD pipeline that builds images, pushes them to a registry, and rolls them out to the cluster on merge. The production rollout itself must be zero-downtime, using a rolling or blue-green strategy with a documented rollback path. Please share your relevant Kubernetes experience and a short plan before you start.
— Dockerfiles for all services with multi-stage builds
— Helm charts with per-environment values, config maps and secrets
— HPA autoscaling plus resource requests, limits, liveness/readiness probes
— CI/CD pipeline building, pushing and deploying images automatically
— Zero-downtime rollout (rolling or blue-green) with a rollback plan
— Short migration runbook and handover documentation
