Services

Setup or takeover, acceptance, then operation.

What a contract with us contains, in plain words. The terms themselves are provided on request.

How it starts

New deployment

In the terms: Service Setup

A new deployment, designed and built by us, accepted by you.

Architecture design delivered through the service desk within ten business days of the agreement
Installation and configuration on your physical or virtual servers, performed remotely at your location
Integration with your network and storage devices and your authentication tools
Service documentation to the scope you specify
Acceptance tests completed within an agreed deadline, counted in calendar days

Takeover of an existing deployment

In the terms: Service Takeover

An existing deployment, taken over from your previous provider or your own team.

Handover of credentials, documentation and installation sources
Analysis of the existing installation against the agreed specification
Configuration adjusted only as far as operation requires; no forced reinstall
Integration with network, storage and authentication verified
Previous provider’s access closed and credentials changed by the day of acceptance
Versions no longer supported upstream are upgraded after takeover, within regular maintenance

Acceptance

A setup or takeover is complete when the acceptance tests in the service specification pass. If none are specified, we propose tests that verify the service fulfils its purpose.
We run the tests, demonstrate the result and deliver an acceptance protocol. You have three business days to approve it, or to state the specific defects that prevent basic functionality.
Defects found after acceptance are handled as incidents within operation, under the service levels below.

One instance at a time

Setup, takeover and operation are always agreed for a single service instance: one deployment with its own control plane, configuration and data. A second cluster of the same software is a second instance, agreed and priced separately.

All work is performed remotely on your own physical or virtual servers, at the location named in the service specification. Hardware, firmware, the operating system on physical servers, virtual servers and data migration are yours to provide unless agreed otherwise.

What you get every month

Operation is one activity in the contract, not a menu. All four parts below are included for every platform; you choose only the service level.

Software Build Management

OpenStack services only

Your own build of the OpenStack source, maintained in your repositories.

Your git repository and container registry hold the build; nothing proprietary sits between you and upstream
Each new upstream major release tested in our environment, patched and built for you
Your earlier patches merged forward into every new version
Fixes pushed upstream, so the difference maintained on your behalf shrinks over time
Pull requests from your team reviewed and merged where compatible

Software Deployment Management

Upgrades that remain upgrades rather than becoming migration projects.

New major versions installed at least once a year; minor versions and patches as published
Performed without downtime where possible, otherwise in an agreed maintenance window
Regular window once a month, at most four hours, outside your business hours where needed
Reconfiguration after servers are added or removed and after hardware maintenance
Service documentation kept current

Incident Management

A service desk staffed by engineers who work at source-code level.

Service desk for reporting incidents in four severity categories, A to D
Response and resolution times guaranteed per category, in 24/7 or 8/5 mode
Root cause established for every incident: usage, environment, source code or configuration
Source-code errors fixed by a patch we write or procure, then built and deployed
A workaround restores service first; the root cause is still eliminated afterwards

Software Operations

The platform is watched, tuned and kept safe, not merely kept up.

Monitoring and log output analysed on a regular cycle
Ongoing capacity management of the resources the software runs on
Configuration changes designed for performance and resource optimisation
Regular automated vulnerability scanning, with remediation
Regular backups of virtual servers and user data for platform services

General Terms and Conditions for the Provision of Managed Services, version 4.6, effective 1 July 2026. Provided on request.

Service levels

Response and resolution times, written into the contract.

Two service modes. Incidents are reported through the service desk in one of four categories, and the guaranteed times for each are below. They apply to every platform we operate.

Maximum response and resolution times by incident category and service mode
Incident category	Continuous 24/7		Standard 8/5
Incident category	Response	Resolution	Response	Resolution
A Critical The service is completely inoperable, or cannot fulfil its purpose at all	15 min	1 h	30 min	2 h
B High The service fulfils its purpose only to a limited extent	1 h	4 h	2 h	8 h
C Medium Functionality is reduced, but the service still fulfils its purpose	4 h	16 h	4 h	16 h
D Low Fully functional, or reduced only negligibly	12 h	48 h	12 h	48 h

Response time runs from your report until we start working on it; resolution time until we tell you it is fixed. Both count only during standby hours.
In Continuous mode, critical and high incidents (A and B) are worked around the clock, every calendar day. Medium and low incidents (C and D) are worked 9:00 to 17:00 Central European Time on Czech business days, which is also the standby window for every category in Standard mode.
An incident counts as resolved once a workaround restores the service. We remain obliged to eliminate the root cause.
You categorise the incident when reporting it; we confirm or adjust the category, and every step is recorded in the service desk.

