Frostmoln Docs

English

Svenska
Suomi
Norsk

English

Svenska
Suomi
Norsk

Appearance

Compute / Instances ​

Frostmoln Compute runs virtual machine instances on demand. This guide covers creating, accessing, resizing, and managing instances, plus SSH keys, snapshots, launch templates, and scale groups.

Create an instance ​

In the portal, Compute → Instances → Create walks you through:

  • Name.
  • Image — the operating system (browse public images, filter by OS, or boot from a custom image you uploaded yourself).
  • Flavor — the size (vCPU / RAM / disk). Flavors use versioned IDs like gp1.medium (family + generation + size).
  • VPC + subnet — the private network the instance joins (see VPCs), and optionally an availability zone.
  • SSH keys — one or more public keys to install for login.
  • Security groups — the firewall rules applied (see Security Groups).
  • User data — an optional cloud-init script run on first boot.

The dialog shows the estimated cost before you confirm.

From the CLI ​

bash
fm compute image list          # browse images
fm compute flavor list         # browse sizes

fm compute instance create \
  --name web-1 \
  --image <image-id> \
  --flavor gp1.small \
  --vpc my-vpc \
  --subnet my-subnet \
  --ssh-key my-laptop \
  --security-group web \
  --user-data @cloud-init.yaml

With Terraform ​

hcl
data "frostmoln_image" "ubuntu" {
  name = "ubuntu-24.04"
}

resource "frostmoln_instance" "web" {
  name            = "web-1"
  image_id        = data.frostmoln_image.ubuntu.id
  flavor_id       = "gp1.small"
  vpc_id          = frostmoln_vpc.main.id
  subnet_id       = frostmoln_subnet.main.id
  ssh_key_names   = ["my-laptop"]
  security_groups = [frostmoln_security_group.web.id]
  user_data       = file("cloud-init.yaml")
}

Both take IDs, not display names: an image is identified by UUID (list them with fm compute image list, or resolve one by name with the frostmoln_image data source as above), while a flavor's ID is its SKU. Changing flavor_id triggers a resize (see below); changing image_id replaces the instance.

Cloud-init (user data) ​

The user data script is handed to cloud-init on first boot — use it to create users, install packages, write config, and start services so an instance comes up ready. Pass it inline or from a file (--user-data @file on the CLI, user_data = file(...) in Terraform). It may be up to 49,149 bytes. The platform composes your user data with its own cloud-init parts — the SSH keys you selected, and the agent enrolment script when instance access is enabled — so leave a little headroom; if the total is too large the create is rejected, telling you your byte count and how much to remove.

On the instance, /var/lib/cloud/instance/user-data.txt holds the composed multipart document rather than your script alone. Parts containing non-ASCII characters (å, ä, ö, €, …) are base64-encoded there — that encoding is what makes them arrive intact, and cloud-init decodes them before running anything.

A script that installs packages or downloads anything needs outbound internet access, which a VPC only has through an Gateway (or, for this instance alone, a public IP). In a VPC with neither, such a script gets no further than the first download.

Connect ​

SSH is key-only (password authentication is disabled). Log in as the image's default user — root is locked. It's debian on Debian, ubuntu on Ubuntu, almalinux / rocky / fedora on those, and so on. The instance's detail page in the portal shows the exact ssh command for that image.

Whether you can reach it depends on the address:

  • A public IP makes the instance reachable from the internet. Allow inbound SSH (port 22) in its security group from your address, then connect with the matching private key:

    bash
    ssh debian@<public-ip>

  • The private IP (e.g. 10.x.x.x) is reachable only from within the VPC — from another instance in the same VPC, or over a VPN/bastion into it. It is not reachable from the public internet, so assign a public IP for direct SSH from outside. It gives the instance no way out either: for outbound traffic the VPC needs a Gateway.

If you can't get in over SSH, open the console for direct keyboard-and-screen access, or check its boot output.

Console ​

