What CI/CD setup includes
You can order a pipeline for a single service or build out deployment for the whole project.
Build
Every commit is built the same way, no more "works on my laptop".
- ✓Docker images with layer caching
- ✓versions from a tag or commit hash
- ✓images stored in a container registry
- ✓only changed services are rebuilt
Tests and checks
A bug is cheaper to catch before release than after.
- ✓tests and linters
- ✓database migration checks
- ✓merges blocked when tests fail
- ✓results right in the merge request
Security
A vulnerable library or a forgotten password in the code shouldn't reach production.
- ✓image scanning with Trivy
- ✓secret detection in code
- ✓SonarQube for code quality
- ✓secrets in Vault or CI variables, not in the repository
Deployment to a server
For projects without Kubernetes: deploying to a VPS or dedicated server.
- ✓Docker Compose or systemd
- ✓zero-downtime deployment
- ✓database migrations in the right order
- ✓a check that the service came up
Deployment to Kubernetes
Releasing into the cluster with Helm or GitOps.
- ✓Helm charts for services
- ✓ArgoCD: the cluster runs exactly what's in Git
- ✓gradual rollout with checks
- ✓separate namespaces or clusters per environment
Environments
A new version is tested first and reaches customers only after that.
- ✓staging and production
- ✓temporary environments for branches
- ✓manual approval for production
- ✓separate settings and secrets per environment
Rollback
A bad release will happen. The question is how long it lasts.
- ✓back to the previous version with one command
- ✓previous images kept
- ✓automatic rollback if checks fail
- ✓history: who released what and when
Runners and speed
Developers start working around a slow pipeline.
- ✓your own runners instead of paid minutes
- ✓dependency caching
- ✓parallel jobs
- ✓release notifications in Telegram or Slack
CI/CD setup pricing
I estimate the work in hours before starting and agree it with you.
| Format | Price | What's included |
|---|---|---|
| Pipeline audit | from $230 | build speed, secrets, manual steps, rollback; a report with a fix plan |
| Setup | $35/hour | build, tests, vulnerability scanning, deployment; estimated before work starts |
| Support | $250/month | runners, updates, failed build investigation, helping the team with releases |
Example estimates
| Task | Estimate |
|---|---|
| Pipeline for one service: image build, tests, deploy to a server | 4-8 hours |
| Staging and production environments with release approval | 4-6 hours |
| Image and dependency vulnerability scanning | 2-3 hours |
| Speeding up a slow build: caching, parallel jobs | 2-6 hours |
How the setup goes
- 1
How you release today
I map the path from commit to production: who builds, what is run by hand, where passwords are kept.
- 2
Pipeline plan
I propose stages and environments for your project. A single service on a VPS doesn't need ArgoCD.
- 3
First service
I set up the pipeline for one service and walk through the first release with the team.
- 4
Other services
I roll the scheme out to the other services through shared templates, so the configuration isn't copied around.
- 5
Handover
I document how to release, roll back and add a new service. From then on the team manages on its own.
What teams come with
Only one person knows how to release
A release is a set of commands in one developer's head. They go on vacation and the release waits.
Nobody wants to release on Friday
Every release is a risk and a rollback takes an hour. With fast rollback you can release any day.
The pipeline takes 40 minutes
Builds without caching, tests in sequence. Usually the time drops several-fold without changing tools.
Passwords are in the repository
Database and cloud keys sit in the code or in variables everyone can see. I move them to a secrets store.
GitLab CI, GitHub Actions or Woodpecker
The choice usually depends on where the code already lives:
| GitLab CI | GitHub Actions | Woodpecker CI | |
|---|---|---|---|
| Where it runs | gitlab.com or your own server | github.com, optionally your own runners | your own server, with Forgejo or Gitea |
| Strength | code, CI and registry in one place | ready-made actions for almost anything | lightweight, a small VPS is enough |
| Self-hosted | yes, there is a free edition | no, only runners | yes, open source |
| When to choose | everything must stay in-house | the code is already on GitHub | GitLab is too heavy for the team |
Pipeline logic carries over between systems, only the syntax changes. Moving just for the sake of it isn't worth it: it makes sense when you need your own server or lower costs.
What a pipeline consists of
A typical path of a change from commit to production:
- A developer opens a merge request, linters and tests run.
- After the merge, a Docker image is built and versioned with the commit hash.
- The image is scanned for known vulnerabilities:
trivy image. - The new version is deployed to staging automatically.
- After checking it, someone on the team approves the production release.
- If the service doesn't respond after the release, the pipeline restores the previous version.
You don't need all of it at once. Build, tests and deployment to one environment are enough to start; the rest is added as the team grows.
Technologies
- CI/CD
- GitLab CIGitHub ActionsWoodpecker CI
- Deployment
- ArgoCDHelmDocker ComposeAnsible
- Security
- TrivySonarQubeVault
- Infrastructure
- DockerKubernetesK3sTerraform
Case studies
ML platform: releases into an isolated network
Service updates had to be delivered not only to the cloud but also into the client's internal network, closed to the outside.
Set up builds in GitLab CI, repository mirroring into the client's network over VPN and automatic deployment from there.
Autonomous tractors: GitOps on AWS
The fleet management platform needed predictable releases to an EKS cluster.
Set up builds in CodeBuild and deployment with ArgoCD: the cluster runs exactly what is described in Git.
Why work with me
Nothing extra
I don't install ArgoCD and five environments where a 30-line pipeline will do.
Former developer
Eight years of writing code in product teams: I know which checks speed work up and which only get in the way.
All in your repository
Pipelines live next to the code. No external services that only I know about.
Self-hosted when needed
I set up your own runners and Git server if you want to stop paying for CI minutes or keep code in-house.
Frequently asked questions
How much does CI/CD setup cost? +
A pipeline for one service with build, tests and deployment to a server usually takes 4-8 hours at $35/hour. An audit of an existing pipeline starts at $230.
What is CI/CD in simple terms? +
CI is automatic building and checking of every code change. CD is automatic deployment of the checked version to the server. Together they replace a manual release with a branch merge or a button.
Does a small team need CI/CD? +
Yes, if you release more than once a month. Even for a single developer, automatic deployment saves time and removes mistakes made in manual commands.
Do you work with self-hosted GitLab? +
Yes: gitlab.com or GitLab on your server, and GitHub. If the code must stay in-house, I'll set up your own GitLab or a lightweight Forgejo and Woodpecker pair.
How do you scan images for vulnerabilities? +
Trivy in the pipeline checks the image and dependencies against a database of known vulnerabilities. Critical findings stop the release, the rest go into a report.
Can releases happen without downtime? +
Yes. In Kubernetes it's a rolling update of pods. On a regular server the new version starts next to the old one and traffic switches once it's ready.
Send a request
Tell me where the code lives, where it is deployed and how that happens today. I'll propose a pipeline and estimate it in hours.