# CloudOps Platform — full documentation > Every page of the public CloudOps documentation in one file, generated from the > same source as https://cloud-ops.io/docs. Index: https://cloud-ops.io/llms.txt --- # Getting started Source: https://cloud-ops.io/docs/getting-started · Section: Start here > What CloudOps is, and the path from an empty account to your first running server. ## What is CloudOps? CloudOps is an infrastructure management platform that gives real hardware the ergonomics of a public cloud. You bring bare-metal servers — or rent them from the built-in marketplace — and the platform turns them into a private cloud: virtual machines, databases, storage volumes, and networks that you provision from a console, a REST API, or Terraform. Everything the platform does to your hardware runs as a tracked, auditable automation job, so there are no snowflake servers and no mystery state. ## 1. Create your organization Sign in and create an organization. Organizations own everything — tenants, servers, billing — and support multiple members with role-based access (owner, admin, member, viewer, billing). Invite your team from the organization settings page. ## 2. Connect or rent hardware You have two ways to get capacity: - **Bring your own.** Register your bare-metal servers and let the platform network-boot and image them. See [Bare-metal provisioning](https://cloud-ops.io/docs/provisioning). - **Rent from the marketplace.** Browse verified servers listed by independent operators and rent them in a few clicks. Rented servers behave exactly like your own. The marketplace is in early access, so listings are few or none for now. See [Marketplace](https://cloud-ops.io/docs/marketplace). ## 3. Provision your first workload From the console, create a virtual machine on any of your servers: pick vCPUs, memory, disk, and an OS image, and the platform handles the rest — including networking and a browser-based console for when you need hands on the keyboard. ## 4. Codify it Once you like what you have, describe it in Terraform so it lives in version control. The [Automation & API](https://cloud-ops.io/docs/automation-api) page covers API tokens and the Terraform provider. --- # Compute Source: https://cloud-ops.io/docs/compute · Section: Platform > Bare-metal servers and KVM virtual machines, Linux or Windows, with a browser console. ## Server types CloudOps manages two kinds of compute: **bare-metal servers** (physical machines you own or rent) and **virtual machines** (KVM guests that run on those servers). Both appear side by side in the console with the same lifecycle controls. ## Creating a virtual machine Pick a host server, then choose the VM's shape: vCPUs, memory, disk size, OS image, and network attachment. The platform creates the VM, wires up its networking, and reports its addresses back to the console within minutes. - Linux images boot with cloud-init and your SSH keys pre-installed. - Windows VMs are cloned from a prepared golden image, with an administrator account you set at creation time. ## Browser console Every VM has a graphical console that runs directly in the browser — no VPN or local client needed. Use it for OS installers, rescue work, or anything else that happens before SSH/RDP is available. ## Lifecycle Start, stop, reboot, and delete from the console or API. Deleting a VM tears down the real resources on the host — disks, network attachments, and console sessions — not just the database record. --- # Managed databases Source: https://cloud-ops.io/docs/databases · Section: Platform > Preview: database instances with provisioning and monitoring handled by the platform. ## Overview Managed databases are in preview. They take the setup work out of running a data store: the platform provisions the instance on your capacity, configures it with sane defaults, and monitors its health. ## Engines - **PostgreSQL** — general-purpose relational workhorse. - **MariaDB** — MySQL-compatible, for the software that expects MySQL. - **Valkey** — Redis-compatible in-memory store, without the licensing questions. ## What the platform handles - Provisioning and initial configuration on the server you choose. - Health monitoring and status in the console. Automated backups are not available yet. Until they are, keep your own backups of any data you can't afford to lose. You keep full network control: database instances live inside your private network and are reachable according to your security groups. --- # Storage Source: https://cloud-ops.io/docs/storage · Section: Platform > Block volumes with snapshots, plus S3-compatible object storage. ## Block storage Block volumes are ZFS-backed and attach to your VMs like any disk. They can be created, attached, detached, resized, and deleted independently of the VMs that use them — including attaching across hosts. - **Snapshots** — point-in-time copies you can roll back to or clone from. ## Object storage S3-compatible object storage for backups, artifacts, images, and static assets. Create buckets, issue scoped access keys, and point any S3 client or SDK at your endpoint. ## Storage policies Policies let you set defaults — like snapshot schedules and retention — once, and have the platform apply them to every volume that matches. --- # Networking Source: https://cloud-ops.io/docs/networking · Section: Platform > Private networks, security groups, an encrypted overlay network, and site-to-site VPN. ## Private networks Servers and VMs get private addresses on your tenant network. Management traffic and workload traffic are kept separate, and nothing is exposed publicly unless you choose to expose it. ## Security groups Security groups work the way you expect from a public cloud: stateful ingress/egress rules attached to servers and VMs, enforced on the hosts themselves. Rules follow the instance — moving or recreating a VM keeps its firewall posture. ## Encrypted overlay Hosts and VMs that can reach your tenant's lighthouse join an encrypted overlay network and reach each other on stable private addresses. Today the lighthouse is reachable only from inside the CloudOps network, so a host at another site cannot join the overlay yet. To connect other sites, use a site-to-site VPN. ## Site-to-site VPN Managed IPsec VPN gateways connect your CloudOps networks to external sites — an office network, another datacenter, or a cloud VPC — with connection status and health visible in the console. --- # Bare-metal provisioning Source: https://cloud-ops.io/docs/provisioning · Section: Platform > Network-boot and image physical servers straight from the platform. ## How it works Point a physical server at the network and boot it: the platform's PXE service takes over, loads the installer for the OS template you chose, and reports progress back to the console. No USB sticks, no KVM cart. ## Unattended and interactive modes - **Unattended** — the OS installs itself from an autoinstall profile: disk layout, users, SSH keys, and packages are all pre-answered. Ideal for fleets. - **Interactive** — the standard installer UI over the network, for one-off or unusual builds. ## Power control Servers with a BMC (iLO, iDRAC, generic IPMI) can be powered on, off, and rebooted from the console, so the whole install cycle can run without touching the machine. ## Virtual machines too The same install pipeline works for VMs, which is handy for testing an autoinstall profile before pointing it at real hardware. --- # Automation & API Source: https://cloud-ops.io/docs/automation-api · Section: Developers > Auditable jobs, the REST API, API tokens, and the official Terraform provider. ## Jobs: how changes happen Every mutation — creating a VM, applying a security group, attaching a volume — runs as an automation job with a full log. Jobs are visible in the console as they run, and their history is your audit trail: what changed, when, and by whom. ## API tokens Create API tokens from your account settings. Tokens are scoped by role — a token can never do more than the user who created it — and can be revoked at any time. ``` curl -H "Authorization: Bearer $CLOUDOPS_TOKEN" \ https:///api/v1/servers ``` ## Terraform provider The official provider lets you manage CloudOps resources declaratively — servers, virtual machines, SSH keys, security groups, storage, databases, and networking. It is not on the public Terraform Registry yet: install it from our release downloads (the Developers page in your organization console has the steps) and reference it by its full source address. ``` terraform { required_providers { cloudops = { source = "cloud-ops.io/cloud-ops/cloudops" } } } resource "cloudops_virtual_machine" "web" { name = "web-01" vcpus = 4 ram_mb = 8192 disk_gb = 80 os_image = "ubuntu-24.04" } ``` Console, API, and Terraform are three doors into the same control plane — anything you build in one is visible in the others. Some things are console-only for now: members, roles, and access are managed in the browser. --- # Marketplace Source: https://cloud-ops.io/docs/marketplace · Section: Marketplace > Early access: rent bare metal from independent operators, or list your own idle hardware. **The marketplace is in early access.** Provider payouts through Stripe Connect are not open yet, so listings are few or none for now. ## Renting capacity The marketplace lists bare-metal servers offered by independent operators. Every listing shows the hardware spec and price; unreachable machines are automatically paused, so what you can browse is what you can actually rent. Once rented, a server joins your account like any other: same console, same API, same automation, same security groups. A rented server is the operator's own machine. When a rental ends, the platform deletes the renter's user account on it and shreds that account's home directory before the server can be rented again. Other storage on the machine is not wiped, so encrypt anything sensitive you keep there. ## Providing capacity Have idle hardware? List it. You set the price; the platform handles provisioning, tenant isolation, and billing. Payouts will go through Stripe Connect; provider onboarding for it is not open yet. Your listing pauses automatically if the machine becomes unreachable, and relists when it recovers. ## Billing Marketplace charges run through the platform's billing system with an itemized ledger, so both sides can always see exactly what was charged and why. --- # Hardware health Source: https://cloud-ops.io/docs/hardware-health · Section: Platform > How CloudOps reads power supplies, fans, memory, drives and the event log from your servers’ management controllers. ## What it does CloudOps reads fault data straight from the baseboard management controller (BMC) of each bare-metal server and shows it as plain findings on your dashboard, next to everything else you already watch. It covers power supplies and redundancy, fans and cooling, temperature, memory and ECC, drives and RAID, chassis intrusion, and the controller’s own event log. It works across vendors: Dell iDRAC, HPE iLO, Supermicro, or any machine that speaks IPMI or Redfish. ## Read-only The check reads the event log, sensors and component status. It never powers a machine on or off, changes a setting, or clears a log. ## Setting it up - Open a bare-metal server in the console. - Add the address and credentials of its management controller. - Press **Check now** to read it straight away. Every server with a controller on file is then checked on a schedule, once an hour. Press **Check now** at any time, for example after a callout or before a maintenance window. ## What you see Repeated log lines are collapsed into one finding in plain language, with what to do about it. An old event is shown with its age rather than raised as a live emergency. A full event log is reported as such, because a full log stops recording silently and the gap would otherwise go unnoticed. --- # Security & access Source: https://cloud-ops.io/docs/security · Section: Security > Tenant isolation, organizations and RBAC, Google sign-in, encryption, and the audit trail. ## Tenant isolation Every tenant runs its own isolated stack — separate namespaces, databases, and networks. There is no shared blast radius between tenants. That isolation is between tenants, not from marketplace operators: a rented server is the operator's own machine, and the operator can still reach it. Encrypt anything sensitive you keep on rented hardware. ## Organizations & roles Access is organized around organizations with five roles: - **Owner** — full control, including billing and deletion. - **Admin** — manage infrastructure and members. - **Member** — day-to-day infrastructure work. - **Viewer** — read-only access. - **Billing** — invoices and payment methods only. API tokens inherit these limits: a token is always capped at the role of the user who created it. ## Sign-in You sign in with a Google account, through the platform's identity provider, so access can be centrally granted — and centrally revoked. SAML and other identity providers are not supported yet. ## Encryption Cross-site traffic rides an encrypted overlay network, and credentials such as SSH keys are stored encrypted. TLS terminates at the edge for every public endpoint. ## Audit trail Because every change is an automation job, the job history shows what changed, when, and by whom. A record of API-token activity is kept for 90 days. Job history has no published retention period yet; ask us before you rely on it for compliance.