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

  1. Re-enable the server: open the server in the UI, go to Settings, turn off 'Force Disable', then retry the operation.
  2. If it was auto-disabled because the host was unreachable, fix the underlying SSH connectivity (IP, port, private key) before re-enabling.
  3. 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

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


AI-assisted analysis of coollabsio/coolify@70b9acc424 (2026-08-17). Data as JSON: /api/errors/04d32ce003b7a98c. Report an issue: GitHub.