Skip to content

Getting started

Eight steps. About ten minutes, most of it waiting for a boot.

Create an account on the site, then click the verification link. Onboarding refuses an unverified address, and that refusal is the single most common way to get stuck at step 2.

Press Onboard in the console, or:

Terminal window
curl -X POST $BASE/v1/onboard \
-H "Authorization: Bearer $JWT" \
-H "Content-Type: application/json" \
-d '{"password":"<a password you use nowhere else>"}'

This creates your project, your cloud user, your network, and your billing customer. It is idempotent — if it times out, run it again.

[!warning]

Choose that password carefully. It is used only on this first call, there is no reset endpoint yet, and it is stored in recoverable form so the console can be opened for you. Use a unique one and keep it in a password manager. See Credentials and trust.

Console → Access keys → mint. Or:

Terminal window
curl -X POST $BASE/v1/access-keys -H "Authorization: Bearer $JWT"
# { "access": "…", "secret": "…" }
Terminal window
export AWS_ACCESS_KEY_ID=…
export AWS_SECRET_ACCESS_KEY=…
alias sc='aws --endpoint-url https://ec2.shelfcs.com --region hel1'
sc ec2 describe-instance-types

[!primary]

The region is hel1. Get it wrong and every call returns SignatureDoesNotMatch with nothing in the message explaining why. This is the second place people get stuck.

Terminal window
sc ec2 import-key-pair --key-name mykey \
--public-key-material fileb://~/.ssh/id_ed25519.pub

Import your own rather than using create-key-pair, which returns a private key once and never again.

Terminal window
sc ec2 describe-images --filters Name=name,Values=debian-13
sc ec2 describe-instance-types

A new account starts at 4 vCPU and 8 GB, so cd-standard-2-4 is a comfortable first machine. AWS names work too — m5.large is exactly cd-standard-2-8.

Terminal window
sc ec2 run-instances \
--image-id ami-… \
--instance-type cd-standard-2-4 \
--key-name mykey \
--count 1 \
--client-token "$(uuidgen)" \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=first}]'

Then wait for running:

Terminal window
sc ec2 describe-instances --instance-ids i-… \
--query 'Reservations[].Instances[].[InstanceId,State.Name,PrivateIpAddress,PublicIpAddress]' \
--output table
Terminal window
ssh debian@<address>

[!warning]

Not root@. The login user is set by the image, not by us: debian, ubuntu, rocky, almalinux, fedora, opensuse, arch. Using the wrong one gives a permission denied that looks exactly like a broken key. This is the third place people get stuck.

Terminal window
sc ec2 create-volume --availability-zone hel1-a --size 20 --volume-type standard
sc ec2 attach-volume --volume-id vol-… --instance-id i-… --device /dev/sdf

Then inside the machine:

Terminal window
lsblk
sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data
echo "UUID=$(sudo blkid -s UUID -o value /dev/vdb) /data ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab
sudo mount -a

--volume-type standard is required — the AWS default is gp2 and it is rejected. nofail keeps a missing disk from making the machine unbootable.

Terminal window
sc ec2 terminate-instances --instance-ids i-…
sc ec2 delete-volume --volume-id vol-…

Terminating destroys the root disk. The volume survives until you delete it, and deleting it destroys the data.

You wantRead
To understand what you just builtCompute user guide
To do it from codeCompute developer guide
Every command on one pageCheat sheet
To know what the disk really isStorage user guide
To know what it costsBilling user guide
What one account can be divided intoAccount user guide
SymptomCause
SignatureDoesNotMatchThe region. It is hel1
Onboarding refusesEmail not verified
Permission denied (publickey)Wrong login user for that image
InsufficientInstanceCapacityThe box is full. Smaller shape, or wait
InstanceLimitExceededYour quota — 4 vCPU, 8 GB to start
Booted, but nothing workscloud-init failed silently. Metadata and user data
Cannot SSH at allUse the VNC console — it works before the network does