DevOps as a Service: CI/CD in Romania

From commit to production, with no manual steps

A good pipeline does the same things in the same order every time. We build the image, run the tests, check the dependencies and the configuration, sign the artefact, then promote it to staging and production through GitOps. Nobody copies files onto a server and nobody keeps secrets in the repository. If your team works on several branches, we add protection on the main branch and required checks, so a merge cannot skip the tests.

• A pipeline defined in the repository, versioned together with the application
• Tests, linting and dependency checks as mandatory gates
• Secrets kept in a vault and injected at runtime, never in code
• Promotion between environments through GitOps, with a history of every change

Best practices we apply to pipelines

The difference between a pipeline that helps and one that gets in the way is a handful of rules we do not negotiate. We apply them on every delivery and leave them in your team's documentation, with a runbook for every alert we configure. The aim is easy to state and hard to reach: a release should be boring, and an alert at three in the morning should mean a customer really has a problem.

• Pipeline as code, with branch protection and test gates
• Signed artefacts and a software bill of materials (SBOM) on every build
• Secrets outside the repository, in a vault, with documented rotation
• Delivery through GitOps: the desired state lives in git, not in hand-typed commands
• SLOs with error budgets, and alerts routed to the right person

Observability that gets used

A dashboard nobody opens is not observability. We set up metrics with Prometheus, central logs with Loki and, where needed, request tracing with Tempo, then build only the panels your team opens during an incident: requests, errors, response times, saturation. Alerts start from availability targets with an error budget, so you do not end up ignoring notifications out of habit.

• Metrics, logs and request traces in one place
• Panels built around the four golden signals
• A runbook for every alert, with verified steps

How it uses your included hours

Building the pipeline and the monitoring comes out of the hours in your plan: 1–8 h a month on VPS, 5–10 h on dedicated servers depending on the plan, 10 h on GPU servers, and 1 h from cPanel Advanced upwards. You request the work in the client panel under DevOps Services and propose the deadline. Because hours reset each calendar month, we usually split the work: the pipeline first, then monitoring and runbooks. Above the quota, extra hours are billed separately.

How we work

1. Request it in the panel

   Open a request under DevOps Services and tell us where the code lives, how you release today and what would help you most this month.

2. We scope the work

   We agree the pipeline stages, the environments and the availability targets, then split the work across the hours available in your allowance.

3. We build it and run it in parallel

   We build the pipeline and run it next to your old process until it earns trust, then add the metrics, the logs and the alerts.

4. Handover with runbooks

   You receive the pipeline in your repository, the exported dashboards, the alert definitions and the runbooks, so your team can react without us.

Use cases

Technology stack

• GitHub Actions
• GitLab CI
• Argo CD
• Prometheus
• Grafana
• Loki
• Tempo
• Alertmanager
• Renovate

Frequently asked questions

• What does DevOps as a service include?

  The delivery pipeline, infrastructure automation, monitoring and alerting, incident response and the work that removes recurring causes. With us it comes out of the monthly hours in your hosting plan, with runbooks and documentation so your own team can take over at any point.

• What is CI/CD, and why does a small team need it?

  CI builds and tests every change automatically, and CD moves it through the environments without manual steps. For a small team the value is larger: you stop depending on the one person who knows how to deploy, and you can release often with low risk.

• How do you monitor infrastructure with Prometheus and Grafana?

  Prometheus collects metrics from servers, containers and the application, Grafana draws them, and Alertmanager sends notifications. We add Loki for logs, so during an incident you see the graph and the log lines side by side, with no SSH session needed.

• GitLab CI or GitHub Actions?

  We choose by where your code lives. GitHub Actions is quicker to start and has a large ecosystem of ready-made actions. GitLab CI gives finer control over your own runners and suits teams hosting their own instance. The pipeline stays portable either way.

• Can you host our CI runners?

  Yes. We can run self-hosted runners on a VPS or dedicated server, isolated from production, with caching and clean-up configured. That keeps build minutes predictable and your source code and artefacts on EU infrastructure.

• What happens when I go over my included hours?

  The work continues. Hours above the monthly quota are accepted and billed separately, and you can see what was used in the panel. When we plan ahead, we usually fit the big steps inside the quota and leave small adjustments for the next month.