ITAM / Servers

Servers

Keep every production VM, API host, and database server in one CMDB, cost, status, uptime, and provider metadata, so Carlos knows what runs where before maintenance windows.

Real-world scenario

Carlos Reyes · IT Admin at Bluewave Labs

Bluewave Labs runs api.workverge.ai on Hetzner, a Postgres cluster on AWS, and a staging box that nobody remembers paying for. Carlos needs one list with uptime checks enabled on production hosts before the next release.

Before you begin

  • ITAM license enabled for your organization
  • Admin or asset manager role with access to Digital Assets

Overview

Servers live under ITAM → Digital Assets → Servers. Each record tracks type, IP, provider, region, cost, and status. You can add servers manually, import a CSV from a legacy spreadsheet, or sync them from AWS, Hetzner, GCP, Azure, or Digital Ocean. Once a server is in WorkVerge, enable uptime monitoring and link it to domains and apps in the CMDB.

For example

Carlos tracks api-WorkVerge-prod (Hetzner, 52.58.x.x, API type, Active), db-postgres-primary (AWS us-east-1, Database), and staging-api-old (Inactive, pending decommission). Production hosts use 5-minute uptime checks; staging uses 30 minutes.

What you can do

Before maintenance

Set status to Maintenance on servers you are patching so uptime alerts do not page the on-call team for planned downtime. Bulk actions make this quick across a whole region.

Getting started

If you are standing up Servers for Bluewave Labs (or your org), Carlos recommends this order:

  1. Review server types so Web, Database, and API labels match how your team talks about infrastructure
  2. Add your primary API host (e.g. api.workverge.ai at its public IP) or connect a cloud provider to sync existing VMs
  3. Enable uptime monitoring on production servers with a 3- or 5-minute interval
  4. Link servers to domains in the relationship graph so blast-radius views stay accurate

How-to guides

Related articles