Skip to main content

Common GPU Dedicated Server Actions

This page explains the most common control actions you may use for a GPU Dedicated Server after it becomes active in Dash.

GPU Dedicated Server controls can vary depending on the provider, server model, hardware setup, or deployment method. Because of that, some actions may be available for one server but not for another.

Before using any action​

Before performing any control action, always confirm:

  • you selected the correct server
  • the service is active or otherwise in a controllable state
  • there is no billing issue affecting access or management
  • no important GPU workload is currently running

This is especially important for production systems and long-running compute jobs.

Power actions​

Power-related controls are the most common GPU Dedicated Server actions.

These usually include actions such as:

  • power on
  • power off
  • restart or reboot

Use these actions when you need to change the current power state of the server.

Before powering off or restarting a server, make sure:

  • important work is saved
  • no active GPU job will be interrupted unexpectedly
  • no training, inference, rendering, or compute workload is still running
  • the interruption is safe for the current workload

Rebooting a server​

A reboot is commonly used when:

  • system changes require a restart
  • the server becomes unstable
  • driver or software updates require a reboot
  • troubleshooting requires a clean restart

A reboot is usually the first safe recovery step before moving to more disruptive actions.

Reinstall options​

Some GPU Dedicated Server services may provide a reinstall option in Dash.

If reinstall is available, it is used to deploy the operating system again from a clean state.

Before using reinstall:

  • back up important files
  • confirm that the current system is no longer needed
  • verify that you selected the correct operating system if a choice is shown
  • make sure no required workload data remains only on the server

Reinstall should always be treated as a destructive action.

IPMI and low-level access​

GPU Dedicated Server services may provide IPMI access, or a similar hardware-level access method.

This is typically used when:

  • the operating system is not responding
  • network access to the server is not working
  • you need lower-level control during recovery or troubleshooting
  • remote operating system access is unavailable

If IPMI access is available for your server, use it carefully and only when needed.

Console access​

Some GPU Dedicated Server services may include console-based access in Dash or through the provider environment.

Console access availability depends on the provider and the server setup.

If available, console access can help when:

  • normal remote login is unavailable
  • you need to inspect boot behavior
  • networking inside the server was changed incorrectly
  • you need direct interaction during troubleshooting

If console access is not shown for your service, that does not necessarily mean there is a problem. It may simply not be provided for that specific server.

Check resource usage​

Another common action is reviewing the service statistics.

This helps when you want to:

  • understand current server activity
  • detect unusual system pressure
  • investigate performance issues
  • check whether another system resource is limiting the workload
  • confirm whether the server still matches your GPU workload requirements

For GPU-based projects, performance issues are not always caused by the GPU alone. CPU, RAM, storage, bandwidth, and software setup can also affect the result.

Confirm billing and renewal status​

Operational issues are sometimes caused by service lifecycle or billing state rather than by the server itself.

Check the billing section when you need to confirm:

  • whether the service is active
  • whether an invoice is overdue
  • the next due date
  • whether renewal is expected

Provider-dependent controls​

Not every GPU Dedicated Server includes the same set of actions.

Depending on the provider or deployment model, some servers may offer:

  • only basic power controls
  • power controls plus reinstall
  • power controls plus IPMI
  • other limited management features

For that reason, always treat the visible controls in Dash as the source of truth for that specific service.

Check service state before assuming a problem​

If an action is unavailable, disabled, or does not complete as expected, first review:

  • current service status
  • any visible billing issue
  • whether the server is still provisioning
  • whether the action is supported for that server

In some cases, the issue is not with the action itself, but with the current state of the service.

When an action does not work​

If a control action fails or the result is not reflected in Dash:

  • refresh the page
  • wait briefly and check again
  • confirm the current service status
  • review billing state
  • verify that the action is actually available for that server type

If the issue continues, contact support and include:

  • service ID
  • the exact action you attempted
  • the current visible service status
  • any error message shown in Dash