Skip to content

Co-Managed DevOps

DevOpsCentral's Co-Managed service is for teams that want the control of sovereign infrastructure without the overhead of day-to-day platform operations. You focus on your application and your customers; DevOpsCentral handles the underlying operations, monitoring, and maintenance within a defined scope.

This page covers the operating model, tier structure, Ops Request policy, and how responsibilities are shared.

Audience

Co-Managed DevOps is designed for:

  • Growing SaaS providers with limited in-house ops headcount
  • Teams migrating from hyperscalers that want to reduce operational overhead
  • Organisations with compliance requirements that need sovereignty but not a full in-house platform team
  • Startups and scale-ups that want predictable operations support as they grow

Operating Model

DevOpsCentral provides a managed Kubernetes platform with ongoing operational care. You retain full ownership of your application code, architecture decisions, and release approvals. DevOpsCentral handles the platform layer: infrastructure health, OS and Kubernetes patching, monitoring, backups, and incident triage within the agreed scope.

The exact boundary is defined by your chosen tier and any signed order or SLA.

Managed Boundary

DevOpsCentral manages the platform up to and including the Kubernetes control plane and worker node OS. Your team retains responsibility for:

  • Application code and configuration
  • Database schema design, queries, and data integrity
  • Release management and deployment approval
  • Access management and security decisions for your team
  • Content stored in the platform

Higher tiers extend the managed boundary into application health monitoring, CI/CD pipeline maintenance, and advanced observability.

The service covers one agreed managed platform. Your signed proposal or order identifies the environments, clusters, databases, and CI/CD pipelines included.

Co-Managed Tiers

Tiers are cumulative — each includes everything from the tiers below it.

Basic Pro Scale Enterprise
Best for Stable production Growing SaaS Business-critical Custom requirements
Response (business hours) 4h 1h — Custom
24/7 P1 response — — 1h acknowledge Custom
Monthly Ops Requests 1 5 10 Custom
Infrastructure health Custom
Application health monitoring — Custom
Daily backups Custom
Backup restore verification — Custom
OS + managed K8s security patching Custom
CI/CD maintenance and tuning — Custom
Custom metrics and priority alerts — — Custom
DR planning and recovery testing — — Custom
Advanced orchestration — — Custom

Service plan pricing:

Tier Monthly Price (EUR)
Basic 299
Pro 599
Scale 1,499
Enterprise Custom

Infrastructure usage (compute, block storage, object storage, and other metered resources) is billed separately at standard rates. Bandwidth is included subject to our fair-use policy. See Pricing Explained for the full invoice breakdown.

Scale tier is subject to platform qualification and a minimum infrastructure commitment defined in your proposal or order. Infrastructure usage is billed separately — the service fee does not include compute, storage, or other metered resources.

Ops Requests

An Ops Request is the unit of customer-requested operational work within the Co-Managed service.

What Counts as One Ops Request

One Ops Request is one clearly stated, accepted operational outcome on the existing managed platform. It is counted by outcome, not by hours. Most accepted outcomes take under one hour, but some can take longer and still remain a single request.

Examples:

  • Install and configure Valkey on the cluster
  • Configure CloudNativePG for high availability
  • Add or configure an ingress for an application
  • Adjust resource limits or autoscaling settings
  • Set up a monitoring check or alert
  • Update an existing CI/CD deployment flow

What Does Not Consume Requests

  • Defect correction: If DevOpsCentral delivers work that has a defect, correcting it does not consume a request.
  • Routine care: Monitoring, patching, provider-initiated maintenance, and incident handling within the agreed scope are included in the service plan.

Policy

  • Unused requests do not roll over to the next month.
  • Extra requests beyond the tier allowance require an approved separate quote.
  • Requests must be submitted through the agreed channel and clearly state the desired outcome. DevOpsCentral will confirm acceptance or request clarification before work begins.

What Is Quoted Separately

The following are not covered by Ops Requests and require a separate quote:

  • New system design and deployment (greenfield projects)
  • Migration of existing workloads from other providers
  • Application development or custom software
  • Major architecture redesign
  • Any work outside the agreed managed platform boundary

Scope Review for Material Additions

Material additions to the managed scope — including systems delivered through separately quoted projects — trigger a scope and subscription review before entering routine managed care. Any change to the recurring service fee must be agreed first.

Once accepted within the revised scope, routine monitoring, patching, provider-initiated maintenance, and incident handling for the additions are included. Later customer-requested changes consume Ops Requests.

Incident Response and SLA Interpretation

Tier Hours P1 Response
Basic Business hours, 4h response Standard incident handling
Pro Business hours, 1h response Standard incident handling
Scale 24/7, P1 1h acknowledge

Scale 24/7 P1 response means DevOpsCentral will acknowledge, begin triage, and attempt remediation for P1 production incidents within the agreed managed-platform boundary. Response is not a guaranteed resolution time.

SLA Boundary

Response targets apply to issues within the managed boundary as defined by the tier and any signed order/SLA. Issues outside that boundary (for example, application code bugs or customer-side configuration) are handled on a reasonable-effort basis.

Your signed order or SLA controls the exact:

  • Business hours and timezone
  • Managed scope and exclusions
  • Severity definitions and contact paths
  • RPO and RTO targets
  • Data retention periods
  • Platform limits

Backup and DR Overview

Tier Daily Backups Restore Verification DR Planning
Basic — —
Pro —
Scale

Exact RPO, RTO, and retention depend on the signed order or SLA.

Backup restore verification and DR exercise frequencies are agreed in the signed order or SLA.

Customer Responsibilities

Even with Co-Managed service, you remain responsible for:

  • Application code — development, testing, deployment, and bug fixes
  • Database schema and queries — schema design, query optimisation, data integrity
  • Access control — who has access to your environments and applications
  • Data and content — what you store in the platform, including compliance with applicable law
  • Release approval — when and what you deploy
  • Security decisions — application-level security, secrets management for your code

See the Responsibility Model for a detailed matrix.

Contract Precedence

If there is any conflict between this documentation and your signed order, proposal, or SLA, the signed document takes precedence. Published price changes do not automatically alter existing signed agreements — the signed contract controls. This page describes the standard offering; custom terms are defined in your agreement.

FAQ

What happens if I use all my Ops Requests for the month?

Extra requests beyond your tier allowance require an approved separate quote. Unused requests do not roll over.

What if an accepted Ops Request takes longer than expected?

Ops Requests are counted by outcome, not hours. An accepted outcome that takes longer than an hour is still one request, as long as it remains a single clearly stated outcome.

Can I upgrade my tier mid-month?

Yes. Contact your account team. The new pricing applies from the next billing cycle or as agreed.

What is included in "routine care"?

Routine care covers ongoing platform operations: infrastructure health monitoring, OS and managed Kubernetes security patching, provider-initiated maintenance, and incident handling within the agreed scope. It does not cover customer-requested changes (those use Ops Requests).

Is the underlying infrastructure different from Self-Managed?

No. Both models run on the same sovereign infrastructure in Romania. The difference is the level of operational support.

Operational support for your sovereign infrastructure