Servers

A server is a machine at a provider, or one of your own. Two properties decide what KamalCloud can do with it:

• Registered — KamalCloud knows how to reach it over SSH. This gates everything done over SSH: hardening, preparing a runner, deploying, reading containers, opening a shell.
• API-managed — there is a provider API behind it. This gates everything that is an API call: building, resizing, powering, pricing, traffic figures.

A machine KamalCloud built is both. A self-hosted machine is registered but not API-managed.

Building one

Servers → New. Pick the connection, then a location, machine type and image from that connection’s catalog. The catalog is the provider’s own, with its prices.

KamalCloud creates the machine with the account’s SSH keys installed for root. No root password is set and none is needed. The row moves through the provider’s own statuses – pending, initializing, starting, running – and KamalCloud keeps reading it back until it settles.

Names follow RFC 1123: letters, digits and hyphens, not starting or ending with a hyphen. They are unique per connection, not per account, so a web-1 in each of two projects is fine.

Once it is running, KamalCloud detects the operating system and records what the machine says about itself: cores, memory, disk, architecture, addresses.

Adopting one

A machine you already have is added with its address rather than chosen from a catalog. See Self-hosted servers.

What you can do to one

Security

The Security page checks the machine and lists what is wanting. Each fix is applied on its own. See Hardening.

On a self-hosted machine where KamalCloud signs in as someone other than root, much of the check needs root or passwordless sudo -n. Without it, those rows say they could not be read.

Settings

Rename it, or resize it. Both change the machine at the provider, not just KamalCloud’s record of it. A resize needs the machine switched off first, and only goes larger: the form offers types with at least the current disk and the same architecture. Growing a disk cannot be undone – providers will not shrink one afterwards.

Power

Power on, power off, reboot. API-managed machines only: KamalCloud cannot press the button on hardware it cannot reach.

Sync

Ask the provider what this machine is now. Useful after changing something in the provider’s own console.

SSH key

Shows which key reaches this machine, and lets you put the account’s deploy key on a machine that does not yet trust it. For providers that hand back a root password, Provider access does it without anyone needing to know one.

Containers

What Docker is running here, read live over SSH. This is also where an import starts.

Apps

What is deployed here, and a way to put something here. It is the other end of an environment’s host list – the same relationship, asked from the machine.

Traffic and cost

For API-managed machines KamalCloud records the included traffic allowance and what has been used. AWS is the exception: it bills data transfer on the account rather than the instance, so there is no per-machine allowance to report. When the allowance is nearly spent, the server.traffic notification fires. Costs per machine roll up into the financial dashboard.

Deleting one

Deleting a server KamalCloud built destroys the machine at the provider and forgets its host key, because providers reuse addresses and a stale entry would fail every connection afterwards.

Removing a self-hosted server only forgets it. Nothing is sent to the machine, and whatever is running there carries on. If you want it tidied, Wipe what KamalCloud deployed too first runs kamal remove for every app whose only machine it is, and clears the Docker volumes behind them. Anything you put on the machine by hand is left alone.

Neither goes through until its data is somewhere else. The first attempt takes a farewell backup of everything holding data on the machine and refuses; the attempt after that goes through. The apps themselves stay. Volumes registered on that machine go – the backups already in buckets stay where they are.

There are no foreign key constraints behind any of this, which is deliberate but has one consequence worth knowing: an environment pointed at a machine that no longer exists reads as “no server”, and a deploy would fall through to whatever the repository’s own deploy.yml names. Check an environment’s hosts after removing a machine it used.