Article 6.11 of the General Terms and Conditions, version 4.6, effective 1 July 2026.

Software we operate

Every platform we operate, and how it is deployed.

Every platform below runs under the same contract and the same response times. Each platform, and each OpenStack component, is a separate item in the terms, so a contract can cover one database cluster or a whole cloud.

Service Catalogue version 4.6, effective 1 July 2026.

Infrastructure as a service

The OpenStack platform and Ceph storage, deployed directly on your physical servers. The OpenStack services share one control plane — HA database, message broker, load balancers, monitoring and central logging — deployed once for the whole environment.

Infrastructure

OpenStack deployed with Kolla-Ansible, Ceph with cephadm

OpenStack

Sixteen components on one control plane, from compute and networking to bare metal; each contracted separately
OpenStack: the sixteen components →
Ceph

Block (RBD), object (S3 and Swift) and file (CephFS) storage on commodity servers

Platform as a service

Application platforms, databases, messaging, search, identity and delivery tooling, operated on your virtual servers or inside a Kubernetes cluster. Every service is deployed highly available by default, and backups of user data are part of operation.

VMs: Linux virtual servers — Ansible, systemd, HAProxy
K8s: Kubernetes cluster — operators or Helm charts

Container platforms

Upstream Kubernetes, K3s and multi-cluster management

Kubernetes VMs

Upstream Kubernetes deployed with Kubespray: containerd, Calico, Gateway API, Ceph CSI
K3s VMs

Lightweight certified Kubernetes for smaller sites, edge and test environments
Rancher K8s

Central management of many Kubernetes clusters, access control, Fleet GitOps

Databases

Clustered, with automatic failover and continuous backups

PostgreSQL VMs K8s

Patroni or CloudNativePG: automatic failover, pooling, continuous backups, point-in-time recovery
MySQL VMs K8s

InnoDB Cluster with Group Replication, MySQL Router, Percona XtraBackup
MariaDB VMs K8s

Galera multi-master cluster fronted by MaxScale, mariabackup
Redis VMs K8s

Sentinel or Cluster mode; Valkey supported as an alternative

Messaging and streaming

Clustered brokers with replicated queues and topics

RabbitMQ VMs K8s

Clustered broker with quorum queues; AMQP, MQTT and STOMP
Apache Kafka VMs K8s

KRaft mode without ZooKeeper, Kafka Connect, MirrorMaker 2; Strimzi on Kubernetes
Confluent Kafka VMs K8s

Confluent Platform: Schema Registry, REST Proxy, ksqlDB and connectors

Search and analytics

Multi-node clusters with replicated shards

Elastic VMs K8s

Elasticsearch, Kibana, Beats and Elastic Agent for logging and search; ECK on Kubernetes
OpenSearch VMs K8s

Apache 2.0 fork of Elasticsearch and Kibana with built-in security

Identity and secrets

Single sign-on and secrets management

Keycloak VMs K8s

Single sign-on over OpenID Connect, OAuth 2.0 and SAML; LDAP and Active Directory federation
HashiCorp Vault VMs K8s

Secrets, dynamic credentials, internal PKI, encryption as a service

Development and delivery

Source, registry, GitOps and error tracking

GitLab VMs K8s

Git repositories, merge requests, CI/CD with runners, package and container registry
Harbor VMs K8s

Container image and Helm chart registry with replication, proxy cache and scanning
Argo CD K8s

GitOps continuous delivery to Kubernetes: drift detection, multi-cluster
Sentry VMs K8s

Self-hosted error tracking, performance monitoring and profiling

Security

Scanning and runtime protection for containers

Trivy VMs K8s

Vulnerability, misconfiguration and secret scanning; works without internet access
NeuVector VMs K8s

Runtime container security: anomaly blocking, network policies, admission control

All software in the catalogue is open source published by third parties; Ultimum is not its author. Where a publisher applies its own licence terms — Confluent, Elastic, HashiCorp Vault, Redis, GitLab — your use of the service must comply with them.
The Service Catalogue lists, for each platform, the software deployed, its architecture, its interfaces and its dependencies. We provide it on request.