Skip to the work

DevOps, without the hire.

I set up or sort out your CI/CD, logging and cloud so that the system fixes some failures by itself, and I stay on to look after it all for as long as you need. I work remotely as a contractor, two hours ahead of London and one ahead of Berlin, so most of your working day overlaps.

Available now

From four developers to several teams.

Six jobs, two ways in: if you have no DevOps person yet — I set things up and look after them myself; if you already have one — I take on a single project or work alongside them. I pick the simplest thing that works at your size; heavier tools come in only once you really need them.

Not sure where to start?

The first job can be a two-to-three-day review of your infrastructure.

  • It only needs read-only access to your cloud configuration, billing and repositories — no access to the contents of your databases or file storage, and no rights to change anything.
  • You get a written list of risks, ranked by how much they matter, each with what could happen and which job fixes it.
  • It also answers two questions: whether restoring your backups has ever been tested, and where you are overpaying for cloud.

Hourly rate: £60 in the UK, €40 for companies in Lithuania, €60 everywhere else. We can also agree a fixed price for the whole project — either way, you know the price before we start.

Six DevOps projects I take on

You don’t need all six — start with the one that hurts today.

Clouds
  • AWS
  • Google Cloud
  • DigitalOcean
  • Exoscale

Exoscale — when keeping data in Europe is not enough and the cloud company itself has to be European.

Logging and observability

Usually needed when nobody can explain an outage or the monitoring bill gets too big.

  • One place that shows what happened and when — which also gives you the facts for the first NIS2 incident report, due within 24 hours, if NIS2 applies to you or your client.
  • A small team is often fine with a managed service; I build a self-hosted stack once the bill or data requirements call for it.
  • Services are also checked from the outside, so you hear about an outage from an alert, not a customer’s email. If someone on your team can be on call, I also set up on-call schedules and escalation.
  • VictoriaMetrics
  • VictoriaLogs
  • Grafana
  • GoAlert
  • On-call schedules

CI/CD pipeline

People usually get in touch when one person knows how to deploy and their scripts live on their laptop.

  • Commit to production, usually in minutes. A failed release rolls back in one step, because database changes are planned so that a rollback does not break them.
  • The pipeline is one template: a new service joins the same path rather than copying it out of an older repository.
  • That path runs style, test, security and infrastructure checks, so nothing reaches production unchecked.
  • GitHub Actions
  • SAST/DAST
  • Reusable workflows
  • Unit and integration tests
  • Repository templates
  • Terraform validation

Infrastructure as code

It usually starts with a server nobody dares to touch because something was once fixed on it by hand.

  • Every environment can be rebuilt from a repository, and the database from continuous backups, up to the last minute before the failure. The restore is tested as part of this job.
  • Staging, production and every new environment come from the same modules — no differences that let a bug surface only in production, and nobody waits on one person to set up an environment.
  • An automatic check spots when what is running drifts from the code — before an outage does. Where it makes sense, it can also put things back to match the code on its own (self-healing), even when I am not around.
  • Terraform
  • Pulumi
  • Barman
  • Modules and templates
  • Drift detection and remediation
  • WAL backups and restore

Secrets management

What usually sets it off: a large client’s security questionnaire or an auditor asking about secrets, keys and what applications and CI/CD pipelines can access.

  • Secrets move out of repositories into one vault and are rotated — repository history does not forget the old ones. An automatic check stops new ones being committed.
  • For a small team that vault is often your cloud’s own secrets service; I run a separate one only when that is not enough.
  • Workloads in the cluster and CI/CD pipelines get short-lived identity instead of long-lived keys, with permissions only for what they actually do.
  • OpenBao
  • OIDC
  • Short-lived credentials
  • RBAC
  • Scoped GitHub Apps

Migration to Kubernetes