When you can't reach an instance over SSH — a broken network config, a firewall mistake, a kernel that won't boot — open its web console for direct keyboard-and-screen access, like plugging a monitor and keyboard into the machine.

  • In the portal, open the instance and click Console (available while the instance is running). A noVNC session opens in a new browser window.

  • Or from the CLI:

    bash
    fm compute instance console web-1

    This prints a one-time console URL — open it in a browser.

The console URL carries a single-use, short-lived token and is scoped to that one instance. Only you — an authenticated member of the instance's tenant — can open it; Frostmoln staff cannot access your VM console. For the boot/serial log instead of an interactive screen, the instance also exposes console output.

Logging in at the console ​

Cloud images ship without a password, so by default there is nothing to type at the console — it's for inspecting a stuck boot or fixing networking, then getting back in over SSH. To make the console loginable, set an optional console password when you create the instance (portal create form → Advanced options; --console-password on the CLI; console_password in Terraform), then log in as the image's default user (debian, ubuntu, …).

  • The password must be printable ASCII — it is typed at a VNC text console whose keyboard cannot reproduce non-ASCII characters (e.g. å).
  • It works only at the console. SSH stays key-only — a console password never enables SSH password login.
  • It is applied by cloud-init, as a chpasswd in the instance's user data. A custom image that has no cloud-init installed therefore accepts the password and silently ignores it: the launch succeeds, the instance boots, and no password is ever set. The same happens if your own user data replaces the users: list and leaves the default user out of it.
  • The user it applies to is resolved from the image, so an image the platform cannot resolve a login user for — one that declares no OS distribution, or one it does not recognise — makes the launch fail with cannot determine the default user for this image; omit the console password or use an SSH key. os_distro can only be set when the image is created, so an image that got it wrong has to be re-uploaded; otherwise launch it with an SSH key and no console password.
  • It is not available for Windows images: a launch that asks for one fails with console password is not supported for Windows images. Frostmoln sets no credentials inside a Windows guest at all — see Windows images.
  • Those failures arrive asynchronously. The portal and Terraform surface the message, but fm compute instance create returns before the launch finishes: it prints the instance as pending and exits 0, and the instance then ends up in error, with the reason visible in the portal.

Lifecycle ​

From the detail page or CLI you can start, stop (--force for a hard stop), and reboot (--force for a hard reboot):

bash
fm compute instance stop web-1
fm compute instance start web-1
fm compute instance reboot web-1

Resize ​

Move an instance to a different flavor with the CLI or Terraform (change flavor_id):

bash
fm compute instance resize web-1 --flavor gp1.medium

The instance stops briefly during the resize, then comes back on the new flavor. After a resize you confirm it (to keep the change) or revert it (to roll back to the old flavor). Disk size can grow but not shrink.

SSH keys ​

Manage keys under Compute → SSH Keys or fm compute ssh-key:

bash
fm compute ssh-key create --name my-laptop --file ~/.ssh/id_ed25519.pub  # import
fm compute ssh-key create --name generated                               # generate (private key returned once)
fm compute ssh-key list

Keys are referenced by name at instance-create time.

Snapshots ​

Capture an instance's disk as a snapshot for safekeeping.

INFO

Snapshot create, list, and delete are available today. Launching a new instance directly from a snapshot is not yet available — for reusable instance blueprints, use launch templates (described below).

Launch templates and scale groups ​

  • Launch templates capture a reusable instance configuration (image, flavor, network, security groups, user data) so you can stamp out identical instances.
  • Scale groups run a managed set of instances at a desired capacity you set. You scale a group by changing its desired size.

Manual scaling for now

Scale groups support manual capacity changes today; metric-based autoscaling policies are not yet available — set the desired count yourself.

Limits ​

  • One region (Sweden) today; no multi-AZ failover.
  • Resize causes brief downtime (the instance stops, then restarts on the new flavor); disk can grow, not shrink.
  • Console login needs a console password — cloud images ship without one, so set it at create (see Console); it must be ASCII and works only at the console. SSH itself is always key-only. It is delivered by cloud-init, so a custom image without cloud-init silently ignores it, and it is not available for Windows images.
  • Snapshot restore / launch-from and instance autoscaling are not yet available.