OSSeva Operate
Managed open source operations.
We hold the pager so your team can build.
OSSeva Operate is a managed service for the open source databases, message brokers and runtimes you run yourself: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, RabbitMQ, Kafka and more. You get 24/7 monitoring, 15-minute P1 response and named engineers who know your system, on your servers, in your cloud account or on your Kubernetes clusters.
Trusted globally by enterprises
What OSSeva Operate runs
Operate covers the same technologies as our patch and support tiers, so the cluster we operate is also the cluster we patch. The main databases and brokers are below. Each link opens the versions we cover and the full scope of each tier. For databases, see also remote DBA services and managed database services.
Databases
Managed PostgreSQL
Replication and failover monitoring around the clock, Patroni, repmgr and DCS quorum checks, VACUUM and analyze tuning, and point-in-time recovery tests. Patched builds for 11, 12 and 13 past community end of life.
Managed MySQL
Replication lag, failover and backup monitoring, with rolling upgrades carried out one replica at a time. Signed Community Edition builds for 5.7 and 8.0, and support for 8.4 and 9.7 LTS.
Managed MariaDB
Galera, replication and backup monitoring, and rolling upgrades done node by node. Patched builds for 10.4, 10.5 and 10.6 next to every current LTS line.
Managed MongoDB
Replica set and cluster monitoring, a named MongoDB engineer, and major version upgrades that we execute. Covers self-managed 4.2, 4.4, 5.0 and 6.0.
Managed Redis
Instance and cluster health monitoring, memory and eviction policy alerts, and replication lag tracking for patched Redis 6.2 and 7.0.
Managed Elasticsearch
Cluster health monitoring for self-managed search, patched 7.10.2 and 7.17 builds, and executed migrations to 8.x or OpenSearch.
Messaging and streaming
Managed RabbitMQ
Monitoring and alerting at any hour, runbooks written for your clusters, and an escalation path to RabbitMQ core contributors. Patched 3.8 through 4.2, plus the current 4.3 line and the Erlang/OTP runtime underneath.
Managed Kafka
Broker and consumer-lag monitoring, capacity planning and scaling, and operational support for Kafka Streams and Connect. Patched 2.8 through 3.9, and 4.x in KRaft mode.
Managed ActiveMQ Artemis
Broker health monitoring, queue depth and consumer lag alerts, and a named senior Artemis engineer on your account.
Managed Apache Pulsar
Broker, bookie and ZooKeeper monitoring, backlog alerts, and support for Pulsar Functions and IO connectors.
Managed ZooKeeper
Quorum, latency and znode count monitoring, with snapshot and transaction log retention handled for you.
Managed ClickHouse
Replication queue, merge and Keeper quorum monitoring, with release upgrades rolled out shard by shard.
Application runtimes are covered too: Spring Boot, Spring Framework, Apache Tomcat, Node.js, .NET, Erlang/OTP. For Flink, NiFi, Hadoop, Solr, Ignite, Hazelcast, etcd, Consul and the rest, see every technology we support.
What's included
Where it runs: your infrastructure
Operate has no platform prerequisite. You do not adopt a new distribution or move data into our account. Your team keeps ownership of the infrastructure and its access, and we take on the operational work.
Your data centre
Bare metal and virtual machines in your own facilities. Patched builds ship as packages and tarballs, so the way you install software stays the same.
Your cloud account
Instances inside your own cloud account and VPC, with whichever provider you use. We work through the access you grant, and the account and its data stay yours.
Your Kubernetes clusters
Clusters you run on premises or in the cloud. Patched builds are also published as container images and Helm charts, so operators and GitOps pipelines keep working.
How onboarding works
We do not take the pager on day one. Monitoring and runbooks are in place for your clusters before we go live, so every alert has a remediation path from the first night on call.
Discovery & Inventory
We audit your existing deployment: cluster topology, version matrix, monitoring gaps, runbook status. Output: a gap analysis and onboarding scope.
Runbook Authoring
Our engineers write the runbooks for your environment — not generic templates. Every alert has a remediation path before we go live.
Steady-State Operations
24/7 monitoring, proactive alerting, and incident response on your infrastructure. You retain data sovereignty; we own the operational layer.
Quarterly Reviews & Upgrade Planning
Every quarter: a structured review of incidents, capacity trends, the version plan, and architectural improvements. No surprises at renewal.
SLA targets
Contractual response and resolution targets by incident priority.
| Priority | Definition | Response | Resolution target |
|---|---|---|---|
| P1 | Production down / data loss risk | 15 minutes | 4 hours |
| P2 | Significant degradation, no immediate outage | 1 hour | 8 hours |
| P3 | Non-critical issue, workaround available | 4 hours | 2 business days |
| P4 | Question, advisory, enhancement request | 1 business day | Scheduled sprint |
Security patching under Operate
OSSeva Operate patches Critical CVEs (CVSS ≥ 9.0) within 48 hours and High within 7 days.
Operate includes everything in Patch and Assure, so fixes arrive as signed builds of the version you already run, end-of-life lines included. Our engineers then roll them out in your maintenance windows, cluster by cluster, with the same runbooks they use for every other change.
How Operate differs from a cloud provider's managed service
A cloud provider's managed service
The provider runs the database or broker inside its own service, and you use it through their console and API. Infrastructure, backups and failover are handled for you, on the engine versions and settings that service offers. Version support follows the provider's lifecycle, and leaving later means a migration.
OSSeva Operate
We run the self-managed clusters you already have, wherever you chose to put them. You keep the community binaries, full access and the configuration you need. End-of-life versions stay patched while you plan upgrades, and one contract covers databases, brokers and runtimes together.
If you would rather not own servers at all, and your workloads fit the versions and options a cloud provider offers, its managed service is often the simpler choice. Operate suits teams that want to keep control of where and how their clusters run, or that run versions and technologies a managed service does not offer.
Pricing: per cluster
OSSeva Operate is priced per cluster. The clusters in scope and the technologies on them set the quote, and adding a technology later goes onto the same contract and renewal date. For databases, the database support cost calculator compares your current spend using your own figures. Book a discovery call for a quote.
What does 24/7 incident response mean in OSSeva Operate?
OSSeva Operate customers have access to an on-call engineering team 24 hours a day, 7 days a week, including weekends and holidays. P1 incidents (production down or data loss risk) receive a 15-minute response SLA with a 4-hour resolution target. P2 incidents (significant degradation without an outage) receive a 1-hour response SLA. Every incident gets a post-mortem and a prevention plan.
What infrastructure monitoring does OSSeva provide?
OSSeva Operate includes deployment of a monitoring stack (Prometheus + Grafana or integration with your existing observability platform) with OSSeva-maintained dashboards and alerting rules for the covered technologies. For RabbitMQ, this includes queue depth, memory headroom, Erlang process counts, and federation link health. For Kafka, it covers consumer lag, partition leader balance, and broker JVM metrics.
Can OSSeva run our OSS infrastructure entirely on our behalf?
Yes. OSSeva Operate can include full operational ownership — we handle patching, monitoring, incident response, capacity planning, and configuration management while your team retains infrastructure ownership and access. This model is common for regulated enterprises that want strong vendor accountability without building an in-house OSS platform engineering team.
Can OSSeva take over operations without a migration?
Yes. Support takeover with no migration is the normal starting point: you keep the community binaries, data and topology you run today, and we take over monitoring, incident response and patching once onboarding is complete. Patched OSSeva builds replace your binaries later, on your schedule.
Does OSSeva Operate cover end-of-life versions?
Yes. Operate includes everything in Patch and Assure, so we run clusters on versions upstream no longer fixes, such as PostgreSQL 11 to 13, MySQL 5.7 and 8.0, MariaDB 10.4 to 10.6, Kafka 2.8 to 3.9 and RabbitMQ 3.8 to 4.2. The technology pages list the exact versions for each project.
How is OSSeva Operate different from a cloud provider's managed database service?
A cloud provider runs the database inside its own service, on the versions and settings it offers. OSSeva Operate runs the self-managed clusters you keep in your data centre, your cloud account or your Kubernetes clusters, with the community binaries and full access left with you. If you want no servers to own and your workloads fit a provider's options, its managed service may be the better fit.
How is OSSeva Operate priced?
OSSeva Operate is priced per cluster. The clusters in scope and the technologies on them set the quote, and every technology sits on one contract with one renewal date. Book a discovery call for a quote.
Get a quote
Book a discovery call for a quote.
15-minute discovery call. We review your stack, identify monitoring gaps, and plan the onboarding. No commitment required.
Prefer to talk or read more first?