For companies whose applications still run on servers set up by hand
Containers and automated releases, without rewriting your application
When releases depend on manual steps and on the one person who knows them, every change is a risk and every upgrade is postponed. I package your applications in containers, set up a development environment that matches production, automate building, testing and deployment, and train your team to run it.
Typical situations
The application works, but every change to it is harder than it should be.
Releases by hand
Files copied to the server, commands over SSH, a checklist in someone’s head. Releases are rare because they are risky.
It works on my machine
Developers’ machines, the test server and production differ, so some errors only appear after the release.
Upgrades keep being postponed
The runtime, the operating system and the libraries fall behind, because nobody knows what an upgrade would break.
One person knows how it works
The setup lives in the head of one developer or an external agency, so holidays and departures become a risk.
No automated checks
Tests, security scans and reviews depend on someone remembering them.
Case study: a shared CI/CD platform
A European technology company (a current client, not named)
Current engagement · DevOps team lead
I built a central CI/CD platform: shared pipelines that every team uses in its own repositories, with the same container builds and the same security checks everywhere.
The starting point
Build, test and release steps were defined separately in each repository, so every improvement and every security check had to be repeated everywhere.
What I did
- Reusable GitHub Actions workflows that the teams use in their own repositories
- Container images built the same way for every application
- Automated security checks in every pipeline: image vulnerability scanning, Dockerfile checks and secret detection
- Infrastructure in Terraform and server configuration with Ansible
Technology
- GitHub Actions
- Docker
- Trivy
- Hadolint
- gitleaks
- Terraform
- Ansible
How the work is organised
Three phases, each with a written result. You decide after every phase whether to continue.
Assessment
What runs where, and how it is released.
- Applications, servers, versions and dependencies
- How releases, backups and access work today
- Risks: unsupported versions, manual steps, missing checks
- A written plan: what to containerise first, the target platform, and the effort of each step
Containers and pipelines
Built, tested and released the same way every time.
- Applications packaged in containers, with configuration and secrets kept out of the images
- A development environment that starts with one command (Docker Compose)
- CI/CD pipelines: build, tests, image scanning and deployment on every change
- Infrastructure as code with Terraform, and monitoring with alerts
Handover and operation
Your team runs it, or I do.
- Documentation and a walkthrough of the new setup
- Hands-on training for developers and operators
- A follow-up review after the first releases
- Optional hosting and operation of the containerised applications
Scope and working model
Your application, as it is
Most applications can be containerised without rewriting them. Where a code change is needed, for example to read the configuration from the environment, I describe it and your developers implement it.
The platform that fits
A server with Docker Compose, a managed container service on AWS, or Kubernetes: the choice follows the number of applications, the team and the requirements. Kubernetes only where it pays off.
Location and hours
Based in Alicante, Spain, working remotely with teams across Europe and beyond, on Central European Time (CET/CEST). Engagements in English or Spanish.
Confidentiality and access
A non-disclosure agreement is in place before any system access. Access is least-privilege and time-bound, and no production change is made without your agreement.
Outside the scope
- Software development: writing or rewriting application code, or moving the application to another language or framework. Code changes stay with your developers or agency; I provide the environment, the pipelines and the advice.
- Reselling hosting capacity, cloud capacity or licences.
I have been introducing containers and CI/CD in development teams since 2014, and I build Kubernetes platforms on AWS. See experience
Frequently asked questions
Do we have to rewrite the application?
No. Applications in PHP, Java, Node.js, Python and most other languages run in a container as they are. Small changes, for example reading the configuration from environment variables, are described in the plan and made by your developers.
Do we need Kubernetes?
Usually not at the start. For a few applications, a server with Docker Compose or a managed container service such as Amazon ECS is simpler to run. Kubernetes pays off with many services and several teams.
Do we have to move to AWS?
No. Containers run on your own servers, at your hosting provider or in the cloud. I work mainly with AWS and recommend it where it fits.
Which tools do you use?
Widely used tools with good documentation: Docker and Docker Compose, GitHub Actions or GitLab CI, Terraform, and, where it fits, Kubernetes with Helm and ArgoCD. No custom scripts that only one person understands.
Can you host and run the applications?
Yes, on request. Once the applications run in containers, I can host and operate them in an environment I manage, or hand the setup over to your team.
How much work is it?
That depends on the number of applications and on how they are released today. The written plan after the assessment states the effort of each step before you commit to it.
Schedule a consultation
Describe your applications briefly: what they are built with, where they run, and how they are released today. Please do not send passwords or access details through this form.