Skip to main content

Servers

Servers are the machines on which Kumoto runs your project components. They can be VPS instances or dedicated machines from any provider you control. Kumoto does not provide the server itself: you choose the provider, create the machine, and retain ownership of that provider account.

A connected server becomes available as a deployment target. It does not receive a workload merely by being connected; components run on it only after a project that targets it is deployed.

For operating-system requirements, sizing, and the connection prerequisites, see Prepare a server.

Connect a server​

  1. In Servers, select Add server and give the machine a recognizable name, such as production-web-1.
  2. Open the newly created server and copy its generated connection command.
  3. Connect to the machine over SSH and run that command with sudo.
ssh root@YOUR_SERVER_IP_ADDRESS
curl -fsSL "YOUR_GENERATED_JOIN_URL" | sudo bash

The join URL is unique to that server and expires after one hour. Treat it as sensitive and use the value provided in the dashboard. If it expires, return to the server setup screen to generate a new command.

During setup, Kumoto creates the account and configuration it needs to manage deployments. Once the server is connected, choose it as the target for a component in a project draft, then deploy the project to run the workload there.

Organize servers clearly​

Use names that indicate a server's role, location, or environment. Clear names make the target selector and deployment review much safer when you operate more than one machine.

For example, you could name servers production-app-1, production-data-1, and staging-app-1. The names do not change how Kumoto deploys; they help your team identify the intended target before a rollout.

Monitor a server​

Each server overview shows its assigned projects and components, so you can see which workloads are using the machine. It also provides CPU, memory, disk, and network telemetry, with time ranges from the last hour through the last month.

Use this view to check capacity before sending another workload to a server, and to investigate an application that may be resource constrained. If sustained usage approaches the server's limits, resize the VPS with your provider or add another server and move future component changes to it.

Telemetry provides useful operational context, but it does not replace your existing monitoring, backups, incident response, or capacity-planning practices.

Remove a server​

Remove a server only after its workloads have been moved or retired. Before deleting it:

  1. Review the projects and components assigned to the server.
  2. Move dependent components to another connected server, or remove them from the relevant project draft.
  3. Deploy those project changes and confirm that the workloads are healthy on their new target or no longer needed.
  4. Delete the server from Kumoto.

Deleting a server from Kumoto does not cancel your VPS provider account or automatically resolve workloads that still need a machine. Keep the provider-side server until you have confirmed the migration or retirement is complete, then manage its deletion through your provider.