Overview
An instance is just a virtual machine on Atlas infrastructure. KVM does the virtualization and CloudStack orchestrates it, but none of that matters much in practice. What you get is a machine you can make bigger or smaller depending on what it has to do, whether that’s a small web server ticking along or a box chewing through a large dataset.
Key Features
Sizing is the choice you’ll make most often, and it comes down to a compute offering from the Atlas.aN range. On Linux the smallest is Atlas.a4 at 1 vCPU, 4 GiB of memory, and a 20 GiB disk; the largest, Atlas.a8, jumps to 16 vCPU, 64 GiB, and 320 GiB. If you need Windows, the Atlas.a6w, Atlas.a7w, and Atlas.a8w offerings cover it, with a licensing surcharge on top for the Windows license itself. Rather than memorize the table, check the pricing page, which always lists the complete catalog and rates.
The Root Volume sticks around across reboots, so you won’t lose the OS when the machine restarts. The instance also sits inside an isolated Guest Networks or VPC, which keeps its traffic walled off from other tenants.
Managing Instances
Launching an Instance
Create a Guest Network or VPC tier first; the instance attaches to it. Then open Compute > Instances, click Add Instance, and fill in the form: zone is1, a Template for the OS (for example Ubuntu 24.04), a Compute Offering for CPU and RAM, the network, and an SSH key from SSH Key Pairs. A data disk is optional.
Without an SSH key, the Ubuntu 24.04 LTS template shows a one-time password for the ubuntu user right after launch. Copy it then; it cannot be retrieved again. The Debian 13 template has no password option and needs an SSH key. The first-VM walkthrough shows the popup.
Lifecycle Actions
A running instance has a handful of actions in the console. Stop shuts the OS down and pauses compute metering, though storage keeps being metered while the VM sits there. Reboot is the usual OS restart, the same as running reboot inside it. Destroy deletes the instance and its root volume for good, so treat it as final. And if SSH ever stops cooperating, View Console opens a VNC session straight to the machine for emergency access.
Connecting
Reach the instance over its public IP if one is mapped through NAT, or over the internal IP from a VPN or private network. Log in as the template’s default user, ubuntu on Ubuntu 24.04 LTS and debian on Debian 13 (image login accounts):
ssh <USER>@<PUBLIC_IP>Advanced Configuration
Beyond launching and connecting, a few features come up once you start running real workloads.
The first is User Data. Hand an instance a cloud-init script when it launches and it’ll configure itself on first boot, installing packages, writing config files, creating users, whatever you script. That’s how you go from a bare template to a ready service without ever logging in by hand, and it’s the same mechanism the Terraform tutorials lean on. The User Data Library collects scripts you can start from. The payoff is repeatability: rebuild the instance and you get the identical setup every time, which matters far more than it sounds the first time you have to recreate a box from memory at an awkward hour.
Traffic control works differently depending on the network type, which catches people out. In a VPC you reach for Network ACLs, stateless rules that apply at the subnet level. Isolated guest networks don’t use ACLs; they use firewall rules for inbound and egress rules for outbound (see Public IP Addresses and Guest Networks). The catch worth repeating: an isolated guest network blocks everything outbound until you add egress rules, so a VM that can’t apt update or resolve DNS is almost always missing them.
Finally, Instance Snapshots capture a volume at a moment in time. Take one before a risky change and you have a clean restore point to roll back to.
A note on cost while you’re managing instances: stopping a VM pauses the compute charge, but the storage behind it keeps billing because the disk still exists whether the machine is on or off. So a stopped instance costs less than a running one, though its storage still bills. If you’re truly done with a VM and its data, destroying it is what stops the storage charge, just remember that destroy takes the root volume with it and there’s no undo. When in doubt, snapshot first, then destroy. The short version: stop a VM you’ll come back to, snapshot anything you might want again, and destroy what you’re genuinely finished with.