Manage a server
Open Servers, select a server, then open General to manage its identity, SSH connection, domain defaults, and role.
Before changing the IP address, domain, SSH user, port, or connection timeout, confirm that the new connection works from the Coolify machine.
General settings
| Setting | What it controls |
|---|---|
| Name | The name shown for the server in Coolify. |
| Description | Optional notes about the server or its purpose. |
| Wildcard domain | The base domain Coolify can use when suggesting domains for new resources. |
| IP address or domain | The address Coolify uses for SSH and server communication. |
| SSH user | The account Coolify uses for SSH. |
| SSH port | The SSH port. |
| Connection timeout | How long Coolify waits for the SSH connection, from 1 to 300 seconds. |
| Server timezone | The timezone used for scheduled operations such as backups and cron jobs. |
| Server role | Choose Deployments only, Builds only, or Deployments and builds. See Server roles. |
Select Save changes after changing fields that do not save automatically. If you changed the connection, run the server validation again to confirm Coolify can still reach it.
You cannot switch a server with managed resources to Builds only. Move or delete those resources first. The role cannot change while GitHub Actions runners are enabled. Read Build Servers before changing the role.
Wildcard domain
For example, setting Wildcard domain to https://example.com lets Coolify suggest a domain such as https://<application-id>.example.com for a new resource.
Create a DNS record for *.example.com that points to this server. Changing the setting does not create DNS records or update domains already assigned to resources.
Server details
After successful validation, the General page displays detected information such as:
- operating system
- CPU architecture and core count
- memory
- kernel version
- Docker versions
Coolify refreshes this information when it validates or checks the server. Use it to confirm that the connected machine and its available resources match what you expect.
Link an existing server to a cloud provider
If you added a Hetzner, DigitalOcean, Vultr, or Hostinger server manually, you can link its Coolify record to the matching provider machine.
Linking lets Coolify read provider status and display provider-backed actions such as Power On when the machine is stopped. It does not create a new machine.
Add the provider token
Follow Cloud Tokens to add a token for the account containing the server.
Open the linking flow
- Open Servers and select the server.
- Open General.
- Select Link Cloud Provider.
- Choose Hetzner, DigitalOcean, Vultr, or Hostinger.
- Select the matching provider token.
Find the provider machine
Search using the provider's server ID or the server IP address.
Confirm that Match Found shows the intended machine, then select Link This Server.
For Hostinger, the flow is different:
- Select Link Provider, then select Hostinger.
- Select the Hostinger token.
- Enter the Virtual Machine ID, or select Search By Server IP.
- Select Link Resource.
Confirm the link
Return to the server page and confirm that provider status is shown. If the status is stale, refresh it before taking a provider-backed action.
A linked Hostinger server shows a Hostinger · <state> badge. Select Refresh Status to update it. If the VPS is stopped, you can start it from Coolify. Coolify does not validate the server over SSH while the VPS is stopped or suspended.
Link only the provider machine represented by this Coolify server record. Provider-backed actions and deletion options apply to the linked machine.
Revalidate after connection changes
Run validation again after changing:
- IP address or domain
- SSH user or port
- network routing, firewall rules, or tunnel configuration
If the connection fails, restore the previous settings or use the provider console to correct SSH access. Follow OpenSSH and Firewall for the common checks.
Build and deployment limits
Open Advanced to control how many deployments a server runs at once and how long each deployment may run.
| Setting | What it controls | Default |
|---|---|---|
| Concurrent builds | How many build and deployment processes run at the same time on this server. Raise it to deploy more resources in parallel; lower it to protect a small server from resource exhaustion during builds. | 2 |
| Deployment timeout | The maximum time a single deployment may run before Coolify cancels it. Increase it for large images or slow builds that legitimately exceed the limit. | 3600 |
| Queue limit | The maximum number of deployments allowed to wait in the queue. When the limit is reached, Coolify rejects new deployments with an HTTP 429 response. | — |
Select Save changes after changing these values.
The concurrent-build count and queue limit apply to each server independently. A dedicated build server has its own limits, so raising them there does not affect deployments on other servers.
Disk usage notifications
Set the high-disk notification interval under Advanced. Alerts repeat at most once per interval per server, with a default of 24 hours. If usage falls at least five percentage points below the threshold and later rises above it, Coolify can alert sooner. The API field is server_disk_usage_notification_interval_hours.
A server becomes unreachable after two consecutive failed connection checks. A single failed check does not mark every resource as exited; deployment attempts recheck servers marked unreachable before failing.