Worth considering once there are enough services that starting and updating them on servers has become manual work.

  • I build on your cloud’s managed Kubernetes, but even that needs looking after: new versions come out several times a year and older ones stop being supported — I keep the cluster upgraded or hand it over to your team. If something simpler is enough for you, I will say so before we start.
  • Services move one at a time while production keeps running — no big-bang switchover weekend. Databases, queues and caches go into the cluster, run by Kubernetes operators, or into your cloud’s managed services — whichever is cheaper for you once upkeep is counted. The first stage is a plan and the first service moved; the rest is agreed stage by stage.
  • A crashed service restarts itself, and when a server fails, it moves to another one — without a break if it runs as several instances; a failed database fails over to its replica, if it has one; a setting changed by hand is put back to what the repository describes (self-healing).
  • Kubernetes
  • Argo CD
  • Helm
  • ApplicationSet
  • Operators
  • GitOps
  • Docker Compose → K8s

Switching providers, with a way back

When the vendor has got more expensive or announced end of life, or when data now has to stay with a European provider.

  • Moved in parts, and every step has a way back: the old system is switched off only once the new one has been running alongside it for a while. You pay for both during that time, so it is planned for.
  • The first stage is a plan and the first part moved; the remaining parts are agreed one at a time.
  • If a database cannot move without a short cutover, that window is agreed in advance.
  • Cloud → cloud
  • Moved in parts
  • Observability swap
  • Data migration

This isn’t everything I do. Not seeing your problem, cloud or tool? Write anyway — I’ll tell you straight whether I’ve worked with it before.

How I work

You pay for the time you actually need, not for a full-time role: the contract says how much time I give you each month. No recruitment process or probation period — a contract and an invoice. I sign an NDA and a data processing agreement, and carry professional indemnity insurance. I let you know about holidays in advance.

The first job has an agreed scope and price and is planned for one to three weeks; if you are not sure where to start, it can be the two-to-three-day review. From your side it needs access and one person who makes the decisions. If you want to carry on afterwards, we carry on; if not, what has been done is yours and you owe nothing further.

If we carry on, I look after what has been built: updates and security patches (a bot proposes new versions automatically, and I check and roll them out), reviews of alerts and bills, and a test restore from backups once a quarter. When something breaks on a working day, I respond the same day, and afterwards write up briefly what happened, why, and what has been done so it does not happen again. Out of hours only by separate agreement.

No configuration living only in my head: it is all in your repository and documented, and every change goes through a pull request your people can see and review. Accounts — cloud, domain, GitHub — stay in your name, and I work through personal, two-factor-protected access you can revoke at any time. Depending on one person is a risk for you as much as for me — so where it makes sense, I also build in self-healing: some failures are detected and fixed by the system itself, without me.

Who you would be working with

I’m Linas Mackevičius, a DevOps engineer, currently based in Vilnius. You deal with me directly: the person who scopes the work is the person who does it. Here is some of what I’ve already done — it’s how I know what a growing company needs, and what a small team doesn’t need yet.

€8k → €3k

Monthly observability bill. I moved metrics and logs off a self-hosted Grafana stack onto separate VictoriaMetrics and VictoriaLogs clusters, run by Kubernetes operators and autoscaled with the load. Dashboards and alert coverage stayed intact.

Built 2, worked across 8

I built two production Kubernetes clusters of 4–6 nodes each myself and worked across eight in total. All of them are managed with Terraform. PostgreSQL, MySQL, RabbitMQ, Valkey and Ceph run on them as operator-managed services.

DigitalOcean → Exoscale

I moved services off Docker Compose onto Kubernetes on DigitalOcean with custom Helm charts, then from DigitalOcean to Exoscale.

Hundreds → 1

I consolidated hand-written Argo CD Applications into a single ApplicationSet template (Helm and Go templating), and dozens of separate GitHub Actions pipelines into one reusable workflow model.

Keys → OIDC

I centralised secrets in OpenBao and gave Kubernetes workloads short-lived identity instead of long-lived static credentials.

Backups → another cloud

I built the backup path from Google Cloud to Exoscale — for managed databases and for those running in the cluster — and tested restoring from it.

Figures from my previous role as an employed DevOps engineer (2025–2026). The employer and its client are deliberately not named.

What do you need?

Tell me which job you have in mind, or just what’s bothering you most. A few sentences are enough — no spec and no call needed. You get an answer within one working day, and a straight one: whether I’ll take it, where I’d start, what that first step costs, and whether an ongoing arrangement is worth considering. The answer is free and commits you to nothing.

info@linasplatform.com