coollabsio/coolify · error · RuntimeException
Server is disabled.
Error message
Server is disabled.
What it means
SshMultiplexingHelper::generateSshCommand() throws when $server->settings->force_disabled is true. Coolify lets admins force-disable a server (manual toggle, or automatically when a host is unreachable); after that, every SSH command generated for it fails fast with this message instead of attempting a connection.
Source
Thrown at app/Helpers/SshMultiplexingHelper.php:181
if (data_get($server, 'settings.is_cloudflare_tunnel')) {
$scpCommand .= '-o ProxyCommand="cloudflared access ssh --hostname %h" ';
}
$scpCommand .= self::getCommonSshOptions($server, $sshKeyLocation, self::getConnectionTimeout($server), config('constants.ssh.server_interval'), isScp: true);
// Download: remote source -> local dest
if ($server->isIpv6()) {
return $scpCommand.escapeshellarg($server->user).'@['.escapeshellarg($server->ip).']:'.escapeshellarg($remoteSource).' '.escapeshellarg($localDest);
}
return $scpCommand.self::escapedUserAtHost($server).':'.escapeshellarg($remoteSource).' '.escapeshellarg($localDest);
}
public static function generateSshCommand(Server $server, string $command, bool $disableMultiplexing = false, ?int $commandTimeout = null): string
{
if ($server->settings->force_disabled) {
throw new \RuntimeException('Server is disabled.');
}
$sshConfig = self::serverSshConfiguration($server);
$sshKeyLocation = $sshConfig['sshKeyLocation'];
self::validateSshKey($server->privateKey);
$commandTimeout = $commandTimeout ?? (int) config('constants.ssh.command_timeout');
$sshCommand = $commandTimeout > 0 ? "timeout {$commandTimeout} ssh " : 'ssh ';
if (! $disableMultiplexing && self::isMultiplexingEnabled()) {
try {
if (self::ensureMultiplexedConnection($server)) {
$sshCommand .= self::multiplexingOptions($server);
}
} catch (\Throwable $e) {
Log::warning('SSH multiplexing failed, falling back to non-multiplexed connection', [
'server' => $server->name ?? $server->ip,View on GitHub (pinned to 70b9acc424)
Solutions
- Re-enable the server: open the server in the UI, go to Settings, turn off 'Force Disable', then retry the operation.
- If it was auto-disabled because the host was unreachable, fix the underlying SSH connectivity (IP, port, private key) before re-enabling.
- If you call SSH helpers programmatically, check settings->force_disabled first and skip/queue the work instead of letting it throw.
Example fix
// before: job throws 'Server is disabled.' mid-deployment
instant_remote_process($commands, $server);
// after: fail fast with an actionable message before any SSH work
if ($server->settings->force_disabled) {
throw new \RuntimeException("Server '{$server->name}' is force-disabled. Re-enable it in the server settings.");
}
instant_remote_process($commands, $server); Defensive patterns
Strategy: validation
Validate before calling
// Guard every SSH-backed job before it reaches the SSH layer
if ($server->settings->force_disabled) {
// skip, queue for later, or fail with an actionable message
throw new \RuntimeException("Server '{$server->name}' is force-disabled; re-enable it in server settings.");
}
$sshCommand = SshMultiplexingHelper::generateSshCommand($server, 'uptime'); Type guard
function serverSshAvailable(\App\Models\Server $server): bool
{
return ! $server->settings->force_disabled;
} Try / catch
try {
instant_remote_process($commands, $server);
} catch (\RuntimeException $e) {
if ($e->getMessage() === 'Server is disabled.') {
// do not retry — re-enablement is a user action; park the job
$this->release(3600);
return;
}
throw $e;
} Prevention
- Filter force-disabled servers out of build-server and automation candidate lists up front.
- Show the disabled state clearly in UI lists so users know why operations fail.
- Never auto-retry this error — it only clears after a human re-enables the server.
When it happens
Trigger: Any SSH-backed operation against a force-disabled server: deployments, proxy configuration, container status checks, terminal access, validations, backups — all route through generateSshCommand().
Common situations: Admin force-disabled the server after repeated connectivity failures and forgot to re-enable; automation/queue jobs still reference the disabled server in their payload; a server was disabled during an incident and never re-enabled.
Related errors
- Private key not found. Please add a private key to the appli
- Pre-deployment command: Could not find a valid container. Is
- Post-deployment command: Could not find a valid container. I
- 69420
- ScheduledTaskJob failed: No valid container was found. Is th
AI-assisted analysis of coollabsio/coolify@70b9acc424 (2026-08-17).
Data as JSON: /api/errors/04d32ce003b7a98c.
Report an issue: GitHub.