Cloud Servers

Cloud Servers explained

A Cloud Server is a virtual computer you rent and run in one of our regions. It has its own operating system, memory, disk and network, and you control it exactly like a physical machine, except you create and destroy it in minutes. You manage servers under Cloud Servers in the console. Each server shows a status: Active means it is running, Shutoff means it is stopped, and Build or Resize mean an operation is in progress. The common things you do with a server all have their own guides: - Launch your first Cloud Server - Give your server a public address - Connect over SSH - Resize to a bigger or smaller plan - Back it up with a snapshot - Delete it to stop charges Two settings you choose when creating a server shape everything else: the Server Plan (its size) and the Operating System (the software it boots). Read Server Plans explained and Operating Systems and custom images before you launch anything important.

Server Plans (sizes) explained

A Server Plan is the size of a Cloud Server: how many virtual CPUs it has, how much memory, and how large its built-in disk is. You choose a plan when you create a server, and you can change it later with a resize. The g1 family scales in even steps, so you can start small and grow: | Plan | vCPU | Memory | Disk | | --- | --- | --- | --- | | g1.nano | 1 | 512 MB | 5 GB | | g1.micro | 1 | 1 GB | 10 GB | | g1.small | 1 | 2 GB | 20 GB | | g1.medium | 2 | 4 GB | 40 GB | | g1.large | 4 | 8 GB | 80 GB | | g1.xlarge | 8 | 16 GB | 160 GB | | g1.2xlarge | 16 | 32 GB | 320 GB | | g1.4xlarge | 32 | 64 GB | 640 GB | Which one to pick - g1.nano / g1.micro: learning, small scripts, a light bot. - g1.small / g1.medium: a small website, a staging app, a modest database. - g1.large / g1.xlarge: a busy production app or a database under real load. - g1.2xlarge / g1.4xlarge: heavy workloads, batch processing, large in-memory jobs. You can browse the live list any time under Cloud Servers, then Server Plans. If you outgrow a plan, resizing keeps your disk and data; it only changes CPU and memory. If you need more disk rather than more power, add a volume instead.

Operating Systems and uploading a custom image

The Operating System is the software a server boots from. You pick one when you launch a server, and you can browse the full list under Cloud Servers, then Operating Systems. What we provide Ready-to-use images kept in every region, so a server boots in seconds: - Linux: Ubuntu (24.04, 22.04, 20.04 and newer LTS), Rocky Linux 9, AlmaLinux 9, Debian 12, Oracle Linux 8 and 9, Fedora CoreOS. - Windows: Windows Server 2019, 2022 and 2025. If you are unsure, Ubuntu 24.04 LTS is a safe default. Upload your own image If you have a prepared disk image (for example one exported from another platform): 1. Open Cloud Servers, then Operating Systems, and click Create Image. 2. Fill in: - Name: what it will appear as in the list. - Format: the disk format of your file, such as QCOW2 or Raw. - Image file: upload the file, or give a URL to fetch it from. - Minimum disk / memory (optional): the smallest plan the image needs. 3. Create it. Once processed, it appears in the list and you can launch servers from it. Moving many machines in from another cloud or VMware is better done through the guided process; see Migrate to Gewape Cloud rather than uploading disks by hand.

Create a bare metal server

Most workloads run on a normal Cloud Server, a virtual machine that shares a physical host. When you need a whole physical machine to yourself, for performance, licensing, or isolation, create a bare metal server instead. It gives you the entire host with no virtualisation layer and no neighbours. Create one 1. Open Cloud Servers and choose Create Ironic Instance. 2. Work through the wizard, much like a normal server: - Availability Zone: the region to run in. - Operating System: the image to boot. - Flavor: the bare metal profile (a whole physical machine, not a virtual size). - Name: a recognisable name. - Network and SSH Key, as with any server. 3. Create it. Bare metal takes longer to provision than a virtual server because a physical machine is being prepared for you. After it is up Manage it like any other server: give it a public address, open ports, and connect over SSH. Bare metal is priced higher because you reserve a full machine, so use it where the isolation or raw performance genuinely pays off. For redundancy across ordinary servers instead, see Placement Groups.

Keep servers together or apart (Placement Groups)

When you run several servers for one service, where they physically sit matters. A Placement Group tells the platform to keep a set of servers apart from each other, or close together, when they are created. Find them under Cloud Servers, then Placement Groups. Create a group 1. Open Placement Groups and create one. 2. Fill in: - Name: for example web-tier. - Policy: choose one: - Anti-affinity (keep apart): servers land on different physical hosts. Use this for redundancy, so one host failing only affects one server. - Affinity (keep together): servers land on the same host, for the lowest latency between them. 3. Create it. Use it When you launch a server, open Advanced Options in the System Config step and select the placement group. Do this for each server that should follow the policy. For a highly available service, the common pattern is a pair of servers in an anti-affinity group behind a Load Balancer, so they never share a host and traffic moves off any server that fails.