Servers: one fleet view across every cloud and data centre
Inventory, patch state, configuration baseline and an audited access path for every host, whether it runs in AWS, Azure, Google Cloud or a rack you own.
What is Servers?
DevOpsArk servers is the module that inventories virtual machines and bare-metal hosts across clouds and data centres, tracks their patch state and configuration baseline, and provides an audited access path to each one.
What Servers is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- Not everything is in Kubernetes, and the hosts that are not get managed by whatever the team used before.
- Patch state is unknown, so "are we affected by this advisory" takes days to answer.
- SSH access is direct, with keys distributed by hand and no session record.
- Configuration drifts because changes are made interactively and never written down.
- Hosts are created for a project and outlive it by years.
Servers discovers hosts from cloud provider APIs and from your own inventory sources, then collects their operating system, installed package set, patch level, running services, open ports and configuration state. That makes fleet-wide questions answerable in one query: which hosts are missing a specific patch, which run an end-of-life operating system, which have an unexpected listening port. Access goes through a brokered path rather than direct SSH: the session is authorised against the IAM model, recorded, and does not depend on distributing keys to individuals. Configuration is expressed as a baseline per host class, so drift is detected as a difference from the baseline rather than noticed by accident, and remediation can be applied fleet-wide with an approval step. Hosts with no recent activity and no owner are surfaced for decommissioning.
What Servers does
The 7 capabilities that make up Servers.
Cross-environment inventory
Cloud instances, on-premises virtual machines and bare metal in one list with their operating system, size, network and owner.
Patch state tracking
Installed package versions against published advisories, so exposure to a new vulnerability is a query rather than an investigation.
Configuration baselines
A declared baseline per host class, with drift reported as a specific difference rather than a general suspicion.
Brokered, recorded access
Sessions authorised through the IAM model and recorded, without distributing keys to individuals.
Host monitoring
CPU, memory, disk, network and service health collected alongside the rest of the estate rather than in a separate tool.
Decommission candidates
Hosts with no owner, no recent login and no meaningful traffic surfaced with their monthly cost.
Coordinated patching
Patch waves with maintenance windows, health verification between waves and automatic halt on failure.
How Servers fits together
Outcomes
- The non-Kubernetes half of the estate is managed on the same terms as the rest.
- Advisory exposure is answered in minutes.
- Access is auditable and does not depend on key distribution.
- Drift from baseline is a specific, fixable difference.
- Forgotten hosts are found and switched off.
Using Servers, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Discover the fleet
Hosts are enumerated from cloud APIs and your own inventory sources.
- 2Collect state
Operating system, packages, services, ports and configuration are recorded.
- 3Declare a baseline
Each host class gets a configuration baseline to be measured against.
- 4Broker access
Sessions are authorised through IAM and recorded.
- 5Patch in waves
Updates roll out per window with verification between waves.
Where teams apply Servers
Answer an advisory question
Query the fleet for hosts running the affected package version and patch them in waves.
Replace direct SSH
Move to brokered sessions authorised through IAM and recorded centrally.
Hold a configuration baseline
Declare a baseline per host class and remediate drift fleet-wide.
Retire abandoned hosts
Surface hosts with no owner and no activity, with their running cost attached.
What Servers works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Servers: frequently asked questions
The 7 questions teams ask most often before adopting Servers.
Yes. Virtual machines and bare-metal hosts across clouds and data centres appear in the same inventory as clusters, with patch state, configuration baseline, monitoring, cost and access governed the same way.
By collecting the installed package set from each host and comparing it against published advisories for that distribution. Exposure to a specific vulnerability then becomes a query over the fleet.
A difference between the declared baseline for that host class and the state actually present, usually caused by an interactive change nobody recorded. DevOpsArk reports the specific difference so it can be reverted or adopted.
Sessions are brokered rather than direct: access is authorised against the IAM model, granted for a bounded period, and recorded. Individual key distribution is not required, so offboarding is a revocation rather than a key hunt.
No. Terraform generally provisions the hosts and Ansible may configure them; DevOpsArk inventories them, tracks their state against a baseline, governs access and coordinates patching. It can trigger existing automation rather than reimplementing it.
Yes. Windows Server hosts are inventoried and patched alongside Linux hosts, with the same wave scheduling and verification.
Patches roll out in waves within a maintenance window. Between waves the health of the affected services is verified, and a failed verification halts the remaining waves rather than continuing.
See Servers against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.