# Global Private Network (/docs/gpn)



A **Global Private Network** (GPN) is a connection between all Servers.com data centers without routing traffic via public networks. This service provides you with a network isolated from the internet, and removes the need for tunnels and a VPN.

## Concepts

A **Customer Private Network** (CPN) is a /23 network that is allocated from the private pool 10.0.0.0/8 for GPN on your account. This network is securely isolated from other customers. A CPN is allocated to you after your first order of a [dedicated server](https://www.servers.com/products/dedicated-servers), and will be automatically configured in an OS and with the network devices during the server set-up. An IP address from the CPN block will be assigned to:

* the `aggi` interface of a dedicated server with link aggregation
* the `int1` interface of a dedicated server without link aggregation
* a separate virtual interface of a cloud server

After set-up, the server will be available to other hosts within the GPN through its private IP address. You can find this address on the details page of your server or by executing one of the following commands:

* `ifconfig` - for Linux
* `ipconfig` - for Windows

## Use case

If you have several servers across different locations that communicate between each other, you can remove your expenses on public traffic. To do this, route your traffic to your GPN. Traffic will not be billed as it will go through the free private network.

## Limitations

These are the limitations on GPN capacity to be aware of:

* The service is only available for dedicated and cloud servers, SBM and Kubernetes clusters
* The maximum bandwidth is up to 20Gbps for each dedicated server

## Billing

The service is free.


# Account management (/docs/account/account-management)



This page covers the most common account management tasks available in the Customer Portal, including access control, user management, and security settings.

### Verify your identity

To undergo the procedure, follow the individual instructions provided by the customer support and billing department.

### Enable 2FA

Two-Factor Authentication (2FA) significantly enhances account security.
To enable 2FA for your account, complete the following steps:

1. Click **Account** in the top right corner of the Customer Portal page → select **User Profile**.
2. Navigate to the **2FA** section and click **Enable 2FA**
3. In the pop-up window that opens, enter the account password and a one-time token, which can be obtained in two ways:
   * By scanning the QR code using your smartphone camera with an authenticator application app
   * By clicking the link below the QR code
4. Click **Enable 2FA**
   Two-factor authentication will be activated for your account.

### Create an API token

The API token is used for accessing the Public API.
To create the API token, complete the following steps:

1. In the left-hand menu, go to **Identity and Access → API keys** and click **Create**.
2. Enter the API token name and select the access level
3. Click **Create**
4. Enter the account password and click **Continue**
   The created API token will appear.
   To return to the window with the list of existing API tokens, click **Back to API tokens list**.
   We recommend storing the API token locally. API tokens are not stored in the Customer Portal and are not restored if lost.

### Revoke an API token

To revoke the API token, complete the following steps:

1. In the left-hand menu, go to **Identity and Access → API keys**
2. Select the API token you want to remove and click **Revoke**
3. Confirm by clicking **Revoke**
4. Enter the account password and click **Continue**
   The API token will be removed.

<Callout>
  The API tokens are issued with the user account. When deactivating the user account, it is also necessary to remove the user's API token.
</Callout>

### Create the support ticket

Create a support ticket to report an issue to the support team.
To create a support ticket, complete the following steps:

1. Go to **Requests** in the left-hand menu and click **Submit a new request**
2. Fill the form with the support ticket details.
3. Once you have finished, click **Create**.
4. Optionally, provide the additional details:
   * Specify the server that corresponds with the support ticket or click **Skip** to bypass adding additional details
   * Select the options that determine the access level to the server and enter the administrator password to the server
5. Once you have finished, click **Submit**
   The support ticket will be created.

### Add a user to the account

Adding users and assigning them roles is necessary for the distribution and control of permissions and access levels within the account.
To add the user to the account, complete the following steps:

1. In the left-hand menu, go to **Identity and Access** → **Users** and click **Invite user**
2. Fill the form with the following details:
   * **Email**: the user's email address for login to the user's account
   * **Role**: the role that will be assigned to the user
3. Click **Send**
4. Enter the account password and click **Continue**
   The user will be added and an invitation with the link for activating the user's account will be sent to the user's email address.

### Change the user role

To change the user role, complete the following steps:

1. In the left-hand menu, go to **Identity and Access → Users**
2. Select the required user from the list
3. Depending on the current user role:
   * Click **Change to Manager** to change user role from `Owner` to `Manager` or vice versa
4. Enter the account password and click **Continue**
   The user role will be changed.

### Remove user from the account

To remove a user from the account, complete the following steps:

1. In the left-hand menu, go to **Identity and Access → Users**
2. Select the user you want to delete from the list
3. Change the Status to **Disable**
4. Enter the account password and click **Continue**
   The user will be deleted from the account.

### Add subscription

Subscriptions are email addresses used to receive account notifications. There are two types of subscription: **Direct** (automatically linked to a specific user) and **Additional** (linked to the account and manually created).
A direct subscription is created automatically when you invite a user. To add an additional subscription, complete the following steps:

1. In the left-hand menu, go to **Account settings**.
2. Scroll to the **Subscriptions** section and click **Create**.
3. Fill in the form with the contact details, including first and last name, phone, job title, and notification types.
4. Click **Create**.

A confirmation email will be sent to the subscription's email address. The subscription will start receiving notifications after confirming the email.
You can view all contacts in the **Subscriptions** list under **Account settings**. The list shows the contact name, email address, notification types, subscription type (**Direct** or **Additional**), phone, and the associated user.

### Remove subscription

Only additional contacts can be removed manually. Direct subscriptions are removed automatically when the associated user is removed from the account.
To remove an additional subscription:

1. In the left-hand menu, go to **Account settings**.
2. Scroll to the **Subscriptions** section and click the trash icon next to the contact you want to delete.
3. Confirm by clicking **Delete**.

The subscription will be removed.

### Add the SSH key

SSH key is a reliable and safe alternative for the password authentication.
To add the SSH key, complete the following steps:

1. In the left-hand menu, go to **Identity and Access** → **SSH & GPG keys** and click **Create**
2. Fill in the form with the SSH key details
   * **Name**: enter the name of the SSH key
   * **SSH key source**: use your own public SSH key or generate the new one
   * **Public key**: specify your own public key you want to use as the SSH key source
3. Click **Create**
   The generated SSH key will appear. To copy the SSH key click the copy button in the upper right corner of the window.

<Callout>
  We recommend storing the SSH key locally. SSH keys are not stored in the Customer Portal and are not restored if lost.
</Callout>

### Remove the SSH key

To remove the SSH key:

1. In the left-hand menu, go to **Identity and Access** → **SSH & GPG keys**
2. Select the SSH key you want to delete from the list and click the trash icon
3. Confirm by clicking **Delete**
   The SSH key will be deleted.

### Give support access to the account

If needed, you can give account access to our support team for 24 hours.
To do this, complete the following steps:

1. In the left-hand menu, go to **Account settings**
2. Scroll to the **Support access** section and click **Allow**
3. To confirm access click **Continue**
   Access to your account for our support team will be granted for 24 hours. You can extend the access or terminate it when it is no longer necessary.

### Change the account password

To change the account password, complete the following steps:

1. Click **Account name** in the top right corner of the Customer Portal page and select **User Profile**
2. Scroll to the **Change password** section and click **Change password**
3. Fill the form with the old and new passwords and click **Save**
   The account password will be changed.

### Deactivate the account

To deactivate an account, all users must be removed from the account. Once the last user is deactivated, a request will be sent to the Billing Department to check the account for any outstanding debts, active services, or remaining balance. Once all these billing issues are resolved, the account will be deactivated.
To deactivate the account, a user with the `owner` role must complete the following steps:

1. Remove all the users from the account by following the instructions above
2. Click **Account name** in the top right corner of the Customer Portal page and select **User Profile**
3. Scroll to the **Deactivate user** section and click **Deactivate user**
4. To confirm deactivation request click **Deactivate**
5. Enter the account password and click **Continue**
   The request for the account deactivation will be sent to the Customer Portal team.


# Concepts (/docs/account/concepts)



Understanding how accounts, users, and access are structured is key to managing your Servers.com environment effectively. This page covers the essential concepts — from roles and contacts to API authentication, session control, and identity verification.

## Account

The **account** is a legal entity associated with services and payment. All accounts support an unlimited number of users. Users can perform sets of actions to manage their account. Available actions can be found in the Customer Portal under the **Identity and Access** section.

### Account restrictions

* The account should have at least one active `owner`
* Only one account can be associated with an email address
* The users cannot modify the roles of other `owner` users
* The `owner` can change their role, provided there is another active `owner` for the account

## User

The **user** is a person with authorized access to the account. Users have a set of permissions, such as inviting a new user.

### User restrictions

* A single user cannot be a member of various accounts
* Users don't have access to the list of other users in the Customer Portal

### User roles and access

Each account user is assigned a specific role and each role is defined by a specific set of permissions.
There are two common types of user roles:

* **Owner**: this role provides full access to the account
* **Manager**: this role provides full access without user management capabilities

The initial user created is always designated as the `owner`. If for any reason, a user already possesses a Public API token, they can utilize the API without any restrictions.
The `current user` is the user who is currently logged into the Customer Portal.

### List of users

The User Management page shows a list of users with the following parameters:

* **Name**: the name of the user
* **Email**: the email address of the user
* **Last login**: the user's last log in date
* **2FA enabled**: Two-Factor Authentication is enabled for the user
* **Role**: the role of the user
* **Status**: the status of the user

## Subscription

The **subscription** is the email address used to receive notifications. The type of notifications depends on the assigned notification types, which can be combined to assign multiple ones to a single contact.

Subscriptions have two types:

* **Direct**: a subscription directly linked to a specific account user, with a one-to-one relationship. One direct subscription is created automatically when a user is invited to an account. The direct subscription email always matches the user's email and cannot be edited or deleted separately — it is removed only when the user is removed.
* **Additional**: a subscription linked to the account rather than to a specific user. An account can have an unlimited number of additional subscriptions.

In the Customer Portal under **Account settings**, the following notification types are available:

* Primary
* Technical
* Billing
* Abuse
* Emergency

For example, a Primary subscription receives all notifications, while a Billing subscription receives only notifications related to finances.

### Subscription restrictions

* Direct subscriptions cannot be deleted independently. To remove a direct subscription, remove the corresponding user.
* The email address of a subscription cannot be changed after creation.
* On accounts using role-based permissions, only account owners can create, edit, or delete additional subscriptions. On accounts using IAM permissions, an administrator can also manage them if granted the `ContactsFullAccess` or `ContactsManagement` permission (to add or edit) or the `ContactsAllowDelete` permission (to delete).
* Account members can edit limited fields of their own direct subscription (such as first and last name, phone, and job title), but cannot change the email address or notification types.

## API key

Tokens are used for authentication when accessing account resources via the Public API. These API keys are issued and function within the scope of the account and can have two types of access:

* **Read-only** — this token allows only `GET` requests and is intended for data retrieval.
* **Read & write** — this token has full access to the API and permits the user to make changes.

Refer to the specifications for a detailed description of all available account actions via the API.

## Active session

Controlling active sessions helps to protect your account from unauthorized access.
The active session list contains authorization history, including unsuccessful attempts. It includes the date, the time, and the IP address from which the account was accessed. Additionally, there is an option to receive notifications for each attempt to log into the account.
It is used for the following purposes:

* **Security**: tracking active sessions helps to detect suspicious activity or unauthorized attempts to access the account
* **Access control**: knowing from which IP address and when the user accesses the account allows you to manage access and take security measures if necessary

The session lifetime is one hour.

### Sign-up attempt notifications

If someone attempts to register a new account using an email address that already belongs to an active user, the system sends a notification to that email. The notification includes the IP address of the sign-up attempt and a prompt to secure the account - for example, by enabling 2FA, configuring an IP allowlist, or changing the password.

## Support access

Support access is a feature that enables granting temporary access to technical support staff.
Access may be required for the following reasons:

* **Problem resolution**: to resolve technical issues or questions encountered by the user
* **Troubleshooting**: to assess the situation and identify the causes of any problems
* **Setup and configuration**: to make changes to the account's settings or configuration, and to address issues or optimize service performance
* **Training and consultation**: to provide user training on service usage or consult on security, functionality, and other aspects
* **Configuration and security checks**: to verify user account settings and ensure its security by identifying potential vulnerabilities or issues

Access to the account is granted only for necessary operations and is limited to 24 hours. After this period expires or upon manual cancellation, access to the account is revoked.

## KYC

The purpose of the KYC (Know Your Customer) process is to confirm the client's identity, comply with the law, identify suspicious users, prevent fraud, and protect the company from financial risks.
The verification of identity and payment method occurs after the client completes the entire service ordering and payment. Additionally, the verification process may involve a request for the intended use of the purchased servers to prevent any violation of the company's policies.
We request one of the following documents to verify the user's account:

1. Passport
2. Driver's license
3. ID card
4. Residence permit

This procedure is also accompanied with an extra step - **selfie with a document**.
Once all requested documents have been submitted, a decision will be made to either approve or reject the request.
During the ordering and payment process for services, the client may receive a request to undergo the KYT (Know Your Transactions) procedure.

## 2FA

Two-Factor Authentication (2FA) significantly enhances the security of your account.
A One Time Token is a token received from an authentication application (such as Google Authenticator).

### Enforcing Two-Factor Authentication (2FA)

The `owner` can force everyone to use 2FA. If this option is activated, it becomes mandatory for all users associated with the account, restricting all their actions until 2FA is enabled. After activation, users without 2FA receive an email instructing them to enable it. Only an authorized `owner` with 2FA enabled can unlock this security enhancement.
For new users, the 2FA activation is a mandatory step post-registration. They must enable 2FA before they can perform any operations in the account.

## SSH key

SSH key is a reliable and safe alternative for the password authentication. The SSH key is associated with the user and consists of a pair:

* **Closed key**: the private part stored on the PC
* **Open key**: the public part located on the server

In the Customer Portal, users can upload the public part of their SSH key or create a new key.
SSH keys store on the virtual machine even after the user has been removed.


# Data privacy and data portability (/docs/account/data-privacy)



This page answers common questions about how Servers.com handles personal data, complies with GDPR, and how you can access, download, or request deletion of your data.

### Which companies of Servers.com group comply with GDPR?

As our client, you are working with Servers.com B.V or Servers.com Inc., depending on where you or your company resides. Both of the aforementioned entities comply with GDPR.

Both Servers.com Inc and Servers.com B.V. as companies that may collect and process personal data of data subjects in the EEA are bound to comply and do comply with the GDPR. It should be noted that Servers.com Inc complies with the EU-U.S. Privacy Shield Framework set forth by the U.S. Department of Commerce regarding the collection, use, and retention of personal information transferred from the European Union to the United States. Servers Inc. has certified to the U.S. Department of Commerce that it adheres to the Privacy Shield Principles. More information on this can be found here in our [Privacy Policy](https://www.servers.com/privacy-policy).

### What has Servers.com done to comply with GDPR?

We have reviewed our current processes to ensure they meet the requirements of the GDPR and implemented appropriate safeguards to ensure the safekeeping of the personal data. More information on our processes and more can be found in our updated [Privacy Policy](https://www.servers.com/privacy-policy) and [Cookie Policy](https://www.servers.com/cookie-policy). Moreover we have implemented the [data processing agreement](https://www.servers.com/legal/personal-data-processing) for the provision of our services to the customer, which shall become binding upon written request by the customer.

### How can I access, and download my personal data? How can I request deletion of my personal data?

Name, company name, email address, telephone, credit card number, and other relevant data you provide during registration and later on the Servers.com platform is available in the **Profile** section of [Customer Portal](https://portal.servers.com/login). This is where you access, download or update the data. You can also deactivate your account right in the Portal or request deletion of your personal data by sending a request to [privacy@servers.com](mailto:privacy@servers.com).

### How can I download my data from the Servers.com services?

You can access and download data from your Dedicated Servers, Cloud Servers, and Cloud Storage using a common set of protocols and utilities, including but not limited to `rsync`, SSH, SFTP, and Openstack Swift API. The process of downloading your data is the same as any other file transfer operation you might already be familiar with.

### I have more questions or a request

Should you have any questions or related requests on our use of your personal data, please contact us at [privacy@servers.com](mailto:privacy@servers.com).


# Embargoed and sanctioned countries (/docs/account/embargoed-countries)



Servers.com does not provide services to individuals or entities located in countries or regions subject to comprehensive embargoes or sanctions.

**The following is a current list of countries/regions subject to comprehensive embargoes or sanctions:**

* Iran
* Cuba
* DPRK / Korea, North
* Sudan
* Crimea Region
* So-called DNR or LNR Regions of Ukraine
* Russia
* Belarus


# Enforce 2FA (/docs/account/enforce-2fa)



Corporate security policies may require all employees to have two-factor authentication (2FA) enabled. The Servers.com Customer Portal lets you enforce this requirement across your account using the **Enforce 2FA** option.

When enabled, all active and invited users are notified by email to set up 2FA. Until they do, their portal access is restricted:

* Account information is not displayed
* Left menu navigation is disabled
* Search and cart are unavailable

New users will be prompted to enable 2FA on every login, even when accessing multiple accounts.

## Getting started

To enable the Enforce 2FA option:

1. Go to [Account settings](https://portal.servers.com/account) → **Two-factor authentication** section
2. Click **Enforce 2FA**
3. Confirm by entering your account number and clicking **Enforce**

Only account owners can enable or disable this feature.

Once Enforce 2FA is disabled, 2FA remains active for all users until they individually disable it on the [User profile](https://portal.servers.com/profile) page → **Two-Factor Authentication (2FA)** section → **Disable 2FA**.

## Use cases

Two-Factor Authentication (2FA) adds a second verification step to the login process, making unauthorized access significantly harder. Below are the main scenarios where enabling 2FA on your account provides practical value.

### Compliance with corporate security policy

You can make two-factor authentication a mandatory part of your corporate security policy and enforce it for all account users directly from the Servers.com Customer Portal.

### Instant access restriction

If a team member leaves or a work device is lost, you can instantly secure the entire account by enabling 2FA. Current team members keep their access while unauthorized logins are blocked.

## Lost device

If you lose a device with a 2FA application, use one of these options:

* **Active browser session:** Go to the Customer Portal → **User profile** page → **Two-Factor Authentication (2FA)** section → **Update 2FA**.
* **No active session:** Contact the support team by submitting a ticket. They will guide you through the next steps.


# How to create an account (/docs/account/how-to-create-an-account)



Follow the steps below to register a new Servers.com account and complete the initial setup.

To create an account, complete the following steps:

1. Go to the Customer Portal
2. Click **Join** and follow the instructions. If you are already registered, enter your username and password and click **Sign in** to log into your account
3. Enter email address and specify how you heard about us
4. Read and agree to the Privacy Policy and Terms of Use
5. Click **Join**. The request to create the account will be sent to the Customer Portal
6. Verify your email within 24 hours by clicking the link in the received email. If you don't find the email in your inbox, please check your spam folder and ensure the email address is correct. If you haven't received the email, contact our support service.
7. Create a strong password using our guidelines on the page and click **Proceed**
8. Fill the form with information about the created account
9. Click **Save**
   Account will be created

### How to view or update your information

To view or update information within the created account:

1. On the Customer Portal page, select **Account settings** in the left-hand menu or click **Account name** in the top right corner of the page and select **Account email**.

   A window will open, presenting the following sections:

   * **Account** — information about the account
   * **Contacts** — contact management section
   * **Support access** — grant our support service temporary access to your account

2. Click **Edit** to edit or add information

3. Click **Save**


# Identity and Access Management (/docs/account/iam)









Identity and access management (IAM) is a set of processes, settings, and policies for account identities, authentication, and authorization. IAM allows you to organize access to Servers.com resources in accordance with your needs in a safe way.

The feature is available in the Customer Portal: **Identity and Access** → [**Management**](https://portal.servers.com/iam/management/users).

The IAM concept is built upon four terms: resource, resource group, permission policy, and team.

## Concepts

### Resources

A **resource** is a subject of identity and access management — for example, a server, an invoice, or a Kubernetes cluster. Each individual server counts as a separate resource. A resource may include child entities or specific operations, such as **DedicatedServersOOBAllowPublicAccess** — an action to grant public OOB access to a dedicated server.

A **resource group** is a set of resources grouped by a certain principle.

There are three resource types, defined by their ability to participate in a resource group:

* **Assignable to resource groups** — a countable resource that can be part of a group, for example, a dedicated server or a Kubernetes node.
* **Aggregative** — a resource that contains assignable resources within it. Aggregative resources cannot be assigned to a resource group themselves (for example, a Kubernetes cluster that consists of Kubernetes nodes).
* **Unassignable to resource groups** — an abstract or unaccountable resource that cannot be managed independently, for example, an account, invoices, or requests.

<img alt="Resource types diagram" src={__img0} />

An assignable resource must always belong to a resource group. By default, it is placed in the **default resource group**. Adding a resource to a custom group removes it from the default one.

<Callout>
  A resource can be a member of only one resource group.
</Callout>

### Permissions

A **permission** is the right to perform an action on a resource. The main permission types are:

* **Full access** — allows all operations on a resource
* **Read** — allows viewing data without the ability to edit a resource
* **Management** — allows resource creation, editing, and updating
* **Allow delete** — allows resources to be deleted
* **Allow \<action>** — allows a specific action

A **permission scope** is a group of entities united by a certain criteria that can be assigned with permissions.

| Scope          | Description                                                                                                  | Involved entities                                                                                                           |
| -------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |
| Administrative | Account management permissions                                                                               | Accounts, IAM                                                                                                               |
| Aggregative    | Permissions for aggregative resources                                                                        | L2 Segments, Firewalls, Kubernetes clusters, Load Balancers                                                                 |
| Billing        | Permissions for finance-related resources                                                                    | Orders, invoices, account statements, payments                                                                              |
| Resource-based | Permissions for group-assignable resources (selecting this scope enables the ability to add resource groups) | Dedicated/Cloud/SBM servers, Kubernetes nodes, Cloud Storage, Direct Connect, VPN2GPN, DNS, Private Racks, SSL certificates |
| Support        | Permissions for communication with the support team via Requests                                             | Requests                                                                                                                    |

A **permission setting** is a list of permissions associated with an entity from a permission scope.
A **permission policy** is a permission scope with configured settings.
<img alt="Permission policy diagram" src={__img1} />

| Permission policy                     | Description                                                                                                                                         | Permission scope               | Examples                                                        |
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------------------------------- |
| Default administrative policy         | Full access to account management and IAM. Intended for admins.                                                                                     | Administrative permissions     | Accounts, SSH/GPG keys, API tokens, IP allowlists, etc.         |
| Default billing policy                | Full access to all financial entities. Intended for accounting teams.                                                                               | Billing permissions            | Orders, invoices, payments, account statements, etc.            |
| Default support policy                | Access to Requests only, allowing users to communicate with technical support.                                                                      | Support permissions            | Requests                                                        |
| Default resource policy               | Full access to all technical resources.                                                                                                             | Permissions by resource scopes | EBM, cloud servers and storage, Kubernetes nodes, etc.          |
| Default resource read policy          | Read-only access to all technical resources. Typically assigned to the billing team when they need visibility into resources without managing them. | Permissions by resource scopes | EBM, cloud servers and storage, Kubernetes nodes, etc.          |
| Default aggregative policy            | Full access to aggregative resources that follow a resource → resource member structure.                                                            | Aggregative scope              | L2 Segments, Kubernetes clusters, Firewall, Load Balancer, etc. |
| Default aggregative read policy       | Read-only access to aggregative resources.                                                                                                          | Aggregative scope              | L2 Segments, Kubernetes clusters, Firewall, Load Balancer, etc. |
| Default technical connectivity policy | Full access to connection and encryption resources; read-only access to IP allowlists.                                                              | Administrative scope           | SSH keys, GPG keys, API keys, IP allowlists, etc.               |

### Export, import, duplication

Export and import let you transfer permission policies between accounts without rebuilding them from scratch. Duplication lets you quickly create a copy of an existing policy or team and adjust only what needs to change. Both features require a user to have the `IamFullAccess` permission.

#### Export permission policies

Go to **Customer Portal → Identity and Access → Management → Permission policies**, click the three-dot icon next to a policy, and select **Export**. A JSON file will be downloaded.
The file contains the:

* policy name
* scope
* permissions list
* source account number
* export timestamp

The filename follows this pattern:

```
<permission policy name><account_number><timestamp>.json
```

Example: `Default_aggregative_read_policy_1_2026-04-22T11-07-46-162Z.json`

#### Import permission policies

Go to **Customer Portal → Identity and Access → Management → Permission policies** and click **Import**. Upload the JSON file exported from another account. The system validates the file before applying it.

#### Duplicate permission policies

Go to **Customer Portal → Identity and Access → Management → Permission policies**, click the three-dot icon next to a policy, and select **Duplicate**. A copy appears in the list. The duplicated policy is not assigned to any teams automatically — you do this yourself.
The duplicate is named using this pattern:

```
<original name> - <timestamp in UTC>
```

Example: `Default aggregative read policy - 20260219121700`

#### Duplicate teams

Go to **Customer Portal → Identity and Access → Management → Teams**, click the three-dot icon next to a team, and select **Duplicate**. The new team is automatically assigned to the same permission policies and account members as the original.
The duplicate is named using the same pattern:

```
<original name> - <timestamp in UTC>
```

Example: `Administrators team - 20260422115931`

### Teams

A **team** is a group of users assigned with permission policies.
<img alt="Teams diagram" src={__img2} />

## Use cases

### Department-based account access

The most common IAM scenario is to create a team for each department and assign policies related only to their area of responsibility.

1. Create policies with the necessary permission scopes:
   * "Management policy" with the administrative permission scope
   * "Financial policy" with the billing permission scope
   * "Engineering policy" with aggregative, resource-based, and support permission scopes
2. Create a team for each department and add users:
   * "Management team" with C-level staff and team leaders
   * "Financial team" with accountants and financial managers
   * "Engineering team" with developers, administrators, and support
3. Assign policies to the corresponding teams:
   * Management policy to the management team
   * Financial policy to the financial team
   * Engineering policy to the engineering team

### Servers with restricted access

Sometimes department-based access is not enough and certain resources need to be restricted to just a few employees. For example, if you have several database servers that only certified employees are allowed to work with:

1. Create a resource group "DB servers" and add the necessary servers to it.
2. Create a policy "DB certified policy" with the resource-based permission scope and select the "DB servers" resource group.
3. Create a team "DB certified team", add users and the "DB certified policy".

### Transfer policies between accounts

Your organization uses two separate accounts — one for production and one for staging. The production account has several permission policies and team configurations that took time to set up. You now need to replicate the same structure in the staging account. Start by exporting each permission policy from the production account. Then switch to the staging account and import the files one by one.

## Getting started

This section guides you through configuring IAM correctly.

### Step 1–4: Resource group creation (optional)

This part is only needed if you want to use the resource-based permission scope. Otherwise, skip to step 5.

1. Go to the [**Resource groups**](https://portal.servers.com/iam/management/resource-groups) tab and click **+ Create**.
2. Give the group a name and description. Click **Save**.
3. Once the group is created, click it to open its details page.
4. On the details page, click **+ Add resource**, select the necessary resources, and click **Save**.

### Step 5–7: Permission policy creation

5. Go to the [**Permission policies**](https://portal.servers.com/iam/management/permissions) tab and click **+ Create**.
6. Give the policy a name and description, then select a **Permission scope**.
   When the **resource-based** scope is selected, you can add a resource group created in the previous steps. You will also see the **Select all resource groups and apply to new ones** checkbox — enabling it applies the policy to all existing resource groups and any new ones added later. Other permission scopes do not use resource groups.
7. In the **Permission settings** section, select the permissions for each entity within the scope. Click **Add**.

### Step 8–9: Team creation

8. Go to the [**Teams**](https://portal.servers.com/iam/management/teams) tab and click **+ Create**.
9. Give the team a name, select **Permission policies** and **Users**, then click **Save**.

All necessary entities for IAM are now configured.


# Accounts (/docs/account)



**Accounts** are the top-level entity in Servers.com, tying your services, users, and billing together. You control who has access, what they can do, and how they authenticate - from enforcing 2FA account-wide to restricting access by IP range and managing identity with fine-grained IAM policies.

* **User roles and permissions** - assign Owner, Manager, or custom roles to team members
* **Two-factor authentication** - enforce 2FA for every user in your account
* **IP allowlisting** - restrict portal and API access to trusted IP addresses only
* **Multi-account management** - switch between and manage multiple accounts from one login

<DocCards>
  <DocCard title="Concepts" description="Understand accounts, users, roles, API keys, and security features." href="/account/concepts/" />

  <DocCard title="IP Allowlist" description="Restrict portal and API access to specific IP addresses or ranges." href="/account/ip-allowlist/" />

  <DocCard title="Identity and Access Management" description="Set up fine-grained permissions with IAM teams and resource groups." href="/account/iam/" />

  <DocCard title="Multi-Accounts" description="Manage and switch between multiple accounts from a single login." href="/account/multi-accounts/" />
</DocCards>

<DocCards>
  <DocCard title="Account Management" description="Configure users, roles, contacts, and account settings." href="/account/account-management/" />

  <DocCard title="How to Create an Account" description="Register and set up a new Servers.com account." href="/account/how-to-create-an-account/" />
</DocCards>


# IP allowlist (/docs/account/ip-allowlist)



The IP allowlist is a feature that limits account access via the [Customer Portal](https://portal.servers.com/login) by allowing only specific networks.

This option can only be managed by an account owner and doesn't restrict access to other systems other than the Customer Portal (for example, access to the public API will remain).

This feature is located on the [account settings page](https://portal.servers.com/account) in the **IP allowlist** section.

### Use case

The IP allowlist can enhance account security. A typical scenario is to add your corporate VPN networks to the list, so only your employees will be able to log in to the Servers.com Customer Portal.

### Feature management

There are two groups of operations that you can perform within the IP allowlist: one group is related to the state management of the entire list and the other group serves for the listing network.

### IP allowlist management

You can apply one of these operations to an allowlist:

* **Activate** – all listed IP addresses and networks will be allowed to log in to the Customer Portal. Other networks will be restricted. If there is a running session and its IP is not listed, the user will be logged out.
* **Deactivate** – all restrictions will be lifted and any IP address will be allowed to log in to the account.

Therefore a list can have two states:

* **Active** – restrictions within the list are in effect.
* **Inactive** – restrictions are listed but not in effect.

### Networks management

You can manage networks within an allowlist by performing the following actions:

* Add
* Edit
* Delete

The allowlist is allowed to add or edit a comment while managing networks.

### Limitations

* The network format is IPv4 and IPv6 CIDR.
* You can't remove your current IP address/network if there is no other network containing the current IP address.\*
* Removing the last network containing a current IP address\* in an active list will deactivate it.

\*A current IP address is the one you are currently logged into the Customer Portal on.

### Prevent access blockage

Servers.com will offer to add your current IP address to the allowlist. However, make sure that you are always able to log in to the Customer Portal from the listed networks. Otherwise, access to the account may be lost.


# Multi-accounts (/docs/account/multi-accounts)



A user can be a member of multiple Servers.com accounts and switch between them without re-authenticating, taking on different roles in each. This page explains how to create and manage multiple accounts, switch between them, and control user access.

### Multi-accounts management

Managing multiple accounts lets you keep services, resources, and billing separate — for example, across different legal entities, regions, or teams. Each account operates independently with its own configuration and invoicing.

#### Create account

To create a new account, click the account name on the upper right of the screen and select the **Create new account** option. A newly created account will operate independently from the current one and will have its own services, resources and billing. The billing information is mandatory for a newly created account.

#### Shift between accounts

To switch to another account, click the account name on the upper right and select the necessary account. After switching to another account, you won't need to authorize again. When a user logs in, the last accessed account will be open.

#### Edit user

To manage the settings of a user regardless of an account, click the account name on the upper right and select the **User profile** option.

#### Revoke access

An account owner can revoke access for a specific user. If a user doesn't have another account, they won't be able to log in to the [Customer Portal](https://portal.servers.com/login).

### Use case

This feature may be useful for those who run several legal entities. For example, if you have two companies – let's say one in the US and another in Europe — you can create one account for your US legal entity being billed in USD, and another for your European company which invoices in EUR.


# Billing management (/docs/billing/billing-management)



This page covers the most common billing tasks available in the Customer Portal, including adding a billing contact, topping up your balance, downloading invoices, and managing payment settings.

### Add a billing contact

Adding a billing contact is used to receive important financial-related notifications.
To add a billing contact:

1. Go to the Customer Portal
2. In the left-hand menu, navigate to the **Account settings**
3. In the **Contacts** section, click **Create**
4. Fill in the contact fields and select **Billing** in the **Job role** row
5. Click **Create**

The billing contact will be created.

### Top up account

Topping up your account balance allows you to manage your finances and pay for services on time without the need to enter payment card details or go through the payment process each time.
To do this:

1. In the left-hand menu, click **Billing** and select **Top up balance**
2. Select your payment method and enter the amount you wish to top up your account balance with.
   You can securely save payment method details by checking the **Save payment method for recurring payments** box.
3. Click **Proceed**
4. Enter your payment method details, then click **Verify**

After the verification process, your account balance will be topped up with the specified amount.

### Pay for the dedicated server from the account balance

A dedicated server, as a pre-paid service, can be paid from the account balance.
When your account balance has sufficient funds to cover the monthly rental fee of the selected server, a payment method from your balance will become available as an option for payment.

### Download an invoice

An invoice contains detailed payment information regarding the services and products used. Customer Portal users can receive and download invoices for the selected period.
To download an invoice:

1. In the left-hand menu, navigate to **Billing** and select **Invoices**
2. In the **Period** row, select the desired period for which the invoices were issued, or use the search function
3. Click on the row corresponding to the required invoice
4. Click **Download** and choose the preferred invoice format

The invoice file will be saved.

In case you have any questions regarding an invoice:

1. Select the invoice as described above
2. Click **Contact sales**
3. Fill in the fields and click **Create**

Your request will be sent to the sales team.

### Paying for the invoice

Within each billing period, invoices are issued monthly and will need to be paid.
Payment can be made in a currency other than the invoice currency. In such cases, there may be a currency conversion fee charged by the bank.
To make a payment via bank transfer using the provided bank details:

1. Open the received invoice
2. Use the bank details provided at the bottom of the received invoice document

Upon successful payment, primary and billing contacts will receive the payment confirmation email.

### Change the currency

To change the currency in the account, follow these steps:

1. In the left-hand menu, navigate to the **Account settings**
2. In the **Account** section, click **Edit**
3. Select the desired currency in the **Currency** row and click **Save**

Your currency will be updated.

Please note that after the first successful transaction, you won't be able to change the currency yourself. In this case, you will need to contact support.

To contact support:

1. In the left-hand menu, navigate to **Requests** and click **Submit a new request**
2. In the opened form, describe why you need to change the currency and specify the desired currency
3. Click **Create**

A request to change the currency will be sent to the support team.


# How to add a payment method (/docs/billing/how-to-add-a-payment-method)



Adding a payment method allows you to manage payments and access the paid services using convenient and secure methods.
To add a new payment method, complete the following steps:

1. Open the Customer Portal and navigate to **Billing** → **Payment details**
2. If you have read and agreed to the company policy, select the checkbox
3. Confirm that you agree to save this payment method as your preferred option for recurring payments by selecting the checkbox
4. Click **Add new card**
5. Enter the payment method details and click **Verify**
   The payment method will be added to your account.


# Billing (/docs/billing)



**Billing** at Servers.com combines monthly invoicing with pre-paid and per-usage pricing across all your services. Invoices generate automatically on the first of each month, and you can pay by card, PayPal, or wire transfer — with recurring charges handled automatically.

<DocCards>
  <DocCard title="Overview" description="Understand billing periods, invoice types, payment methods, and tax policy." href="/billing/overview/" />

  <DocCard title="Billing API Reference" description="Manage invoices and billing programmatically via the REST API." href="https://developers.servers.com/api-documentation/v1/#tag/Invoice" />
</DocCards>

<DocCards>
  <DocCard title="Billing Management" description="View invoices, check account balance, and manage billing contacts." href="/billing/billing-management/" />

  <DocCard title="How to Add a Payment Method" description="Link a card, PayPal account, or wire transfer to your account." href="/billing/how-to-add-a-payment-method/" />
</DocCards>


# Overview (/docs/billing/overview)



Billing is the process of invoicing and accounting for provided billing services. It involves an automated process of calculating and recalculating service prices, payment monitoring, reminders, tracking outstanding balances and resolving disputes. Billing ensures transparency, accuracy, and timeliness in invoicing.

Standard billing methods include pre-paid services and services that are billed per usage.

## Tarification

We provide services that are billed in advance as well as services that are billed per usage within the billing period.

## Types of billing services

Pre-paid services are billed in advance for the upcoming month. Billed per usage services are calculated based on actual usage for the previous month.

### Pre-paid services:

* Dedicated servers and all their components
* Dedicated server racks
* Uplinks of dedicated servers
* Any additional equipment
* All licenses

### Services billed per usage for the previous month:

* Additional IP addresses and network
* L2 segment
* Load balancers traffic
* Firewall traffic
* Cloud servers
* Cloud storage
* Traffic overuse exceeding the included bandwidth in the dedicated or cloud server package
* Forex VPS

## Billing period

The **billing period** is one calendar month. The services usage cost is calculated and added to the invoice during the billing period. Invoices are issued on the first day of each month, regardless of the order date. It is valid for both pre-paid payments and payments based on actual usage.
When the services ordered on a date other than the first day of the month, a **partial billing period** is used for tarification. Pre-paid services ordered in the previous month will be billed for the entire usage period plus the advance payment for the upcoming month. Services billed per usage will be billed for the entire usage period only.

### Pre-paid services example

If a dedicated server has been ordered on January 15, the invoice will be calculated on February 1. It will include the charge for using the server from January 15 to January 31 and the charge for the whole next month.

### Services billed per usage example

If a dedicated server has been ordered on January 15, the invoice will be calculated on February 1 and will include the charge for using the server from January 15 to January 31.

## Invoice currency and sales tax policy

In most instances, the invoice currency corresponds to the payment currency selected during account registration in the Customer Portal before the first transaction. It is specified in the **Account settings** under the **Currency** field. This may differ from the service currency. In such cases, a conversion to the account currency will occur based on the exchange rate.
For the avoidance of doubt, customers with a U.S. billing address will, at all times, be invoiced in USD, regardless of the location of their services or the local currency of those services. Sales tax may be charged based on the applicable laws and regulations in the relevant state in each instance.
After the first transaction in the Customer Portal, changing the account currency is only possible by contacting technical support. Note this will not be possible for customers with US billing address.

### Exchange rates

The cost of billing services in currencies other than payment currency will be converted with the exchange rate on the first day of the previous calendar month.
For example, the invoice dated February 1 will use the currency exchange rate of January 1. The specific exchange rates will be indicated in the invoices.

### VAT and sales tax policy

Value Added Tax (VAT) is a consumption tax levied on selling goods or providing services in the European Union, the United Kingdom, and certain other jurisdictions. In the United States, applicable sales tax may also be levied based on the applicable laws and regulations in the relevant state.
VAT and sales tax are not included in the service prices listed on the Servers.com website or in the Customer Portal. Tax rates may be determined by taking into account a number of factors such as the customer's billing address etc.
If a customer is entitled to a reverse charge for VAT purposes the customer will need to provide a valid VAT number in the **Account settings** of the Customer Portal or appropriate exemption certificates.

## Invoices

The invoice is a document that lists the Servers.com billing services that have been used and ordered within a billing period.
Invoices are automatically generated on the first day of each month. The invoice includes all billing services consumed during the billing period, each listed as a separate line item and categorised as either pre-paid services or services billed per usage. Both types of services can be determined by the dates in the **Period** column on the invoice.
The invoice includes the following information:

* Billing period
* Due date
* Relevant service usage information:
  * Start date
  * End date
  * Service type
  * Quantity of units (may be represented as units or traffic)
* The price for the usage period in the service currency and in the final invoice currency
* Account owner details provided by them
* Servers.com company details issuing the invoice
* Tax rate, if applicable
* Conversion rates, if applicable
* Total amount to be paid
* Bank details for payment

### Invoice issuance stages

**A pending invoice (pro forma)** is a preliminary invoice that is generated automatically for the following month before the official invoice is issued. It can be found in the Customer Portal → **Billing** → **Invoices** if upcoming period is selected. This helps to track changes in the upcoming billing period due to ordering new billing services or cancelling existing ones.
A pending invoice is not a legally binding document and can be modified before the official invoice is issued.
**An invoice** is an officially issued invoice that must be paid by the due date specified in it. It has three statuses:

* Outstanding — an invoice issued for payment
* Paid — an invoice that has been fully paid after processing and acceptance of the payment
* Outdated — an overdue invoice, to be paid as soon as possible

## Payment methods

A payment method is the method used to pay for the billing services. We offer our clients various payment methods:

* Debit or credit card, physical or virtual
* PayPal
* Wire transfer

Paying by card or PayPal are the most convenient ways to pay for services. These methods allow for instant service ordering and payment, as well as automatic and immediate processing of recurring payments, ensuring uninterrupted service.
At the beginning of each month, funds will be automatically withdrawn as **recurring payments** from the account balance after the invoice is issued. If there are insufficient funds, the payment will be withdrawn from the linked payment method, specified on the **Payment methods** page of the Customer Portal.
However, if you prefer to make payments via wire transfer, you should contact customer support before ordering any services. They will explain the process and assist with the organizing of transfers.

### Payment rules and deadlines

Paying invoices for billing services are subject to certain rules and company policies.

* When ordering a dedicated server, the account balance must cover the monthly rental cost. Subsequent payments will be automatically charged to the account balance or the linked payment method.
* When ordering a cloud server, a payment card must be linked to your account. Prepayment for cloud server usage is not required.

The payment term is five days from the invoice date, meaning payment is due by the 5th of the current month. If you encounter difficulties paying the invoice on time, please contact the support team for assistance. We do not block services without prior notice.
In the event of a delayed payment or an outstanding balance more than 14 days after the invoice date, a late fee may be applied. In such situations, the billing department will contact the customer or their account manager (if any) in advance to address the payment issues. If payment is not made or communication is ignored, Servers.com reserves the right to suspend services without further notice. Services will remain suspended until full payment is received.
For more detailed information, please refer to general terms and conditions.

## Billing contact

By default, all notifications, including billing-related ones, will be sent to the email address provided during account registration. If you need to add additional contacts for billing notifications, you can do so in the Customer Portal.
The billing contact is an email address used to receive important notifications related to finances.
The billing contact receives:

* Notification of issued invoice
* Payment confirmation
* Notification of account balance top-up
* Reminder for upcoming payment due date
* Notification of overdue invoice
* Service suspension warning due to non-payment
* Notification of created credit note

Please note that billing contacts do not have access to the account or invoices; they will only receive notifications.
If you want them to access the Customer Portal, you can grant access with User Management.


# Troubleshooting (/docs/billing/troubleshooting)



Billing issues can range from incorrect invoice details to declined payments. This page covers the most common problems and how to resolve them — or who to contact when you need further help.

### Changing billing details after an issued invoice

If your billing details need to be updated after an invoice has been issued, follow these steps:

1. Contact our customer support as soon as possible and let us know about the changes needed for the invoice. We are ready to assist you in this process.
2. Provide us with the updated information that needs to be included in the invoice. We will update the details and send you the corrected or reissued invoice.
3. Check the amended invoice to ensure the information is correct.
   If you have any questions or need further assistance, please reach out to our [support team](https://www.servers.com/contact-us#support).
   Please note, changing the originating country of the transfer can sometimes lead to a change in the tax rate. These changes may reflect in the final amount on the invoice.

### Dispute charges

If there's a need to challenge specific payments on the statement or an unauthorized transaction, contact our [support team](https://www.servers.com/contact-us#support).

### Unable to add a credit card as payment method

If your credit card was declined, here are a few possible reasons:

* **The expiration date of the credit card has passed**: check the expiration date of your card and make sure the correct date is entered in the payment method.
* **The payment information was entered incorrectly**: ensure that the billing name, address, postal code, and CVV number of your credit card matches the information entered in our system. The CVV number is a three-digit code printed on the back of most credit and debit cards. For American Express cards, it is a four-digit code on the front of the card.
* **Browser's cache and cookies**: sometimes browser's cache errors from previous unsuccessful attempts and block transaction processing. Remove the payment method, clear your browser's cache and cookies, and then re-add the payment method.
* **The transaction time has expired**: if the payment service is busy processing other transactions, the waiting time for your transaction may expire. Don't worry, if the transaction times out, no withdrawals will be made from your card. If the transaction time has expired, try again in a couple of minutes.
* **The credit card has a low limit**: sometimes banks open new accounts with security limits to protect against fraud and may decline some purchases. Call the issuing bank to inquire whether you need to increase your spending limit.
* **Other cases**: if none of these steps help resolve the issue, contact your bank to find out why your card was declined. If you require further assistance, you can contact our technical support.

### PayPal payments are not going through

If you are using PayPal as a payment method and are encountering any payment issues, please contact PayPal support. If you require further assistance, you can contact our technical support.

### Declined transactions

Declined transactions is a potential reason for errors you may encounter when adding a payment method. In this case, we advise you to contact the issuer bank of your card to find out why the transaction was declined and inquire whether they can prevent the transaction from being blocked. Additionally, you can try adding your payment details using another credit or debit card.

### Not receiving payment emails

All payment emails are sent to the account contacts with primary and billing roles to the specified email address. If you notice that you are not receiving payment emails, you should first check your account settings and ensure that the email address for contact is correct. If the billing email address is correct, check your junk/spam folder. If you still haven't received the email, contact support for further assistance.

### Bank transfer payment was declined or returned

It's likely that the payment was made using outdated bank transfer payment details. In the event of any change in payment details, the Customer Portal automatically sends notifications to the account manager and contacts with primary and billing roles.
Please ensure that you're using the correct payment details from the latest invoice for making the payment to avoid any issues.

### The charge is too small

A small charge is a way to verify newly added credit and debit cards. For example, if you made a payment with your credit card and noticed a charge of only 1 euro on your card, don't worry. This charge is a common practice to verify newly added credit and debit cards. It's a standard procedure to ensure that the card is valid. The charge will eventually be refunded, and the correct amount for your transaction will be charged.


# Access management (/docs/cloud-servers/access-management)



Access to the cloud server is managed using the authentication method selected during server creation or reinstallation. The following authentication methods are available:

* Key-based authentication with the **cloud-user**
* Password authentication with the **root** user

Depending on the operating system, here are several methods for accessing a cloud server:

### SSH

SSH (Secure Shell) provides secure, encrypted network communication and is primarily used to access Linux-based cloud servers.
To connect, you'll need the server's IP address and credentials (password or private key). To retrieve this information:

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the cloud server
2. On the server details page, scroll down to the **Public IP** row and use the displayed IP address to connect
3. Use the private part of the SSH key that matches the fingerprint shown in the **SSH key** field

For more details, see the article [Connecting to a remote server via SSH](/tutorials/ssh-access/connecting-to-a-remote-server-via-ssh/).

### RDP

RDP (Remote Desktop Protocol) provides a graphical interface for managing Windows-based cloud servers. You can connect using the built-in remote desktop client in Windows or third-party RDP clients on other platforms.
To set the administrator password, access the VNC console after creating the server. Once the password is set, you can connect to the cloud server via RDP.
For more details, see the article [How to connect to a Windows server](/tutorials/windows-administration/connect-to-windows-server/).

### VNC console

The VNC console provides direct access to the current output of both Linux and Windows-based cloud servers through a graphical interface in a web browser. It is typically used for troubleshooting, server recovery, or resetting the root password (we do not store server passwords).
To access the VNC console, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the cloud server
2. Scroll down on the server details page and click **VNC console**
3. Enter your account password or a one-time code if two-factor authentication (2FA) is enabled

The VNC console will open.


# Billing (/docs/cloud-servers/billing)



Cloud Server is a postpaid service with hourly and monthly billing. Hourly option is advantageous for partial use of the Cloud Server, while monthly option is beneficial for Cloud Servers that operate continuously throughout the month. To start using the service, ensure you have an active payment method, such as a linked credit card, or add a payment method during the checkout process. Payment by wire transfer does not require adding a payment method.

The following related services are billed hourly:

1. Paid operating systems (e.g., Windows)
2. Volumes (available not in all locations)

Snapshots, backups, and images are stored in Cloud Storage. The cost depends on the amount of storage (in GB) per month.

Cloud Servers are listed in aggregate format on the issued invoice, with all compute resources and their costs combined into a single line per cloud region.

### Traffic

Each tariff plan includes a certain amount of traffic, which is specified on the order page. Any overage beyond the plan will be included in the invoice at the end of the month. Information about overages can be found in the [Reports](https://portal.servers.com/cloud-computing/reports) section on Customer Portal.

Traffic for Cloud Servers is aggregated within a single cloud region zone. This means that the total volume of included traffic across different servers in any proportions is accounted for within one cloud region zone. For example, there are two servers in Dallas: SSD.30 and SSD.50 with 2048 GB and 3072 GB of included traffic respectively. In this case, up to 5120 GB in total can be used on both servers without overage in that cloud region zone. Although formally, SSD.30 may have consumed more traffic than included in its plan. However, if the servers are used for less than a full month, the amount of included traffic will be provided proportionally to the time the servers were active.

Traffic between Cloud Servers and Cloud Storage is charged since it passes through the public network. A direct GPN connection between Cloud Servers and Cloud Storage is not available.

<Callout>
  Amsterdam location consists of four zones, in which traffic is aggregated separately, regardless of the fact that these zones are in the same location.
</Callout>

### Cancellation terms

The service can be canceled anytime by being removed. The billing stops at the end of the cancellation hour. The hour when a service was canceled is billed completely. Please note, switching off a server doesn't imply its cancellation.


# Concepts (/docs/cloud-servers/concepts)



Cloud Servers are virtual machines running on the OpenStack-based cloud platform. The primary technology behind Cloud Servers is virtualization, which divides the physical server's resources into multiple independent virtual machines. This allows for flexible computing power that can scale quickly based on demand, with pay-as-you-go pricing.

Each Cloud Server operates on hypervisors that efficiently distribute resources among multiple users, running on physical nodes (server hosts). Cloud Servers can be managed via the [Customer Portal](https://portal.servers.com/) or [Public API](https://developers.servers.com/api-documentation/v1/#tag/Cloud-Instance), and OpenStack API. Access to virtual machines is provided through SSH for Linux and RDP for Windows. If access is lost, you can regain control of your server using the VNC console, available in the Customer Portal.

Our Cloud Servers can also be managed via the OpenStack API, allowing seamless integration into existing infrastructures and process automation. This flexibility makes the service ideal for a variety of use cases, such as:

* Web hosting and web application development
* Testing and development environments
* Scaling business applications

### Cloud regions

Cloud regions are geographical areas that contain one or more data centers where Cloud Servers are hosted. Within a single geographical area, there may be multiple cloud regions. Data centers are available in Europe, America, and Asia. This geographical distribution reduces latency and optimizes performance for end-users based on their location. Available cloud regions can be viewed in the Customer Portal when ordering a Cloud Server.

### Cloud flavor

Cloud flavor is a predefined set of computing resources that define the configurations (e.g., `SSD.30`, `SSD.50`) of a Cloud Server, such as SSD storage, RAM, vCPUs, and a traffic package. Each flavor is designed for different needs, from small web applications to high-performance systems. Cloud flavors can be easily upgraded, allowing quick scaling without physical hardware changes.

### Cloud images

Cloud images include the operating system, configurations, software, and dependencies required to run applications or systems on the Cloud Server. You can use snapshots and backups as images, upload your own custom images or use the ones provided by Servers.com. Available operating systems are listed in the Customer Portal on the [Create Cloud Server](https://portal.servers.com/cloud-computing/editor?location_id=0) page. We recommend using the `qcow2` format, but Servers.com also supports other formats such as `raw`, `vhd`, `vhdx`, `vmdk`, `vdi`, and `ami`.

### Snapshots and backups

Snapshots and backups capture the current state of your Cloud Server and are stored as images, helping with data protection and recovery. With a snapshot or backup, you can create servers with identical configurations or restore previous server states.

* **Snapshot** — a manually created image that captures the cloud server's state at a specific moment for quick restoration.
* **Backup** — automatically created at regular intervals, stored as a series of several copies for ongoing protection.

Backup details:

* Backups are performed daily, whether the server is powered on or off.
  By default, last five backup copies are stored. This can be adjusted in the backup settings.
* The server remains available while the backup is in progress.
* Backup images are securely stored within the data center's infrastructure. Storage costs are calculated monthly based on usage, as described in the article [Cloud Storage billing](/cloud-storage/billing/).
* You can download backups and snapshots to your local computer via the Customer Portal or with the [Glance client](https://github.com/openstack/python-glanceclient).
* When a Cloud server is decommissioned, backups and snapshots remain.
* The first backup is created automatically after 12:00 AM UTC on the day after the server is launched. Backup times cannot be customized.

### Cloud volumes

Cloud volumes are additional block storage for Cloud Servers. These volumes are independent resources that can be easily attached to or moved between Cloud Servers within the same region. Once attached they function like connected storage devices, similar to disk drives, but more reliable.

### GPN

The Global Private Network (GPN) is our private network that provides high-speed and secure interactions between Dedicated servers across multiple continents. It ensures fast and safe data transfer between your servers without the need for additional tunneling or VPN configurations. This service is free of charge. Refer to the [GPN article](/gpn/).


# How to create and access a Linux-based cloud server via an SSH key (/docs/cloud-servers/creating-a-linux-based-cloud-server-and-accessing-it-via-an-ssh-key)

















To access a Linux-based server via an SSH key, you need to generate a key pair. The private part of the key is stored on the PC you connect from, and the public part is placed on the cloud server. You can generate the key pair on your PC and place the public part in the Customer Portal, or generate a key directly at portal.servers.com — in which case you will be given the private part of the key to save on your PC. Both options are described below.

## 1. Creating a key pair in OS

### 1.1. Guide for Windows users

[Download](https://the.earth.li/~sgtatham/putty/0.83/w32/) the Putty SSH client and the PuTTYgen private key generator. Start PuTTYgen, select **SSH-2 RSA**, click **Generate**, and move the mouse until the progress bar is full.
<img alt="PuTTYgen key generation" src={__img0} />
Enter and confirm a password. Save the key files in a safe place.
<img alt="PuTTYgen save key files" src={__img1} />
Select and copy the text of the public key as shown in the picture. For more information on how to add this key via your account at portal.servers.com, see [Adding the previously created key to portal.servers.com](#2-adding-the-previously-created-key-to-portalserverscom).
<img alt="PuTTYgen copy public key" src={__img2} />

### 1.2. Guide for macOS and Linux users

To generate an SSH RSA key pair, open the Terminal and run the following command:

```bash
ssh-keygen -t rsa -b 4096
```

Specify the path where you want to save your private SSH key, for example:

```
/home/youruser/.ssh/rsa_key
```

Then enter and confirm your password. While entering it you will not see the characters — this is expected:

```
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```

You should get a result similar to the following:

```
Your identification has been saved in /home/youruser/.ssh/rsa_key
Your public key has been saved in /home/youruser/.ssh/rsa_key.pub
```

The private key file `rsa_key` must be stored on your local computer.
To view the contents of your public key, run:

```bash
cat /home/youruser/.ssh/rsa_key.pub
```

A text similar to the following will appear on your screen:

```
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQ...
```

Copy this text for the next step. For more information on how to add this key via your account at portal.servers.com, see [Adding the previously created key to portal.servers.com](#2-adding-the-previously-created-key-to-portalserverscom).

## 2. Adding the previously created key to portal.servers.com

Log in to your account at [portal.servers.com](https://portal.servers.com/login).
Go to **Identity and Access** → **SSH & GPG keys**.
In the upper right corner, click **Create**.
Enter any name for your public key, tick the option **Use public SSH key**, paste the text of your public key in the field, and click **Create**.

## 3. Creating a new key in your personal account

Log in to your account at [portal.servers.com](https://portal.servers.com/login).
Go to **Identity and Access** → **SSH & GPG keys**.
Enter any name for your key, tick the option **Generate new SSH key**, and click **Create**.
In the new window, copy the private key and store it on your PC in a safe place. You will need this key to connect to the cloud server in the future. Click **Return to the list**.

## 4. Creating a Linux-based cloud server with SSH key access

Go to **Cloud Servers** → **Instances**.
Click **Create server**.
Choose the region, choose the appropriate Linux distribution, enter the name for your server. In **Authentication method**, select **SSH key**, select the previously created SSH key, and click **Create Cloud Server** at the bottom of the page.

## 5. Connecting to a Linux-based cloud server with SSH key access

### 5.1. Guide for Windows users

Open the Putty SSH client. Go to **Connection** → **SSH** → **Auth** and select your private key file.
<img alt="PuTTY Auth configuration" src={__img3} />
Go to **Connection** → **Data**. In the **Auto-login username** field, enter `cloud-user` (note that Linux usernames are case-sensitive).
<img alt="PuTTY auto-login username" src={__img4} />
Go to the **Session** tab. In the **Host Name** field, enter the external IP of your virtual machine. Select port **22**, which is the default port for SSH. Enter a session name and click **Save**. To connect, click **Open**.
<img alt="PuTTY session configuration" src={__img5} />
Enter the password for your key.
<img alt="PuTTY key password prompt" src={__img6} />
To get root user privileges, type:

```bash
sudo su -
```

### 5.2. Guide for macOS and Linux users

To connect from a macOS or Linux machine, open the Terminal and enter the following command:

```bash
ssh cloud-user@external_ip_of_machine -i /home/youruser/.ssh/rsa_key
```

Replace `external_ip_of_machine` with the external IP of your cloud server and `/home/youruser/.ssh/rsa_key` with the path to your private key.
To obtain root user privileges, type:

```bash
sudo su -
```


# Getting started (/docs/cloud-servers/getting-started)



In this section, we will guide you through the steps how to quickly and easily order a Cloud Server. Follow the instructions below to get started with your cloud infrastructure:

1. Log in to the [Customer Portal](https://portal.servers.com/) and navigate to **Cloud Servers** → **Instances** from the left-hand menu
2. Click **Create server**
3. In the **Location** field, select one of the available cloud regions
4. Configure your Cloud Server:
   * Choose the OS image — note that licenses for Windows Server OS are paid. The total hourly or monthly price, including the Windows license, will be displayed when you select Windows OS during the ordering process
   * In the **Configuration** field, choose a billing plan (per month/per hour) and select one of the available server configurations
   * Choose the authentication method: password authentication with the root user, and/or key-based authentication with the cloud-user
   * Specify whether backups should be created automatically
   * Select the necessary network features
   * Enter a server name. This name will help you distinguish between multiple servers and can be useful when contacting support
5. Click **Create Cloud Server**

Your Cloud Server will be created.


# Cloud Servers (/docs/cloud-servers)



**Cloud Servers** are OpenStack-powered virtual machines with flexible vCPU/RAM/storage flavors, daily automated backups, and private networking via the Global Private Network. Deploy in seconds from the portal, API, OpenStack API, or Terraform - and scale up or down without downtime.

* **Flexible flavors** - choose the right vCPU, RAM, and SSD combination for any workload
* **Snapshots and daily backups** - protect data with automated backups and manual snapshots
* **Private connectivity** - join servers across regions over the Global Private Network
* **Full automation** - manage via Public API, OpenStack API, Terraform, or the `srvctl` CLI

<DocCards>
  <DocCard title="Concepts" description="Understand flavors, images, snapshots, backups, and volumes." href="/cloud-servers/concepts/" />

  <DocCard title="Billing" description="See how Cloud Server pricing and cancellation terms work." href="/cloud-servers/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Deploy your first Cloud Server and connect to it." href="/cloud-servers/getting-started/" />

  <DocCard title="Access Management" description="Connect to your server via SSH, VNC, or RDP." href="/cloud-servers/access-management/" />

  <DocCard title="Service Management" description="Upgrade, reboot, rebuild, and delete Cloud Servers." href="/cloud-servers/service-management/" />

  <DocCard title="Snapshot and Backup" description="Create and restore snapshots and automated daily backups." href="/cloud-servers/snapshot-and-backup/" />
</DocCards>


# Limitations (/docs/cloud-servers/limitations)



Certain limitations and quotas are in place to protect the infrastructure, and ensure a high level of security and performance:

* **Downgrades are not possible.** Cloud Servers can only be upgraded to a more powerful plan, with the option to revert the upgrade within 72 hours.
* **Images are region-specific.** An image uploaded to one region can be used only for instances within that region.
* **Modifying individual resources is not supported.** Memory, vCPU, or disk configurations cannot be modified independently. For additional storage, you can attach a virtual drive to the Cloud Server.
* **Only one public IPv4 address is provided.** Each Cloud Server is limited to a single public IPv4 address. Alias addresses are not supported, but an IPv6 address can be ordered separately.
* **Operating system reinstallation can be done only to the same type.** Reinstallation can be performed only from Linux to Linux or from Windows to Windows.
* **User data can be accessed only via the Public API.** Managing and injecting user-specific data into cloud instances can be done only through the [Public API](https://developers.servers.com/api-documentation/v1/#tag/Cloud-Instance).

### Quotas

By default, the following quotas are applied per account:

* 3 Cloud Servers per region
* 192 GB of RAM per region
* No more than 10 servers per account
* Global Private Network (GPN) is available when at least one Dedicated Server is ordered


# OpenStack API credentials (/docs/cloud-servers/openstack-api-credentials)



Servers.com allows you to manage your cloud servers and storage via OpenStack API. This article describes how to get started with OpenStack API and avoid exceeding OpenStack rate limits.

## Get Keystone credentials

Keystone is an OpenStack component responsible for authentication and authorization within the cloud platform. When using OpenStack API, you'll need to authorize via Keystone using its credentials. Servers.com uses Keystone v3.
To get credentials, go to **Cloud Servers** → **Instances** → **Show credentials**, select **Location**. Credentials are valid within a single cloud region.
You will need the following variables:

* API URL (e.g., `https://<keystone_host>:5000/v3`)
* User name (e.g., `OS_USERNAME`)
* Tenant name (e.g., `OS_PROJECT_NAME` / `OS_TENANT_NAME`)
* Password (e.g., `OS_PASSWORD`)
  Additional parameters that are not shown in the **Credentials** window but are required in Keystone:
* User domain (e.g., `OS_USER_DOMAIN_NAME`) — set the `default` value
* Project domain (e.g., `OS_PROJECT_DOMAIN_NAME`) — set the `default` value

## Get Keystone token

Authentication into Keystone is performed by getting a token that allows you to perform actions within OpenStack. A token is requested via an API request with the following structure:

* **Method:** `POST`
* **Endpoint:** `<OS_AUTH_URL>/auth/tokens`
* **Request headers:** `Content-Type: application/json`

**Request body:**

```json
{
  "auth": {
    "identity": {
      "methods": ["password"],
      "password": {
        "user": {
          "name": "<User name>",
          "domain": { "name": "default" },
          "password": "<Password>"
        }
      }
    },
    "scope": {
      "project": {
        "name": "<Tenant name>",
        "domain": { "name": "default" }
      }
    }
  }
}
```

There are several methods and tools you can use to get a token:

### cURL request

You can generate a token using cURL by making a POST request to the API endpoint obtained from the Keystone credentials:

```bash
curl -i -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "auth": {
      "identity": {
        "methods": ["password"],
        "password": {
          "user": {
            "name": "<User name>",
            "domain": { "name": "default" },
            "password": "<Password>"
          }
        }
      },
      "scope": {
        "project": {
          "name": "<Tenant name>",
          "domain": { "name": "default" }
        }
      }
    }
  }' \
  https://<keystone_host>:5000/v3/auth/tokens
```

Once you've made a successful request, you will get a response with a Fernet token in the **X-Subject-Token** header. You will also see its expiration time in the `expires_at` parameter.

### OpenStack SDK (Python)

OpenStack SDK automatically retrieves and renews a token. To set it up, follow these steps:

1. Install the library:

   ```bash
   pip install openstacksdk
   ```

2. Create a `clouds.yaml` file with the following content:
   ```yaml
   clouds:
     mycloud:
       auth:
         auth_url: https://<keystone_host>:5000/v3
         username: <User name>
         password: <Password>
         project_name: <Tenant name>
         user_domain_name: default
         project_domain_name: default
       region_name: <region_name>
       interface: public
   ```
   You can find the region name in the Customer Portal: **Cloud Storage** → **Access credentials** → **Shell variables** → `OS_REGION_NAME` value.

3. To create a connection with OpenStack, insert the following lines into your Python code:
   ```python
   from openstack import connection
   conn = connection.Connection(cloud='mycloud')
   ```

### OpenStack client (CLI)

To get a token via the OpenStack client:

1. In the Customer Portal, go to **Cloud Servers** → **Instances** → **Show credentials**, select **Location**.
2. Create the `openrc.sh` file and insert the variables from the previous step:
   ```bash
   export OS_AUTH_URL=https://auth.servers.%location_id%.cloud.servers.com:5000/v3/
   export OS_IMAGE_URL=https://images.servers.%location_id%.cloud.servers.com:9292
   export OS_TENANT_NAME=XXX
   export OS_USERNAME=YYY
   export OS_PASSWORD=ZZZ
   export OS_IDENTITY_API_VERSION=3
   export OS_DEFAULT_DOMAIN_NAME=default
   ```
3. Load the environment variables by running the following command in the terminal:
   ```bash
   source openrc.sh
   ```
4. Run any OpenStack command to verify it works, for example:
   ```bash
   openstack server list
   ```

## Limitations

Servers.com OpenStack platform has the following limitations:

* Servers.com OpenStack uses v3 Keystone — other versions are not supported
* A token is valid for 24 hours
* There are rate limits for Keystone authentication — refer to the [Rate limits](#rate-limits) section to optimize your request consumption

## Token recommendations

Follow these recommendations to ensure secure token usage:

* Store the token securely in a protected variable or configuration
* Do not log the token or store it in version control systems
* Applications should monitor token expiration and refresh it in advance
* Do not store passwords and tokens in plain text
* Use secure storage solutions (e.g., HashiCorp Vault, AWS Secrets Manager)

## Rate limits

For security reasons, Servers.com imposes limits on the number of authentication requests you can make in Keystone. Use the following recommendations to prevent request overuse:

* **Token reuse:** don't request a new token for every action — use one token until it expires
* **Token caching:**
  * In your code, start the token refresh process 1 hour before expiration
  * If a token is used every minute in parallel processes, requests made 5 minutes before expiration will reliably refresh the token
  * The optimal refresh interval is every 12 hours (half the token lifetime)
* **Limiting parallel authentication requests:** use a shared token in multi-threaded processes instead of a separate token for each thread
* **Handling rate-limiting errors:** implement an exponential backoff mechanism in case of a `429 Too Many Requests` error


# Power management (/docs/cloud-servers/power-management)



You can manage the power state of your active cloud server. To check its current status, navigate to the cloud server details page and scroll to the **Status** row.

To reboot or power off the server, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, go to the **Power** tab and click the appropriate button
3. Confirm the action by entering your account password

The power state of your active cloud server will be switched.


# How to prepare your own OS image and deploy it on a cloud server (/docs/cloud-servers/prepare-os-image-deploy-on-cloud-server)



You can deploy a cloud server from your own custom image. This is useful when you need:

* An operating system that is not yet available among our ready-to-use images in the Customer Portal
* A preconfigured image with your own software and settings

For the purpose of this article, images are grouped into two categories:

* **Cloud-compatible images** — provided by the OS vendor for cloud environments. They typically include the required drivers, cloud-init support, and OpenStack compatibility.
* **Non-cloud images** — generic images, such as ISO-based installers, that require additional configuration before they can run properly in an OpenStack-based cloud.

This guide covers how to create, customize, and prepare a virtual machine (VM) image and then upload it to the Customer Portal to deploy a cloud server. It walks through three scenarios:

1. Deploying a cloud server using a cloud-compatible image without modifications (as-is)
2. Preparing and customizing a cloud-compatible image before uploading
3. Preparing a non-cloud image (for example, from an ISO file) to make it OpenStack-compatible

This article does not cover the operating system installation process.

## Prerequisites

* Customer Portal account
* [Added SSH key](/account/account-management/) to the Customer Portal (required only if you plan to use key-based authentication)
* Local machine (Windows, Linux, or macOS)
* Installed virtualization software (we use QEMU in examples)
* Source OS image

## Image requirements

Our cloud services are built on OpenStack. You can configure all parameters and applications as needed, and ensure your VM meets the following core OpenStack image requirements:

| Requirement                     | Linux                                                                                                                                                                   | FreeBSD                                                                                                                                                                                                | OpenBSD                                                                                                             | NetBSD                                                                                                                     |
| ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| Architecture                    | x64 OS                                                                                                                                                                  | x64 OS                                                                                                                                                                                                 | x64 OS                                                                                                              | x64 OS                                                                                                                     |
| Image format                    | `qcow2` (recommended)                                                                                                                                                   | `qcow2` (recommended)                                                                                                                                                                                  | `qcow2` (recommended)                                                                                               | `qcow2` (recommended)                                                                                                      |
| Boot firmware                   | Only BIOS (UEFI not supported)                                                                                                                                          | Only BIOS (UEFI not supported)                                                                                                                                                                         | Only BIOS (UEFI not supported)                                                                                      | Only BIOS (UEFI not supported)                                                                                             |
| Disk layout                     | Use the standard disk layout from your distribution's cloud images. Enable automatic root expansion on first boot with cloud-init's `growpart` and `resizefs` modules.  | Use GPT with two partitions. First: `freebsd-boot` (≈64 KB, no mount point). Second: `freebsd-ufs` mounted as `/`. Root partition must be last on disk. Required for auto-resize with `bsd-cloudinit`. | Use GPT with the root partition placed last on disk. Auto-grow supported via `growfs` in OpenBSD 7.3+.              | Use GPT (recommended). Automatic root expansion is not supported; resizing requires manual steps: `gpt resize` + `growfs`. |
| No hard-coded networking        | Use DHCP; remove any static IP and MAC assignments from network config files (e.g., `/etc/network/interfaces`, `/etc/netplan/*.yaml`).                                  | Use DHCP on `vtnet0`; remove static network config from `/etc/rc.conf`.                                                                                                                                | Use DHCP on `vio0`; remove static config from `/etc/hostname.*` files.                                              | Use DHCP on `vioif0`; remove static config from `/etc/ifconfig.*` files.                                                   |
| Configured remote access        | Ensure SSH server is enabled and starts on boot.                                                                                                                        | Ensure `sshd` is enabled. `bsd-cloudinit` injects SSH keys automatically.                                                                                                                              | `sshd` is enabled by default.                                                                                       | Ensure `sshd` is enabled. Root SSH login may be disabled by default.                                                       |
| Hypervisor/driver compatibility | Modern Linux distributions include all necessary virtio drivers. Very old kernels (pre-3.0) may require adding virtio and network drivers. Legacy Xen-PV is not needed. | Ensure virtio disk and network drivers are enabled and `comconsole` is configured. Verify the image boots correctly under KVM/QEMU.                                                                    | Ensure virtio disk (`vioblk`) and network (`vio`) drivers are supported. Virtio is fully supported in OpenBSD 5.3+. | Ensure basic virtio disk and network support `virtio(4)` is available.                                                     |
| Image size                      | Upload size: ≤ 5 GB                                                                                                                                                     | Upload size: ≤ 5 GB                                                                                                                                                                                    | Upload size: ≤ 5 GB                                                                                                 | Upload size: ≤ 5 GB                                                                                                        |

For the complete list of requirements, see the [OpenStack Image Guide](https://docs.openstack.org/image-guide/openstack-images.html).

### Cloud-init compatibility

Cloud-init supports a wide range of Linux and BSD distributions. For the list of supported platforms, see: [https://docs.cloud-init.io/en/latest/reference/availability.html](https://docs.cloud-init.io/en/latest/reference/availability.html).

You can find unofficial BSD images that include cloud-init and have been tested on OpenStack at: [https://bsd-cloud-image.org/](https://bsd-cloud-image.org/).

## Installing QEMU

In this guide we use QEMU, a free and open-source cross-platform virtualization environment.

QEMU is required only if you plan to customize an image ([Case 2](#case-2-deploying-from-a-cloud-compatible-image-with-customization)) or prepare a non-cloud-compatible ISO ([Case 3](#case-3-deploying-from-a-non-cloud-compatible-iso-image)).

If you want to deploy a vendor-provided cloud image as-is ([Case 1](#case-1-deploying-from-a-cloud-compatible-image-without-customization-as-is)), you can skip this section.

**Ubuntu/Linux**

```bash
sudo apt-get install qemu-system
```

**Fedora**

```bash
sudo dnf install qemu qemu-kvm
# or
dnf install @virtualization
```

**Red Hat/CentOS**

```bash
sudo yum install qemu qemu-kvm
```

**SUSE**

```bash
zypper install qemu
```

**Arch Linux**

```bash
sudo pacman -S qemu
```

**macOS** (Homebrew)

```bash
brew install qemu
```

**macOS** (MacPorts)

```bash
sudo port install qemu
```

**Windows** (PowerShell, run as administrator)

```powershell
winget install SoftwareFreedomConservancy.QEMU
```

Or use a ready-made [installer for Windows](https://qemu.weilnetz.de/w64/).

## Cloud-init setup

Cloud-init is a cross-platform tool used to initialize a virtual machine during its first boot and apply configuration through metadata. Typical tasks include setting the hostname, configuring networking, adding SSH keys, creating users, and running initialization commands or scripts.

### Cloud-init configuration files

To provide initialization data when preparing an image locally, this guide uses a small ISO file called `seed.iso`. During the first boot, cloud-init reads the contents of this ISO and applies the defined settings.
The ISO contains two files:

* `user-data` — defines users, SSH keys, and other initialization settings
* `meta-data` — specifies basic instance parameters, such as hostname
  Create two plain text files named `user-data` and `meta-data` (without file extensions) in the same directory before building the ISO.

Example `user-data`:

```yaml
#cloud-config
users:
  - name: cloud-user
    shell: /bin/bash
    groups: sudo
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - INSERT_YOUR_SSH_KEY_HERE

  - name: admin
    shell: /bin/bash
    groups: sudo
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - INSERT_YOUR_SSH_KEY_HERE

ssh_pwauth: false
hostname: fedora-vm
```

In the example above, `ssh_pwauth` is set to `false` to allow authentication only with SSH keys. Setting it to `true` can be helpful during testing. Before uploading your prepared image to the Customer Portal, make sure to disable password authentication again and rely on SSH keys only.

Example `meta-data`:

```yaml
local-hostname: fedora-vm
```

Specifying `local-hostname` in `meta-data` is sufficient; `instance-id` is generated automatically by cloud-init.

### Build the seed.iso

Use one of the supported tools to generate a compatible ISO. The recommended method is `cloud-localds`. If not available, use `mkisofs` or `genisoimage`.

**Linux / macOS** (run in the directory containing the files)

```bash
cloud-localds seed.iso user-data meta-data
```

Alternatives:

```bash
mkisofs -output seed.iso -volid cidata -joliet -rock user-data meta-data
# or
genisoimage -output cidata.iso -volid cidata -joliet -rock -graft-points user-data=./user-data meta-data=./meta-data
```

**Windows**

1. Install the [Windows Assessment and Deployment Kit (Windows ADK)](https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install), selecting only the **Deployment Tools** component.
2. Run the following command:

   ```bat
   C:\path-to-oscdimg-exe-file -j1 -lcidata C:\path-to-cloud-init-config-files .\seed.iso
   ```

   `oscdimg.exe` is typically located at:
   `%ProgramFiles(x86)%\Windows Kits\<Windows version>\Assessment and Deployment Kit\Deployment Tools\<architecture>\Oscdimg\oscdimg.exe`

A `seed.iso` file will be created in the same directory.

## Launching a VM with QEMU

Start the virtual machine with your OS image and `seed.iso` attached.

Note the parameter `-netdev user,id=net0,hostfwd=tcp::2222-:22` — it maps host port `2222` to port `22` inside the VM. You will use this forwarded port to connect to the VM after it boots.

Use `-m` and `-smp` to set memory and vCPUs to match the configuration you plan to use on the cloud server.

**Linux**

```bash
qemu-system-x86_64 \
  -m 2048 -smp 2 \
  -drive file=cloud-image.qcow2,format=qcow2,if=virtio \
  -drive file=seed.iso,format=raw,if=virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device virtio-net,netdev=net0 \
  -nographic
```

For subsequent boots, remove the line `-drive file=seed.iso,format=raw,if=virtio`.

**macOS**

```bash
qemu-system-x86_64 \
  -accel tcg,thread=multi \
  -m 2048 -smp 2 \
  -drive file=generic_alpine.qcow2,format=qcow2,if=virtio \
  -cdrom seed.iso \
  -device virtio-net-pci,netdev=n1 \
  -netdev user,id=n1,hostfwd=tcp::2222-:22 \
  -nographic
```

For subsequent boots, remove the line `-cdrom seed.iso`.

**Windows** (run from `%ProgramFiles%\qemu`)

```bat
.\qemu-system-x86_64.exe ^
  -m 2048 -smp 2 ^
  -drive file=<C:\path-to-cloud-image.qcow2>,format=qcow2,if=virtio ^
  -cdrom <C:\path-to-seed.iso> ^
  -device virtio-net-pci,netdev=n1 ^
  -netdev user,id=n1,hostfwd=tcp::2222-:22
```

For subsequent boots, remove the line `-cdrom <C:\path-to-seed.iso>`.

### Check applied configuration

After the VM starts, connect to it via SSH:

```bash
ssh -p 2222 <user>@localhost
```

To verify cloud-init behavior, run:

```bash
cloud-init status --long
```

On non-cloud ISO images, this command often shows `status: disabled` — this is expected during local testing. After uploading the image and deploying a cloud server, our provisioning system provides the proper OpenStack datasource, and cloud-init runs normally.

## Case 1: Deploying from a cloud-compatible image without customization (as is)

You can deploy a cloud server directly from a vendor-provided cloud-compatible image without creating a local VM first. To do this:

1. Download the vendor cloud image.
2. Upload the image to the Customer Portal and create a cloud server (see [Uploading the image to the Customer Portal](#uploading-the-image-to-the-customer-portal)).
3. Connect via SSH as the default user preinstalled in the image (see [Default users in vendor-provided cloud images](#default-users-in-vendor-provided-cloud-images)).
   For Alpine, this is `alpine`:

   ```bash
   ssh alpine@<cloud_server_public_ip>
   ```

Some cloud-compatible images come with only a minimal default user. After deploying, create a separate privileged account for further work.

**Example: Creating a privileged user after deploying from an Alpine cloud image**

1. Switch to root:

   ```bash
   doas -s
   ```

2. Install and configure sudo:

   ```bash
   apk update
   apk add sudo
   adduser alpine wheel
   ```

3. Create a new administrative user:

   ```bash
   adduser cloud-user
   adduser cloud-user wheel
   ```

4. Configure SSH access for the new user:

   ```bash
   mkdir -p /home/cloud-user/.ssh
   echo 'ssh-rsa your_public_SSH_key' > /home/cloud-user/.ssh/authorized_keys
   chmod 700 /home/cloud-user/.ssh
   chmod 600 /home/cloud-user/.ssh/authorized_keys
   chown -R cloud-user:cloud-user /home/cloud-user/.ssh
   ```

5. Edit SSH configuration. Open `/etc/ssh/sshd_config` (install nano if needed: `apk add nano`) and ensure these lines are present and uncommented:

   ```
   PubkeyAuthentication yes
   PasswordAuthentication no
   ```

   Also check `/etc/shadow` and ensure the line for `cloud-user` does not contain `"!"`. If it does, replace it with:

   ```
   cloud-user:*:::::::
   ```

6. Restart the SSH service:

   ```bash
   rc-service sshd restart
   ```

7. Connect from your local machine as the new user:

   ```bash
   ssh admin@<server_ip>
   ```

## Case 2: Deploying from a cloud-compatible image with customization

This section explains how to customize a vendor-provided cloud-compatible image before uploading it to the Customer Portal.

1. Download the vendor's cloud image.
2. Create cloud-init configuration (`user-data` and `meta-data`) and generate `seed.iso` — see [Cloud-init setup](#cloud-init-setup).
3. Start the VM with QEMU, attaching `seed.iso` so cloud-init applies your configuration on first boot — see [Launching a VM with QEMU](#launching-a-vm-with-qemu).
4. Inside the VM, install and configure the guest OS as needed.
5. Verify the VM meets the [Image requirements](#image-requirements).
6. Shut down the VM and optimize the image — see [Preparing the image for upload](#preparing-the-image-for-upload).
7. Upload the image to the Customer Portal and deploy a cloud server — see [Uploading the image to the Customer Portal](#uploading-the-image-to-the-customer-portal).

## Case 3: Deploying from a non-cloud-compatible ISO image

This section covers preparing a VM created from an ISO image that does not include cloud-init or any cloud-specific configuration. The goal is to make the image boot correctly in OpenStack and accept initialization metadata during the first launch.

If you already have the OS installed in your VM, skip ahead to verifying that the SSH server is installed and running.

### Create a local virtual disk

When installing from an ISO, you must first create a virtual disk (the ISO is not a disk image). Choose a `<disk-size>` that fits your OS installation requirements (for example, `4G`).

**Linux / macOS**

```bash
qemu-img create -f qcow2 path-to-cloud-image.qcow2 <disk-size>
```

**Windows** (from `%ProgramFiles%\qemu`)

```bat
.\qemu-img.exe create -f qcow2 C:\path-to-cloud-image.qcow2 <disk-size>
```

### Start QEMU with the OS installation ISO

The first boot must use the installation ISO (for example, `ubuntu-25.10-live-server-amd64.iso`). Attach it as a virtual CD-ROM device — see [Launching a VM with QEMU](#launching-a-vm-with-qemu):

```bash
...
-cdrom ubuntu-25.10-live-server-amd64.iso \
-boot order=d \
...
```

### Install and configure the guest OS as needed

Cloud-init does not require a "clean" system. Your ISO-based image may already contain installed packages, system users, pre-configured services, etc.

### Restart the VM without the installation ISO and `boot order=d`

After the OS is installed, the VM must boot from its virtual disk instead of the CD-ROM.

### Make sure the SSH server is installed and running

```bash
sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh
```

### Install cloud-init and disk auto-expansion utilities

**RPM-based**

```bash
sudo dnf install -y cloud-init
sudo systemctl enable cloud-init
```

**Debian-based**

```bash
sudo apt update
sudo apt install -y cloud-init
sudo systemctl enable cloud-init
```

### Configure cloud-init datasources

1. Create a configuration file in the VM at `/etc/cloud/cloud.cfg.d/99-openstack-datasource.cfg`.

2. Add the following content:

   ```
   datasource_list: [NoCloud, Ec2, ConfigDrive]
   ```

### Apply cloud-init metadata and start QEMU

Attach the previously created `seed.iso` — see [Cloud-init setup](#cloud-init-setup). Cloud-init reads it as a NoCloud datasource and applies the configuration from `user-data` and `meta-data` during the first boot. After initialization, `seed.iso` can be removed for all subsequent VM launches.

### Verify the disk layout and auto-expansion

* Make sure the disk layout is simple (a single root partition, as created by the default Ubuntu installer).
* Check that `growpart` and `resizefs` are present in the module lists in `/etc/cloud/cloud.cfg`:

```bash
grep -A3 -i growpart /etc/cloud/cloud.cfg
grep -A3 -i resizefs /etc/cloud/cloud.cfg
```

### Remove hard-coded network settings

For modern Ubuntu (netplan):

* Check `/etc/netplan/*.yaml` and make sure `dhcp4: true` is used.
* There must be no static IP, MAC address, or interface names tied to a specific MAC.

If the file `70-persistent-net.rules` exists, remove it:

```bash
rm /etc/udev/rules.d/70-persistent-net.rules
```

### Do a final cleanup

Remove VM-specific state and temporary data:

* Clear cloud-init state (`/var/lib/cloud`)
* Remove permanently baked-in SSH host keys (so new ones are generated on first boot)
* Remove user `~/.ssh/authorized_keys` files (keys will be injected through cloud-init)
* Disable the firewall

## Preparing the image for upload

### Remove cloud-init state

**Linux and FreeBSD/BSD**

```bash
sudo cloud-init clean --logs
sudo rm -rf /var/lib/cloud/*
```

For Ubuntu/Debian, confirm that `/etc/cloud/cloud.cfg.d/*.cfg` does not contain test-specific datasource overrides.

### Delete VM-specific artifacts

**Linux**

```bash
# Delete SSH host keys
sudo rm -f /etc/ssh/ssh_host_*

# Remove temporary authorized_keys added during local testing
sudo rm -f /home/*/.ssh/authorized_keys
sudo rm -f /root/.ssh/authorized_keys

# Remove persistent network rules, if present
sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
```

**FreeBSD / BSD**

```bash
sudo rm /etc/ssh/ssh_host_*
sudo rm -rf /var/db/cloud/*
```

### Shut down the VM cleanly

**Linux**

```bash
sudo shutdown -h now
```

**FreeBSD / BSD**

```bash
sudo shutdown -p now
```

### (Optional) Optimize and compress the image

The target size limit in the Customer Portal is 5 GB.

```bash
qemu-img convert -O qcow2 -c original.qcow2 optimized.qcow2
```

Check the resulting size:

```bash
qemu-img info optimized.qcow2
```

## Uploading the image to the Customer Portal

We recommend disabling any VPN when uploading an image. If uploading fails, try restarting the process. If the issue persists, contact our [support team](https://www.servers.com/contact-us#support).

1. Upload your image to the Customer Portal (see [How to upload your own image](/cloud-servers/service-management/)), selecting the same location where you plan to deploy the cloud server.
2. Create a cloud server (see [Getting Started](/cloud-servers/getting-started/)). In the **Image** section, select **Other** and choose your uploaded custom image. Use SSH authentication with the key that matches the public key in your `user-data`.

Wait for the cloud server to deploy and obtain a public IP address from the server's details page.

## Default users and access

Access to the deployed server depends on the operating system in the image. SSH access with `root` is disabled in most vendor images by default.

When a cloud server is provisioned from a custom image, the `cloud-user` is created and the SSH key you selected during server creation is injected into `~/.ssh/authorized_keys`.

Default users in vendor-provided cloud images:

| Distribution | Default user |
| ------------ | ------------ |
| Ubuntu       | `ubuntu`     |
| Debian       | `debian`     |
| Fedora       | `fedora`     |
| AlmaLinux    | `almalinux`  |
| Alpine Linux | `alpine`     |
| RHEL         | `cloud-user` |
| openSUSE     | `opensuse`   |
| FreeBSD      | `freebsd`    |
| OpenBSD      | `openbsd`    |
| NetBSD       | `netbsd`     |


# Service management (/docs/cloud-servers/service-management)



This article describes how to manage cloud servers through the Customer Portal — including upgrading to a more powerful plan, confirming or reverting an upgrade, deleting a server, uploading a custom image, and viewing preliminary billing information.

### How to upgrade a cloud server

A cloud server can be upgraded to a more powerful plan.
To upgrade the cloud server configuration, complete the following steps:

1. Navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, go to the **Upgrade** tab
3. Choose a configuration from the available options and click **Upgrade**
4. Confirm the action by entering your account password
5. Wait for the upgrade to complete

The cloud server will be upgraded.

### Upgrade confirmation

The server will be available for operations as soon as the upgrade is complete, regardless of whether you confirm the upgrade.

You have 72 hours to confirm or revert the upgrade after completion. If no action is taken within this period, the upgrade will be confirmed automatically.

<Callout>
  Please note that if the upgrade is reverted, any data added to the server after the upgrade will be lost.
</Callout>

To confirm the server upgrade, complete the following steps:

1. On the server details page, click **Awaiting confirmation**
2. Click **Confirm Upgrade**

The upgrade will be confirmed.

### How to delete a cloud server

Before deleting a cloud server, review the [cancellation terms](/cloud-servers/billing/#cancellation-terms).

To delete a cloud server, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, go to the **Destroy** tab and click **Destroy**
3. In the confirmation window, click **Destroy** again and enter your account password

The cloud server will be deleted.

### How to upload your own image

You can upload your own images for cloud servers within a cloud region, without any cost for storage.

There are two options for adding images to the system:

Option 1: Drag and drop

1. Log in to the Customer Portal
2. In the left-hand menu, navigate to **Cloud Servers** → **Images** and click **Upload image**
3. Choose the location where the cloud server is deployed for which this image is intended
4. In the area labeled **Drop images here or click to upload**:
   * Drag and drop the image file, or click inside the area to browse and select the file from your computer
5. Click **Upload** to begin

Option 2: Upload by cURL

1. Log in to the [Customer Portal](https://portal.servers.com/)
2. In the left-hand menu, navigate to **Cloud Servers** → **Images** and click **Upload by cURL**
3. Go to the **Upload by cURL** tab
4. Select your cloud server location and provide:
   * A **Name** for the image
   * The **Format** of the image
5. Click **Generate cURL**
6. Copy the generated cURL command and execute it in your terminal

Your image will be uploaded and ready for OS installations within a cloud region.

### How to view preliminary billing information

Cloud computing resources are listed on invoices in an aggregated (summarized) format for each cloud region. To view preliminary billing information (pro forma), complete the following steps:

1. Log in to the [Customer Portal](https://portal.servers.com/)
2. In the left-hand menu, navigate to **Reports** → **Cloud Servers**
3. Select the period and cloud region for which you want to view the preliminary billing information

A billing summary will display all cloud computing resources used in the selected location, including the number of units consumed during the specified period.


# Snapshot and backup management (/docs/cloud-servers/snapshot-and-backup)



Snapshots and backups allow you to capture the current state of your cloud server and restore it later, providing a safeguard for your data. The total size of a snapshot depends on the used disk space on the cloud server.

You can manage your snapshots and backups in [Customer Portal](https://portal.servers.com/) → **Cloud Servers** → **Snapshots**.

### How to create a snapshot

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the cloud server
2. On the server details page, click **Snapshots**
3. Click **Take snapshot** and enter a name for the snapshot

Once the status changes from **Pending** to **Active**, the snapshot will be created.

### How to download or delete snapshots and backups

1. In the left-hand menu, navigate to **Cloud Servers** → **Snapshots**
2. In the item line, click **Download** or **Delete**

Depending on the selected action, the file will either be downloaded or deleted.

Downloaded snapshots and backups will be in `qcow2` format.

### How to activate automatic backup creation

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, click **Backups**
3. Click **Manage backups**
4. Select the number of copies and click **Save**

For more details, refer to the backup details.

### How to disable automatic backup creation

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, click **Backups**
3. Click **Manage backups**
4. Uncheck the checkbox and click **Save**

### How to restore a cloud server

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the cloud server
2. Decide which image you want to use to restore the server, and navigate to the corresponding tab on the server details page
3. Select the desired snapshot or backup from the list and click **Restore**
   * Restoring the server from an image will erase all existing disk data
4. If you are sure, confirm by clicking **Reinstall** and entering your account password

The server will be restored to the state captured in the selected image.


# Volume management (/docs/cloud-servers/volume-management)



Volumes are persistent block storage devices that can be created, attached, and detached independently of cloud servers. This page explains how to manage volumes through the Customer Portal.

### How to create a volume

1. Log in to the [Customer Portal](https://portal.servers.com/)
2. In the left-hand menu, navigate to **Cloud Servers** → **Volumes** and select the cloud region
3. Choose a preset volume size or choose the **Custom size**
4. Select the cloud server to attach the volume to, or choose **Do not attach** if you want to attach it later
5. Enter the volume name and click **Create volume**

The volume will be created.

#### How to mount a volume

1. Before mounting a volume, create a mount point:

```bash
sudo mkdir -p /mnt/mount_point_name
```

2. Before you can use a new volume you need to build a Linux file system on it:

```bash
sudo mkfs.ext4 -F /dev/vdb
```

3. Mount the volume:

```bash
sudo mount -o discard,defaults /dev/vdb /mnt/mount_point_name
```

#### Keeping mount point through reboots

You need to add a record into the "fstab" config if you want OS to mount a volume automatically after boot:

```bash
echo '/dev/vdb /mnt/mount_point_name ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab
```

### How to attach a volume to a cloud server

Option 1: attach from the volumes page

1. In the left-hand menu, navigate to **Cloud Servers** → **Volumes**
2. Select the created volume and click **Attach**
3. From the dropdown menu, select the cloud server and click **Apply**

Option 2: attach from the server details page

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the server
2. On the server details page, click **Attach volume**
3. Select the created volume from the list and click **Attach**

The volume will be attached to the cloud server.
In the **Attached volume** row, you will see the path where the volume is mounted on the server.
On Linux, the volume is mounted as a block storage device with the device name, e.g., `/dev/vdb`.
On Windows, the volume will be assigned a drive letter, such as `D:` or `E:`.

### How to detach a volume from a cloud server

1. In the left-hand menu, navigate to **Cloud Servers** → **Instances** and select the cloud server
2. On the server details page, scroll to the **Attached volume** row and click **Detach** next to the volume you want to detach
3. In the confirmation window, click **Detach** and confirm the action by entering your account password

The volume will be detached.


# Billing (/docs/cloud-storage/billing)



The service is provided on a postpaid basis. Your account will be charged at the end of a month according to the actual usage. The service cost includes:

* Charges for private and public cloud storage containers
* Charges for traffic from public cloud storage containers

### Storage

The cloud storage is billed for hour-weighted average data volume per month. In other words, we calculate the average data amount you have stored over the entire month and how long each data amount stored during that time.

### Traffic

Charges are based on the number of gigabytes transferred during the billing period, including traffic delivered over the internet from public cloud storage container to end users.

Incoming traffic is not charged during container synchronization. Additionally, there are no charges for incoming or outgoing GPN traffic between cloud storage and cloud or dedicated servers.

### Cancellation terms

The cloud storage service can be canceled at any time by deleting the created containers. Please note that any outstanding payments up to the deletion date must still be paid.


# OpenStack API (/docs/cloud-storage/cloud-storage-openstack-api)



Cloud storage is accessible via the OpenStack API with v3 (Keystone) authentication. For more details about OpenStack Swift and Keystone, see the official documentation:

* [OpenStack Swift](https://docs.openstack.org/swift/latest/)
* [OpenStack Keystone](https://docs.openstack.org/keystone/latest/)

### Getting access credentials for OpenStack API in the Customer Portal

To retrieve your access credentials, navigate to **Cloud Storage** and select the desired region. In the **Access credentials** section, the authorization details will be displayed based on the selected region.

### Installing python-openstackclient

`python-openstackclient` is a command-line tool for managing OpenStack components, including cloud storage, cloud servers, and more.

### macOS

Open the terminal and execute the following command:

```bash
pip install python-openstackclient
```

### Ubuntu

It is recommended to install the client from the Ubuntu repository rather than using `pip`, as `pip` may provide newer versions with functional differences.

Execute the following command in the console:

```bash
sudo apt-get install python3-openstackclient
```

### Authorization in the OpenStack API using python-openstackclient

To simplify the authorization process and avoid manually entering credentials each time, create a file with environment variables:

1. Create a `.sh` file:
   * On macOS, use any text editor to create a file.
   * On Ubuntu, use the built-in `nano` editor by executing the following command:

     ```bash
     nano ~/%file-name%.sh
     ```

     Replace `%file-name%` with the name of the created file.

2. In the [Customer Portal](https://portal.servers.com/), go to **Cloud Storage** → **Access Credentials** and click **Show** next to **Shell Variables**.

3. Copy and paste the environment variables into the created file in the following format:

   ```bash
   export OS_AUTH_URL=https://auth.servers.%region_id%.cloud.servers.com:5000/v3/
   export OS_TENANT_NAME=XXX
   export OS_PASSWORD=YYY
   export OS_USERNAME=ZZZ
   export OS_IDENTITY_API_VERSION=3
   export OS_DEFAULT_DOMAIN_NAME=default
   export OS_REGION_NAME=%region_name%
   ```

4. In the `nano` editor, save the file using the following shortcuts:
   * Press **CTRL + O** to save
   * Press **Enter** to confirm
   * Press **CTRL + X** to exit the editor

5. Import the environment variables into the current terminal session:

   ```bash
   source ~/%file-name%.sh
   ```

   Replace `%file-name%` with the name of the created file.

Once loaded, the OpenStack client will use these environment variables for authorization.

### Checking authorization

To ensure the authorization data has been loaded correctly, execute the following command:

```bash
openstack token issue
```

If successful, the command will output a token.

### Useful commands

Get a list of available OpenStack commands:

```bash
openstack -h
```

Get a list of containers in the region:

```bash
openstack container list
```

Get a list of objects in a container:

```bash
openstack object list CONTAINER_NAME
```

Replace `CONTAINER_NAME` with the name of the container.


# Concepts (/docs/cloud-storage/concepts)



Cloud Storage is a scalable solution for storing and distributing unstructured data of any size and format. As an object storage solution, it is suitable for storing large datasets with robust data integrity mechanisms. Its key characteristics are described below.

### Object storage

Cloud Storage, as an object storage solution includes the following key features:

* Automatically adjusts storage capacity and resources to handle growing workloads
* Object storage does not provide direct access to the operating system. This design uses metadata to manage data independently
* Supports distributed storage, ensures data integrity, and reduces complexity in managing large datasets

#### Data structure

The organization of data in object storage includes the following key features:

* Data in object storage are organized as objects with unique identifiers and metadata, simplifying data management and enabling instant access regardless of location
* Objects are stored in a flat structure without the nesting typical of hierarchical file systems. However, graphical interfaces may simulate hierarchies using path-like identifiers, such as `folder1/file.txt`, to represent objects within folders
* Triple data replication across three different servers ensures high reliability
* Specialized mechanisms detect and resolve discrepancies among object copies, maintaining data consistency
* Multipart upload is supported for objects over 100 MB, enabling efficient independent uploading of segments, better utilization of network resources, and resumption of interrupted uploads

#### Logical organization

Objects are grouped into containers (also know as buckets), which act as independent logical structures. Containers provide the following capabilities for managing data and metadata:

* Containers can be configured with access control settings to be either private or public.
* Containers store both system and user-defined metadata describing objects, their properties, and settings, such as deletion policies or version control
* Containers support functionalities such as undelete options for restoring deleted files, regional synchronization, object versioning, and partial object updates
* Containers can be deployed in various regions to optimize access speed and performance based on user location

### Access and managing Cloud Storage objects

Cloud storage objects have a direct integration into web applications and can be managed in various ways:

* Using the [Customer Portal](https://portal.servers.com/)
* Using APIs such as S3 or OpenStack Swift
* Via third-party applications that support Swift (e.g., Cyberduck)
* FTP

<Callout>
  Managing objects via FTP is not recommended. FTP-based applications attempt to imitate a hierarchical file system interface, aligned with POSIX standards. This imitation results in poor performance, a lack of support for key features (e.g., metadata, containers, multipart upload), and potential errors or incorrect behavior. Instead, it is advised to use tools compatible with S3 or OpenStack Swift APIs, which work directly with the object storage architecture.
</Callout>

Cloud storage containers (buckets) provide two types of access:

* Private access restricts container contents from being accessible via the internet. Commonly used for backups, confidential data storage, and other tasks requiring limited access
* Public access makes container contents accessible over the internet through public links via HTTP or HTTPS protocols. Ideal for hosting and distributing files, such as static web content (e.g., images, documents, videos) or publicly shared materials

For more detailed information on managing objects and configuration, refer to the article [How to access data in cloud storage](/cloud-storage/data-access/).

### Additional features

Here is a list of additional features you can apply to your cloud storage:

* Versions storage allows you to designate a container for storing old copies of modified objects
* Custom domain enables the association of a custom domain with a container, allowing the use of custom URLs for publicly shared materials
* Container synchronization ensures objects are synchronized across containers in different regions, maintaining data consistency


# Data access (/docs/cloud-storage/data-access)



This section covers how to get access credentials and configure clients.
Please note that each cloud storage you create is a separate and independent object storage container. For convenience, the terms "container" and "cloud storage" will be used interchangeably in the following instructions.

### Getting access credentials

Access credentials can be found in the Customer Portal → **Cloud Storage** → **Access credentials** section. Please note that each region has its own unique access credentials.

### Customer Portal

The Customer Portal features a user-friendly file manager. To use it:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field

2. Click the cloud storage entry from the list

In the file manager that opens, you can manage your objects.

### Cyberduck

Cyberduck is a popular open-source client for working with object storages (S3, Azure, Swift). It supports various protocols, including FTP, SFTP, WebDAV, Amazon S3, OpenStack Swift, Microsoft Azure, and more. The application is available for Windows and macOS and can be downloaded for free from the [official website](https://cyberduck.io/).

#### Cyberduck profile

In the Customer Portal, you can download a pre-configured Cyberduck profile for a specific location, allowing for quick connection to cloud storage:

1. In the left-hand menu, navigate to **Cloud Storage** and select the storage location in the **Region** field

2. In the **Access credentials** section, click **Download,** next to **Cyberduck profile**

#### Setting up Cyberduck

1. Open the downloaded profile with the `.cyberduckprofile` extension using the Cyberduck application
2. Enter the Tenant Name:User name and Password using the access credentials found on the cloud storage page in the Customer Portal
   For example, if the **User Name** is `12345` and the **Tenant Name** is `67890`, you would enter `67890:default:12345`
3. Close the Cyberduck settings window
4. To connect, select the profile from the list and press **Enter** or right-click the profile and select **Connect to Server**

The connection to the cloud storage will be established.

### FTP

Connecting to cloud storage via FTP allows you to use either the built-in tools of the operating system or third-party applications to upload, download, and manage files directly. However, it is **not recommended** to use FTP/SFTP protocols for connecting to and managing objects in cloud storage. [Learn more](/cloud-storage/concepts/#access-and-managing-cloud-storage-objects).

The FTP URL with embedded credentials can be found in the Customer Portal under **Cloud Storage** → **Access credentials** section. Click **Show** next to **FTP**.

#### Built-in terminal

##### macOS

1. Open **Finder** → **Go** → **Connect to Server**

2. Paste the FTP URL into the **Server Address** field and click **Connect**

##### Windows

1. Open **File Explorer** by pressing **Windows Key + E**

2. In the address bar, paste the FTP URL and press **Enter**

The connection to the cloud storage will be established.

#### FileZilla

FileZilla is a free, open-source client that supports FTP and SFTP protocols, designed for easy file transfers between a local computer and a server. To connect to cloud storage, follow these steps:

1. Download FileZilla from the [official website](https://filezilla-project.org/) and launch the application

2. In the **Quickconnect** bar, enter the following details:
   * **Host**: paste the part of the FTP URL after the `@` symbol

   * **User**: enter **Tenant Name.User Name**. For example, if the **User Name** is `12345` and the **Tenant Name** is `67890`, you should enter `67890.12345`

   * **Password**: enter the password for cloud storage

3. Click **Quickconnect**

The connection to the cloud storage will be established.


# File management (/docs/cloud-storage/file-management)



This article explains how to upload files to cloud storage through the Customer Portal and how to restore deleted files using the **Undelete** option.

### How to add a file to cloud storage in the Customer Portal

Uploading files (objects) to a cloud storage using a user-friendly interface in the Customer Portal. To add a file, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list
3. Drag and drop files into the **File manager** area, or click **Upload Files** and select them from your local computer

The files will be uploaded to your cloud storage.

### How to restore a deleted file

Using the **Undelete** option allows you to restore deleted files (objects). To activate this option, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list and click **Edit**
3. In the **Options** section, tick the **Undelete** option
4. Click **Save**

A container named `.trash-<yourCloudStorageName>` will be created, where deleted files will be stored.

To restore a deleted file, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the container named `.trash-<yourCloudStorageName>` from the list
3. Select the file you want to restore and download it to your local computer
4. Return to the list of cloud storages and upload the restored file back to the original cloud storage

The deleted file will be restored.


# Getting started (/docs/cloud-storage/getting-started)



In this section, we will guide you through the steps how to quickly create a cloud storage. Follow the instructions below to get started with your cloud storage:

1. Log in to the [Customer Portal](https://portal.servers.com/) and navigate to **Cloud Storage** from the left-hand menu
2. In the **Region** field, select the available geographical region where your cloud storage will be located and click **Create storage**
3. Select the **Access Type** as either **Public** or **Private**
4. Select the **Undelete** option if you want to have an additional container for storing and recovering deleted objects
5. Enter a storage name. This name will help you distinguish between multiple storages
6. Click Save

Your cloud storage will be created.

### Configure your cloud storage

To configure your cloud storage and change the access type, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the location of the created storage in the **Region** field
2. Select the storage from the list and click **Edit** in the **Details** section

Here, you will find a list of options:

* The **Listing** option provides access to a list of contents in public container in HTML format via a public link. By default, listing is disabled, and container contents are displayed in XML format. You can also specify a CSS file to apply custom styles to the listing HTML page.
* The **Static page** option allows the use of an index HTML file instead of a listing when the container is accessed via URL. You can also specify custom error page for 404 error during unsuccessful access attempts to the container. To enable this, place `404error.html` file in the container's root directory.
* The **Undelete** option allows you to collect deleted objects in a special container, enabling you to restore them at any time.


# Cloud Storage (/docs/cloud-storage)



**Cloud Storage** is S3 and Swift-compatible object storage built for unstructured data at any scale - replicated across multiple servers for high durability, and accessible via API, the Customer Portal, or any S3-compatible tool.

* **S3 and OpenStack Swift APIs** - use existing tools, SDKs, and integrations without modification
* **Built-in replication** - data stored redundantly across multiple servers for high reliability
* **Flexible access control** - set per-container permissions and use custom domains for static hosting
* **Regional sync** - replicate containers across regions for global availability

<DocCards>
  <DocCard title="Concepts" description="Understand containers, objects, replication, and access control." href="/cloud-storage/concepts/" />

  <DocCard title="Billing" description="See how Cloud Storage usage and pricing are calculated." href="/cloud-storage/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Create your first Cloud Storage service and container." href="/cloud-storage/getting-started/" />

  <DocCard title="Data Access" description="Retrieve and manage data in your containers." href="/cloud-storage/data-access/" />

  <DocCard title="File Management" description="Upload, organize, and manage objects in Cloud Storage." href="/cloud-storage/file-management/" />

  <DocCard title="OpenStack API" description="Access Cloud Storage programmatically using the Swift API." href="/cloud-storage/cloud-storage-openstack-api/" />
</DocCards>


# Limitations (/docs/cloud-storage/limitations)



Cloud Storage, as an implementation of object storage based on OpenStack Swift, has the following limitations:

| Type                                     | Value                         | Description                                                                                                                                                                                                                                     |
| ---------------------------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Maximum object size                      | 5 GB                          | Maximum size of a single object. Larger files require multipart upload with segmentation and merging                                                                                                                                            |
| Minimum object size                      | No limitations                | While objects with a zero-byte body can be stored, there is metadata and object storage-specific overhead. As a result, the actual minimum storable object size, including overhead, is typically around 4 KB per object.                       |
| Segment size for multipart uploads       | Up to 5 GB                    | Recommended size for each segment in a multipart upload                                                                                                                                                                                         |
| Maximum number of containers per account | No limitations                |                                                                                                                                                                                                                                                 |
| Maximum objects per container            | Soft limit of 1000000 objects | While there is no hard limit on the number of objects in a container, keep in mind that once a container holds approximately 1 million objects, the operation speed for that container may gradually decrease.                                  |
| Maximum object name length               | 1024 bytes                    | Maximum length of an object name                                                                                                                                                                                                                |
| Maximum container name length            | 256 bytes                     | Maximum length of a container name                                                                                                                                                                                                              |
| API request limits (GET/PUT/POST/DELETE) | No limitations                | Requests to Swift have no limitations, while requests to Keystone (authorization) are limited to approximately 12 RPS. The request capacity depends on the capabilities of the frontend servers, which vary by location (typically two servers) |
| Metadata size                            | 8 KB                          | Combined size of all metadata for a single object                                                                                                                                                                                               |
| Metadata entries per object              | 90                            |                                                                                                                                                                                                                                                 |
| HTTP header size                         | 8 KB                          | Maximum total size of all HTTP headers in a request                                                                                                                                                                                             |
| Number of object versions                | No limitations                |                                                                                                                                                                                                                                                 |
| Container size                           | No limitations                |                                                                                                                                                                                                                                                 |


# Service management (/docs/cloud-storage/service-management)



This article explains how to manage Cloud Storage settings in the Customer Portal — including changing the access type, enabling synchronization, listing, static pages, and versioning, attaching a domain, and deleting a storage.

### How to change the access type of your storage

You can switch the access type of your cloud storages between public and private in the Customer Portal. To switch the access type, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list and click **Edit**
3. In the **Access Type** field, select the type and click **Save**

The access type of your cloud storage will be updated.

### How to synchronize cloud storages

You can synchronize content between cloud storages in different regions, allowing you to maintain data consistency across locations. Ensure you have at least two cloud storages before enabling synchronization.

To proceed, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list
3. Scroll down to the **Synchronization** section and click **Enable Synchronization**
4. In the **Location to Synchronize** field, select the cloud storage location you want to sync with the current one and specify it in the **Destination Storage** field
5. Click **Add Connection** if you want to include additional cloud storage to synchronize with the current one
6. Click **Apply**

The cloud storage synchronization will be applied. To modify synchronization links with other cloud storages, click **Change Synchronization**. To cancel synchronization, choose the cloud storage from the list and click **Disable Synchronization**.

### How to enable listing

Enabling listing allows you to display the contents of your cloud storage in HTML format by accessing it via a public URL. By default, listing is disabled, and cloud storage contents are displayed in XML format.

To enable listing, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list and click **Edit**
3. In the **Options** section, tick the **Listing** option
4. In the **Listing CSS** field that appears, you can specify the relative path to a custom CSS file to apply styles for the listing page
5. Click **Save**

The listing will be presented in HTML format.

### How to enable static pages

Enabling static pages allows you to use an HTML index file instead of the listing page, which will be displayed when accessing the cloud storage via the public URL. Additionally, you can set up custom 404 error page for unsuccessful access attempts.

To enable static page:

1. Create an HTML file (for example, `index.html`), then add it to the cloud storage
2. In the **Options** section, tick the **Static Pages** option
3. In the **Index file** field, enter the file path and name if it differs from `index.html` or is not in the cloud storage root
4. Click **Save**

To enable custom error page:

1. Create HTML file named `404error.html` and add it to the root of the cloud storage
2. In the **Options** section, tick the **Custom Error Pages** option
3. Click **Save**

Static pages will be displayed when accessing cloud storage via a public link.

### How to enable versioning for cloud storage

Enabling versioning for cloud storage allows you to designate a container for storing old versions of modified files.

To enable versioning, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list and click **Edit**
3. Scroll down to the **Versions Storage** section and enter the cloud storage name where versions of modified files will be stored. Use the following naming convention: `.trash-<yourCloudStorageName>-versions`
   For example, if your cloud storage is named `websitedoc`, the versions cloud storage should be named `.trash-websitedoc-versions`
4. Click **Save**

The versioning for cloud storage will be enabled.

### How to attach a domain to cloud storage

Attaching a domain to cloud storage allows you to use a unique, easy-to-remember domain name for accessing the storage (e.g., `files.example.com`). Before proceeding, ensure that your main domain is added to the Customer Portal.

To attach a domain, complete the following steps:

1. In the Customer Portal, navigate to your public storage page and scroll down to the **Domains** section
2. Copy the specified target value from the **Domains** section, as you will need it to create a CNAME record
3. In the left-hand menu, go to **Networks** → **DNS** and select your main domain from the list (e.g., `example.com`)
4. Scroll down to the **CNAME Records** section and click **Add CNAME Record**
5. In the window that opens, fill in the following:
   * **Alias Domain**: specify the subdomain name (e.g., `files`) that will be used before the main domain
   * **Domain Name**: enter the target value obtained from the cloud storage page
   * **TTL**: leave this field unchanged
6. Click **Save**. The CNAME record will be added
7. Return to your cloud storage page and scroll down to the **Domains** section
8. Enter the alias domain name created in the previous step (e.g., `example.com`)

The domain will be attached to your cloud storage within some time.

### How to delete cloud storage

Before deleting cloud storage, ensure that all necessary data is backed up. The cloud storage will be removed immediately, and this action is irreversible. To delete the cloud storage, complete the following steps:

1. In the left-hand menu, navigate to **Cloud Storage** and select the cloud storage location in the **Region** field
2. Choose the cloud storage from the list
3. Click **Edit** and ensure that the **Undelete** option is disabled
4. Click **Save**
5. Click the trash can icon next to the cloud storage you want to delete
6. Confirm the action by clicking **Delete**
7. Enter your account password

The cloud storage will be deleted.


# Getting started (/docs/direct-connect/getting-started)



To start using the direct connect service, follow the steps below:

1. Go to the **Networks** → **Direct Connect** section of the menu of the [Customer Portal](https://portal.servers.com)
2. Click **Add connection** on the [Direct Connect page](https://portal.servers.com/networks/dc)
3. Select a necessary location. You will see logos of major hosting providers with whom you can establish a connection. This is not an exhaustive list
4. Give the details of a **Destination point**, such as the location, provider and a device to connect
5. Select the **Type** of the connection: L2 or L3. Currently, L2 is available by default. Contact your account manager to get more details on L3 direct connect
6. Select the **Connection** type: single or redundant
7. Specify whether **Cross-connect** is required:
   * When a cross-connect is required, it will be set up and managed by Servers.com
   * Otherwise, Servers.com will send you the Letter of Authorization (LOA), so that you can establish physical connection yourself
8. Give a **Name** to a direct connect service

If any additional information is needed, you will be contacted by the Servers.com team. When the connection is finally set up and ready to use, you will receive an email notification.

Once the direct connect setup is over, add the connection to an [L2 segment](https://portal.servers.com/networks/l2). Thus, your direct connect will become accessible within the Global Private Network.


# Direct Connect (/docs/direct-connect)



**Direct Connect** lets you establish a dedicated physical connection from your premises into the Servers.com Global Private Network - bypassing the public internet entirely for lower latency, higher reliability, and predictable bandwidth. Choose a single port or a redundant LACP-bonded pair for double the throughput and automatic failover.

<DocCards>
  <DocCard title="Overview" description="Understand Direct Connect architecture, concepts, and billing." href="/direct-connect/overview/" />

  <DocCard title="Getting Started" description="Set up your first Direct Connect cross-connection." href="/direct-connect/getting-started/" />
</DocCards>


# Overview (/docs/direct-connect/overview)



The Servers.com Direct Connect service allows you to set up a dedicated network connection from your premises or another service provider to Servers.com. This allows you to reach resources in the [Global Private Network](/gpn/), directly bypassing other providers.

## Concepts

Direct connect is built upon a physical connection between a third-party infrastructure and Servers.com network equipment. A cable that physically connects network equipment on both sides is called a **cross-connect**.

The service is designed in accordance with the 802.1Q VLAN standard and operates over the data link (L2) level. Direct connect needs to be a member of an L2 segment to interact with other Servers.com resources.

A **destination point** is a device that connects your Servers.com equipment to your/third-party equipment. For example, it can be a switch from another hosting provider.

A **single connection** consists only of one port. A **redundant connection** implies two ports bound by LACP into a Link Aggregation Group (LAG). It unites bandwidth capability and ensures fault-tolerance if one port fails.

**Speed** is a bandwidth characteristic of a direct connect port. When a redundant connection is selected, the entire bandwidth at your disposal will double.

## Use case

Your main production environment is located at Servers.com, but you also have servers that you use for redundancy at another hosting provider. Both installations are hosted in the same data center, but they can interact with each other only via the internet. To link your infrastructure and establish faster communication within a private network, you can use Servers.com Direct Connect.

## Limitations

A single direct connection can have a native link with one of your L2 segments. Tagged trunks can have multiple L2 segments simultaneously.

## Billing

The direct connect price consists of the following items:

* Connection setup fee;
* Connection monthly payment;
* Cross-connect setup fee (per one port);
* Cross-connect monthly payment (per one port).

When selecting a redundant direct connect, connection setup and monthly payments will increase. Since direct connect works as a member of an L2 segment, keep in mind billing of that service as well.

### Cancellation terms

The service is billed for a full month. In the case of a premature cancellation, the full monthly price will still be charged.


# Getting started (/docs/dns/getting-started)



This guide explains how to add a domain and verify ownership, either by delegating it to Servers.com name servers or by adding a TXT record at your registrar.

### Add a domain

1. In the Customer Portal, open **Networks** → **DNS**
2. Click **Add domain**
3. Enter your domain name and email in the modal window and confirm. The domain is created in `undelegated` status.

### Configure your DNS records (optional)

You can add DNS records while the domain is still `undelegated`. Records take effect as soon as the domain is published (served by resolver). Use the **Records** section in the Customer Portal.

### Verify ownership

After adding the domain, the Customer Portal shows the NS servers assigned to your domain and the TXT record value for verification. Choose one of two verification methods - or combine them:

#### TXT record verification

Add the TXT record provided in the Customer Portal to your domain at your registrar. The system detects the record within 24 hours and transitions the domain to `verified`. This method is useful when you want to go live without changing your NS delegation yet. You can pre-configure all records, add the TXT record to publish the domain, and switch to NS delegation later at your own pace.

#### NS delegation

To delegate your domain, update the NS records at your registrar to point to the Servers.com name servers assigned to your domain:

* `ns01.srvrsdns.com`
* `ns01.srvrsdns.net`
* `ns01.srvrsdns.org`
* `ns01.srvrsdns.co.uk`

To complete delegation:

1. Log in to your DNS provider account and navigate to the DNS management page
2. Find the option to change the name servers - these are typically defined by an NS record
3. Replace the existing name servers with the Servers.com name servers listed above
4. If you have any difficulties, refer to your DNS provider's documentation or contact their support team
   The system detects the change within 24 hours and transitions the domain to `delegated`. You can track delegation status using tools such as `dig` or `nslookup`.

<Callout type="info">
  To avoid downtime during migration, add your domain in the Customer Portal and configure all DNS records before updating your name servers at the registrar. You can use TXT record verification to go live immediately and switch to NS delegation later.
</Callout>


# DNS (/docs/dns)



**DNS** from Servers.com gives you free authoritative name hosting for your domains, supporting all standard record types - A, AAAA, CNAME, MX, CAA, and more - with full management from the Customer Portal at no additional cost.

<DocCards>
  <DocCard title="Overview" description="Understand how DNS works and which record types are supported." href="/dns/overview/" />

  <DocCard title="Getting started" description="Add and configure a domain in the Customer Portal." href="/dns/getting-started/" />
</DocCards>


# Overview (/docs/dns/overview)



DNS lets you manage domains and records directly from the Customer Portal or via the Public API (PAPI).

### Concepts

#### Domain statuses

Every domain you add has one of three statuses that reflects its current verification state:

* **Undelegated** - the domain has neither been delegated to the system's NS servers nor has a valid TXT verification record or lost delegation. The domain is not published and will not resolve.
* **Verified** - the domain is not delegated, but a valid TXT verification record is present at your registrar. The domain is published and resolves.
* **Delegated** - the domain's NS records at your registrar point to the Servers.com NS servers, and at least one of them responds authoritatively. The domain is published and resolves.
  The system checks the status of each domain automatically at least once every 24 hours.

#### How domain verification works

There are two ways to confirm ownership of a domain: NS delegation and TXT record verification. You can use either method, or combine them.

**NS delegation** means updating the NS records at your registrar to point to the NS servers (at least 2 of 4) provided for your domain. Once the system detects that at least one NS server responds authoritatively (an SOA record or AA flag is present), the domain transitions to `delegated`.

**TXT record verification** is a way to confirm ownership without changing your NS delegation. The system generates a unique TXT record value for your domain. You add this as a TXT record at your registrar. When the system's next check detects the record, the domain transitions to `verified` and becomes published - even if the NS records still point to your previous provider.

TXT record verification is useful when you want to pre-configure your DNS records here and cut over later, or when you want to migrate from another NS provider without any downtime. You can set up all your records first, add the TXT verification record to go live, then switch NS delegation at your own pace.

#### Publishing and unpublishing

A domain is published (served by resolver) when its status is `verified` or `delegated`. A domain in `undelegated` status is not published (not served).

If a domain was published and later loses both its delegation and its TXT verification record, it transitions to `undelegated`. The domain continues to be published for 72 hours to give you time to restore verification. If the domain is not verified or delegated again within 72 hours, it is unpublished automatically.

You receive email notifications when your domain fails a check:

* First notification 1 hour after the first failed check (72 hours remaining)
* Follow-up notifications every 24 hours until the domain is unpublished

If you restore verification or delegation before the 72-hour window expires, the domain remains published without interruption.

#### DNS records

You can add, modify, and delete DNS records for a domain at any time - including when the domain is in `undelegated` status. This means you can fully configure a domain before it goes live.

The following record types are supported:

* **A** - links a domain name to an IPv4 address
* **AAAA** - links a domain name to an IPv6 address
* **CNAME** - canonical name record used for redirection to another domain name
* **MX** - points to mail exchange servers for the domain
* **TXT** - associates free text with the domain; also used for ownership verification
* **NS** - defines the authoritative name servers for the domain
* **SRV** - points to servers for specific services such as Jabber or Active Directory
* **PTR** - a reverse DNS record that links an IP address to a canonical name; used in mailing to reduce spam
* **CAA** - specifies which certificate authorities (CAs) are allowed to issue SSL/TLS certificates for your domain

An SOA record is created automatically when you add a domain. You cannot manually create or edit the SOA record directly - SOA parameters such as TTL and admin email are updated through the domain settings.

#### CAA record

A CAA (Certification Authority Authorization) record allows a domain owner to specify which certificate authority is authorized to issue SSL/TLS certificates for their domain. It reduces the risk of unauthorized certificate issuance and phishing attacks.
A CAA record consists of three parameters:

* **Flag** - an integer that defines how the CAA record should be processed. Two values are supported:
  * `0` (non-critical): allows the certificate to be issued without strict enforcement of the record
  * `128` (critical): rejects the certificate request if the CA does not recognize or support the CAA record
* **Tag** - a string that specifies how the CA should handle certificate issuance:
  * `issue` - allows a specified CA to issue standard certificates
  * `issuewild` - allows the issuance of wildcard certificates
  * `iodef` - specifies a contact email for receiving violation notifications related to CAA policies
* **Value** - a string containing at most one CA identifier permitted to issue certificates for the domain

### Use cases

**Automating DNS management in CI/CD** You use the Public API (PAPI) to create domains, manage records, and check verification status as part of your deployment pipeline. Domains can be created before infrastructure is ready, and records can be updated programmatically without using the Customer Portal.

### Limitations

* Status checks run at most once per 24 hours. Changes you make at your registrar - such as adding a TXT record or updating NS servers - are not reflected immediately.
* Domains in `undelegated` status are unpublished after 72 hours. To restore publishing, the domain must pass a delegation or TXT verification check.
* Custom or vanity NS server names are not supported.
* SOA records cannot be created or edited directly via the records API. SOA parameters are managed through the domain settings.

### Billing

DNS is free of charge.


# Billing (/docs/firewall/billing)



The service is billed per usage. Charges are calculated based on actual usage and are included in the invoice for the upcoming billing period. The service is billed as follows:

* A fixed monthly fee for each firewall instance
* Charges for permitted outbound traffic through the firewall, calculated monthly based on amount of data used (in GB). Dropped traffic is not billed
* Outbound traffic is billed separately for the firewall and the dedicated server, with no mutual offset

### Cancellation terms

The service can be canceled at any time. Any outstanding payments must be paid up to the deletion date.


# Concepts (/docs/firewall/concepts)



A firewall is a network security solution that monitors and controls inbound and outbound traffic based on predefined filtering rules. The firewall service does not provide DDoS mitigation; its primary function is to act as a barrier between trusted private networks and untrusted public networks, blocking unauthorized traffic.

### Infrastructure

The firewall service is a multi-tenant solution based on a clustered architecture, where each firewall instance represents an individual firewall profile, allocated for servers. These instances are created in the Customer Portal and hosted on shared hardware used by multiple users. Under optimal conditions, a single instance can handle up to 8,5 Gbps of traffic. High availability is ensured through hardware, network, and power redundancy.

### L2 segment compatibility

A VXLAN is created for each firewall instance, serving as the native network for hosts behind the firewall. Hosts staying behind the firewall cannot use native connections to public L2 segments and must utilize tagged trunks instead. All connections to public L2 segments must be configured as tagged trunks.

### Impact of firewall changes on server downtime

Some operations may result in brief downtime for protected servers. These include:

* Creating or deleting a firewall instance leads to downtime for all associated servers
* Adding or removing a server under the firewall leads to downtime only for this server, other servers will not be affected

Adding, removing, or editing firewall rules does not result in any downtime.

### Features

The Firewall offers the following capabilities:

* Creation and management of filtering rules for inbound and outbound traffic based on IP addresses, ports, and supported protocols, such as TCP, UDP, ICMP
* Stateful TCP session monitoring and packet filtering
* Protection of additional public IPv4 addresses
* Traffic monitoring and anomaly detection

### Benefits and use cases

Deploying the Firewall in front of your infrastructure helps you:

* Reduces the packet-filtering workload, preventing unwanted traffic from reaching servers
* Lowers the risk of attacks by blocking unexpected traffic directed at protected nodes
* Helps prevent data leaks caused by software misconfigurations


# Getting started (/docs/firewall/getting-started)



To get started, ensure you have at least one dedicated server. Follow the instructions below to begin the setup process:

1. Log in to the [Customer Portal](https://portal.servers.com/) and navigate to **Firewalls** from the left-hand menu
2. Click **Create**
3. In the **Location** field, select the location that matches the one where your dedicated servers are provisioned
4. In the **Host** section, select the dedicated servers to which the firewall rules will be applied
5. Configure firewall rules
   The **Inbound rules** and **Outbound rules** sections allow you to define traffic rules for your firewall instance. Here is how the elements in both sections work:

* Select the protocol for the rule (e.g., TCP, UDP, ICMP)
* **Port range**. Specify a port or range of ports for allowed traffic (e.g., `22` for SSH, `80` for HTTP, or `0-65535` for all ports)
* **Source/Destination**. Define the IP addresses or networks. In **Inbound rules**, this specifies the source of traffic, while in **Outbound rules**, it specifies the destination. By default, `All IPv4` allows traffic from or to any IPv4 address
* Add a short description to identify the rule (e.g., `TCP for SSH` or `UDP for DNS`)
* **Add rule** button. Use this button to create a rule based on predefined presets. For example:
  * Selecting IMAPS in **Inbound rules** adds a rule with protocol TCP and port `993`
  * Selecting HTTPS in **Outbound rules** adds a rule with protocol TCP and port `443`
  * Once created, rules appear in their respective lists and can be edited or deleted using the icons in each row

6. Enter a firewall instance name. This name will help you distinguish between multiple instances
7. Click **Create**
8. In the opened window, confirm your action by clicking the **Proceed** button

Your firewall instance will be created.

### Firewall setup best practices

A firewall is an essential security tool for protecting against external threats and malicious activity. The level of security directly depends on proper configuration which should block unauthorized traffic while maintaining optimal network performance. We've collected below the key points and recommendations for using the firewall service from Servers.com.

* Default rules are applied automatically. When a new firewall instance is created, default rules are automatically applied to restrict all traffic to any destination and from any source
* Firewall blocks all traffic if no rules are defined. If all rules, including default ones, are removed, the firewall will block all traffic by default
* Unspecified ports are blocked. If rules are applied only to specific ports, traffic for other unspecified ports will be blocked. For example, if rules are applied for ports 80 (HTTP) and 443 (HTTPS), port 22 (SSH) will be blocked

### Recommendations

* Allow only necessary ports, such as 80 (HTTP) and 443 (HTTPS) for public services, and block all other ports
* Restrict access to remote connection ports 22 (SSH) and 3389 (RDP) from specific trusted IP addresses
* Leave outbound traffic rules as default if no filtering is required
* Avoid rule duplication


# Firewall (/docs/firewall)



The **Firewall** service gives your servers a dedicated security layer - filtering inbound and outbound traffic by IP address, port, and protocol with stateful TCP session monitoring. Each instance handles up to 8,5 Gbps and is backed by hardware, network, and power redundancy.

<DocCards>
  <DocCard title="Concepts" description="Understand Firewall architecture, filtering capabilities, and L2 segment compatibility." href="/firewall/concepts/" />

  <DocCard title="Billing" description="See how Firewall usage and pricing are calculated." href="/firewall/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Create and configure your first Firewall instance." href="/firewall/getting-started/" />
</DocCards>


# Limitations (/docs/firewall/limitations)



The following limitations apply when using this service:

* Deep Packet Inspection (DPI) is not supported
* The firewall service is available only for dedicated servers
* A server cannot be added to the firewall if it:
  * is already assigned to another firewall
  * belongs to an L2 segment in native mode
  * is configured without a public network
* Each rule can include up to 1,000 addresses
* IPv6 support is not available at this time
* The service is available in specific locations only
* Limited compatibility with L2 Segments (refer to the [L2 segment compatibility](/firewall/concepts/#l2-segment-compatibility) section)


# Access management (/docs/ebm/access-management)



For remote access to the server, the Customer Portal offers two authentication methods.

### SSH Key

An SSH key is a pair of cryptographic keys used for authentication. An SSH key pair consists of a private key and a public key. The private part of the key stored on the local machine from which the user connects to the server. The public part stored on the server. It is recommended to use SSH keys in most cases, especially if you need maximum security.
Advantages: High level of security, no need to enter a password for each connection.

### Password

A password can be used for quick access or in situations where using SSH keys is difficult or impractical. It is also suitable for temporary access or for users who are not familiar with setting up SSH keys. The password for server access will be sent to the contacts with Primary and Technical roles via email.
Advantages: Easy to set up and use, does not require additional tools for SSH key generation.

## How to create SSH key

### Generate keys via Customer Portal

1. In the left-hand menu, navigate to **Identity and Access** and select **SSH & GPG keys**

2. Click **Create**

3. Specify the SSH key name in the **Name** field, select **Generate new SSH key** and click **Create**

A new private SSH key will be generated.
Carefully copy the key to ensure all characters are accurately transferred and pasted into a file on your local machine. Make sure to save the SSH key on your local machine in a secure location. Use this key when ordering new dedicated servers or reinstalling the OS on an existing server by selecting SSH key from the list created in the Customer Portal. The public part will be automatically generated and added to the dedicated server.

### Generate keys on a local machine

#### Linux

To generate an SSH key, you can use the `ssh-keygen` utility. It is part of the standard OpenSSH toolset.

1. Open a terminal and generate an SSH key pair on your local machine using the following command:

```
ssh-keygen
```

By default, `rsa` type of key will be generated. If you need a different type of key, specify it:

```
ssh-keygen -t <SSH key type>
#<SSH key type>: ed25519, rsa, ecdsa, or dsa.
```

The utility will prompt you to choose a directory to store the key pair. For example, when choosing the default `rsa` key type:

```
Generating public/private rsa key pair.
Enter file in which to save the key (/username/.ssh/id_rsa): 
```

By default, they are stored in the `.ssh` directory inside the user's home directory. It is more convenient to store the keys in the default directory. This allows the SSH client to automatically locate the SSH keys during authentication

2. Choose the key storage location:
   * To use a non-standard directory, specify it at this step in the format `/path_to_id_rsa_key/` and press **Enter**
   * Otherwise, press **Enter** to accept the default directory

3. The utility will prompt you to enter a passphrase for the key for additional security (optional). Enter a passphrase or press **Enter** to skip it.
   This can be used to encrypt the private key file on the disk, providing an additional layer of protection in case the user account is hacked. Note that you will need to enter it every time the corresponding key is used

```
Enter passphrase (empty for no passphrase):
```

Once this process is complete, you will have an SSH key pair that can be used for authentication:

* `id_rsa` – the private key, stored on the local computer. Never share or transfer it to anyone or anywhere
* `id_rsa.pub` – the public key. This needs to be added to the server to authenticate

The key fingerprint and its image will appear in the terminal:

```
Your identification has been saved in /username/.ssh/id_rsa
Your public key has been saved in /username/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:6S0ATIXbSPYGtNAJdhj1T1Ak8QSyxuE/a3XzWtJKrMQ username@IP
The key's randomart image is:
+---[RSA 3072]----+
|  =BB+*=+        |
| ..BB* =         |
|   oO*. o        |
|   .oo+o .       |
|     .+ S o      |
|       B + +     |
|      o E = +    |
|     . . + =     |
|        . o      |
+----[SHA256]-----+
```

#### Windows

You can use the PuTTYgen utility to generate an SSH key pair on Windows OS. It is automatically installed with the PuTTY SSH client.

1. Go to PuTTY website and install utility
2. Launch PuTTYgen
3. Select the type of SSH key (e.g., `rsa`) and click the **Generate** button
4. Move the mouse cursor around the screen until the progress bar is completely filled
   You can move the mouse in any manner, just be careful not to accidentally close PuTTYgen
5. Choose whether to use a passphrase:
   * When the key is ready, enter and confirm the passphrase for the private key in the designated fields
   * If you do not want to set a passphrase, simply save the private and public key files in a secure location. The utility will warn you that the key is being saved without a passphrase

This completes the creation of an SSH key pair

## How to add an existing SSH key to the server

To connect to the server via SSH, you must have a public key on the server. Adding an SSH key to the server via the Customer Portal is only possible during the installation or reinstallation of the OS. In all other cases, this can be done via the console.

### Linux based systems

1. Open a terminal on your local machine
2. Copy the public key to the server using the following command:

```
ssh-copy-id -i path_to_file/id_rsa.pub username@server_ip
```

Replace:

* `path_to_id_rsa.pub` with the full path to the `id_rsa.pub` key on your local computer
* `username` with your actual username on the server
* `server_ip` with the server's IP address

3. Press **Enter** and type the password

Your public key will be added to the server.

### Windows

To add an existing SSH key to a Windows-based server, complete the following steps:

1. Open the Command Prompt on your local computer
2. Copy the public key to the server using the following command:

```
scp path_to_file\your_key.pub username@server_ip:C:\Users\username\.ssh\authorized_keys
```

Replace:

* `path_to_file\your_key.pub` with the full path to the public key on the local computer

* `username` with your actual username on the server

* `server_ip` with the server's IP address

3. Press **Enter** and type the password

Your public key will be added to the server.

To check the permissions, complete the following steps:

1. Connect to the server via RDP or other remote access methods
2. Open a PowerShell on the server
3. Retrieve the access control list (ACL) of the `authorized_keys` file:

```
Get-Acl C:\Users\<username>\.ssh\authorized_keys | Format-List
```

4. To display the file permissions for the `authorized_keys` file, use this command:

```
icacls C:\Users\<username>\.ssh\authorized_keys
```

Replace `<username>` with the actual username for which you want to check the SSH file permissions

## How to connect to the server

There are various ways to remotely connect to a dedicated server, using SSH, RDP (for Windows), or VNC.

### SSH

SSH is a cryptographic network protocol that allows users a secure way to access a server over an unsecured network. This protocol refers to the suite of utilities that implement the SSH protocol and available on most operating systems, including Linux, macOS, and Windows. The SSH protocol supports various authentication methods, such as password, public and private keys.
To authenticate on the server using the generated SSH key, you must first add it to the server. Instructions are provided in the article How to add an SSH key to the server.
To connect to a remote server via SSH, use the `ssh` utility on your local machine. On macOS and Linux, you can access this utility via the Terminal. On Windows, use PowerShell.
Before connecting to the server, you will need its IP address and login credentials:

* IP address: public and private IP addresses can be found on the server details page in the Customer Portal. Use the public IP address of your server if you're connecting via the Internet

* Credentials: username and password, or username and private key. If you have not provided a public key when ordering a server, an automatically generated password will be sent to you via email. **For a newly provisioned dedicated server, the username is `root`**

#### Password authentication

To authenticate using a password, run the following command and enter the password sent to your email.

```
ssh username@server_ip_address
```

#### Key-based authentication

To authenticate using a key, use the private key from the pair that corresponds to the public key you set up for the server.
Usually, SSH keys are stored in the ".ssh" subdirectory of the user's home directory. Assuming the key file is named "id\_rsa", the command will look like this:

```
ssh -i ~/.ssh/id_rsa username@server_ip_address
```

Note that "id\_rsa" is a default file name for a private key when you generate key pair with the "ssh-keygen" utility. Your actual key may have another name.
When using the key for the first time on your local machine, the console will display a warning that the key is being used for the first time and will ask if you want to proceed with the given fingerprint.

```
Are you sure you want to continue connecting (yes/no/[fingerprint])?
```

Type "yes" and press **Enter**.
You will gain access to the server without being prompted for a password.

##### "Permissions too open" error

When using a key file for the first time, you might encounter an error from SSH stating "Permissions for \[the key file] are too open".
Use the following command to set more restrictive file permissions for the key file under macOS and Linux:

```
chmod 600 ~/.ssh/id_rsa
```

Use the following series of commands to change file permissions in Windows PowerShell:

```
#Extracts username of the current user
[String] ${stUserDomain},[String] ${stUserAccount} = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name.split("\")
#Grants full permissions to the current user
icacls $home/.ssh/id_rsa /grant:r ${stUserAccount}:F
#Removes inherited permissions
icacls $home/.ssh/id_rsa /inheritance:r
```

#### How to connect to the server via SSH on a Windows-based system

You can use SSH clients like PuTTY or the built-in OpenSSH Client (available with Windows 10 and later).

1. Prepare connection details and ensure you have the server's IP address or domain name, username, and password (or a private key for authentication).
2. Launch the SSH client
   If using the PuTTY client, ensure the connection type is set to **SSH** and the port is **22**. Then click **Open**
3. Use the following command:

```
ssh username@server_ip
```

Replace:

* `username` with your actual username on the server
* `server_ip` with the server's IP address or domain name

4. Complete authentication:
   * If using a password, enter it when prompted
   * If using SSH keys, specify the path to the private key with the `-i` option:
     ```
     ssh -i path_to_your_private_key username@hostname_ip
     ```

5. Confirm the connection by typing 'yes' and pressing **Enter** if you trust the connection

You will gain access to the server.

### VNC console

A VNC (Virtual Network Computing) console is a remote management tool that allows users to access and control their servers' graphical interface remotely over the Internet. This enables users to perform server maintenance tasks, install updates and software, and resolve issues even if the operating system does not boot or is not installed.
Dell servers use the Integrated Dell Remote Access Controller (iDRAC). In the Customer Portal, there is a VNC console that provides access to the server's console using VNC technology, independent of the Java/HTML5 console provided directly by iDRAC.
To connect to the server using VNC, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. In the **My servers** section, choose the server and click **Details**
3. Click **VNC console**
4. Enter your account password in the pop-up window and click **Continue**

A screen with the console will open. Use the icon to open a sidebar with VNC console control elements.

<Callout>
  To avoid typing long text, passwords, or commands manually, use the VNC console's clipboard function. Click the icon, paste the text into the field, and then click the icon again. The text will be inserted into the console.
</Callout>

### RDP

RDP (Remote Desktop Protocol) from Microsoft is designed for remote access to the graphical interface of Windows systems. It is used for remote administration, technical support, and working with applications.
To connect to the server via RDP, see this article How to connect to a Windows server.


# Billing (/docs/ebm/billing)



Dedicated server billing occurs on a pre-paid basis and is proportional to the number of days the service was used within the billing period, which is one month. Invoices are automatically generated on the 1st of each month. Payment for the dedicated server and associated services is due five days from the invoice date.

The cost of the dedicated server is listed in the currency of its location and will be converted to the account currency based on the exchange rate if they differ.

### Payment delay

If payment is not received for the issued invoice after the specified period, an overdue notice is sent to the account contacts. If the overdue notice is disregarded and payment is not received, company employees may proceed to block the ordered dedicated servers and suspend the ability to order services. This restriction does not apply to services already paid for.

Before blocking, company employees always reach out to the account manager to remind them of the outstanding balance.

Blocked dedicated servers remain assigned to the account; data is not deleted, and servers are not shut down or restarted. However, servers become inaccessible to account users via both private and public networks, as well as via the Virtual Network Computing (VNC) console.

### Additional services

Here is a list of additional services that can be applied to the ordered dedicated server:

* HDD upgrades
* RAM upgrades
* Paid operating systems
* Extended traffic packages
* Additional IP addresses
* Uplink aggregation

We offer the possibility to discuss and fulfil custom requests for hardware and networks. These services are provided only after approval from our managers and architects.


# Concepts (/docs/ebm/concepts)



Enterprise Bare Metal (EBM) provides dedicated physical servers with complete resource isolation and no shared hardware components. This page outlines the core concepts of the EBM infrastructure, including server chassis specifications, provisioning timelines, and the scope of included services.

### Dell server chassis

Dell PowerEdge servers form the backbone of our infrastructure, providing robust solutions for a wide range of computing needs. Our experience has proved the reliability, performance, resilience, and low maintenance requirements of Dell servers. The majority of our servers are rack-mountable, standing either 1U or 2U high.

To distinguish between the server model and chassis model, we adhere to the following terminology:

* A **chassis model** is a server's body with the key components such as processors installed and the backplane, excluding attachments such as disks, RAM, and so on. The processor installed in the chassis does not change. Each chassis can accommodate several server models.
* A **server model** represents a real server with all attachments (disks, RAM, additional network cards and so on).

We offer chassis with a wide range of system classes, processors, and platform generations, enabling the creation of solutions for small businesses and providing scalability for large enterprise tasks.
The naming generally consists of a letter(s) followed by three numbers (e.g., PowerEdge R240):

A brief description of the available server chassis:

| Model    | Description                                                                                                                                                                                                                                                                                                                                                                                             |
| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **R2xx** | A single-socket (single CPU), single PSU system in the 1U size. They are installed into server racks equipped with Automatic Transfer Switches (ATS). See the Power redundancy section of this article. R2xx servers usually do not have a RAID controller installed. The second network interface controller occupies the only PCI expansion slot. See the Network redundancy section of this article. |
| **R3xx** | Practically the same as R2xx, but it has two power supply units (PSUs).                                                                                                                                                                                                                                                                                                                                 |
| **R4xx** | Dual-socket 1U system. Two CPUs allows for more RAM, more PCI lanes, and so on.                                                                                                                                                                                                                                                                                                                         |
| **R5xx** | 2U dual-socket system. Has more storage slots, expansion slots, and PCI lanes than R4xx.                                                                                                                                                                                                                                                                                                                |
| **R7xx** | 2U dual-socket system for storage and data processing workloads. Up to 26 x 2.5" drives per server.                                                                                                                                                                                                                                                                                                     |
| **T6xx** | They are explicitly used for GPU servers. Despite being the "tower" type, the chassis can be installed into a server rack as a 5U unit.                                                                                                                                                                                                                                                                 |

Dell servers come with an autonomous subsystem for management and monitoring capabilities – iDRAC. It is a hardware component installed on the server's motherboard and allows for server management even when the server is turned off. iDRAC provides both web and command-line interfaces.

### Provisioning time

Provisioning time is the duration required to configure and provide the dedicated server in the requested configuration after it has been ordered.
Provisioning ETA:

* From 15 minutes – The ordered server configuration is available in the rack
* 24 hours or more – The ordered server is not currently in the rack or configuration changes are needed

If server hardware needs to be ordered or transported, the server provisioning time is determined by the delivery deadlines.
For additional information on the server provisioning stages, refer to server provisioning.

### Included services

* Server hardware equipment
* Internet connection
* Connection to both a private and public network with flexible billing options
* Public IPv4 address
* Automated OS installation system and server booting in recovery mode
* Out-of-Band access
* Server management environment: Customer Portal, public API, terraform
* Replacement of failed components or entire server
* 24/7 technical support

### Additional services

A list of additional services that can be applied to the ordered dedicated server:

* HDD upgrades
* RAM upgrades
* Paid operating systems
* Extended traffic packages
* Additional IP addresses
* Uplink aggregation

We offer the possibility to discuss and fulfill **custom requests** for hardware and networks. These services are provided only after approval from our managers and architects.

### Dedicated server ID

Each ordered dedicated server is assigned a unique identifier. This ID is used to identify the server in Servers.com Public API requests and for accessing technical support.
Refer to the API documentation to find out the capabilities and available operations for dedicated servers.


# How to create a dedicated server via public API (/docs/ebm/create-a-dedicated-server-via-public-api)



This guide provides instructions on configuring and ordering a server using the API. For this example, we're looking at the Dell R220 / Intel Xeon E3-1231 v3 / 32 GB RAM / 2x480 GB SSD server in the AMS1 location. To explore other available server models, configurations, and locations, please visit the [Customer Portal](https://portal.servers.com/).

You can use either a password or an [SSH key](/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair) to authenticate a server. All SSH key fingerprints can be found in the Customer Portal under **Identity and Access** → **SSH & GPG keys**. Filling in user information is optional.

As you proceed with the requests, use the IDs obtained in the previous steps. Examples of requests and instructions on setting parameters will be provided in each section.

### Environment setup

Before working with the API, set up your environment for making requests. This includes installing the necessary tools for authentication and sending API requests.

Most modern operating systems come with built-in command-line tools like cURL. Additionally, you can use:

* Graphical tools like Postman to simplify sending API requests and receiving responses.
* IDE plugins or built-in tools for working with APIs (e.g., Visual Studio Code and JetBrains IDEs).

### Authentication

All requests to the Public API must include your authentication token and must be made using cURL, as specified in the [Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Dedicated-Server/operation/CreateADedicatedServer).

To get an API token:

1. Go to the [Customer Portal](https://portal.servers.com/login).
2. In the left-hand menu, navigate to **Identity and Access** and select **API keys**.
3. Click **Create**.
4. Specify the name of the API key and select **Read & Write** permissions.
5. Click **Create**.

An API token will be generated. Replace `TOKEN` with your API token in each request.

### Getting a list of available locations

Before finding the required server and its ID, get a list of available locations and choose the desired one.

```bash
curl -g "https://api.servers.com/v1/locations" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using the [srvctl CLI](/interfaces/cli):

```bash
srvctl locations list
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Location)

For this example, the AMS1 location (Amsterdam Metropolitan Area, The Netherlands) has `id: 1`.

### Getting a list of available dedicated servers in the selected location

| Parameter     | Description                    |
| ------------- | ------------------------------ |
| `location_id` | The identifier of the location |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl server-models list --location-id {location_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Server-Model-Option/operation/ListServerModelsForALocation)

The response will include a list of available servers and their configurations for the selected location. For custom configurations, all necessary parameters can be specified in the request body. See: [Create a dedicated server](https://developers.servers.com/api-documentation/v1/#tag/Dedicated-Server/operation/CreateADedicatedServer).

For this example, the required server model has `ID: 10522`.

### Configuring the selected server

Before ordering the server, perform several GET requests to retrieve required IDs and parameters such as `uplink_models`, `bandwidth_id`, `drives`, and more.

#### Getting the list of uplinks

| Parameter         | Description                    | Example |
| ----------------- | ------------------------------ | ------- |
| `location_id`     | The identifier of the location | 1       |
| `server_model_id` | The identifier of the server   | 10522   |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models/{server_model_id}/uplink_models" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl uplink-models list --location-id {location_id} --server-model-id {server_model_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Uplink-Model-Option/operation/ListUplinksForAServerModel)

For this example:

* Private 1 Gbps without redundancy has `ID: 10201`
* Public 1 Gbps without redundancy has `ID: 10198`

#### Getting available bandwidths for public uplink

| Parameter         | Description                         | Example |
| ----------------- | ----------------------------------- | ------- |
| `location_id`     | The identifier of the location      | 1       |
| `server_model_id` | The identifier of the server        | 10522   |
| `uplink_model_id` | The identifier of the public uplink | 10198   |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models/{server_model_id}/uplink_models/{uplink_model_id}/bandwidth" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl uplink-bandwidths list --location-id {location_id} --server-model-id {server_model_id} --uplink-model-id {uplink_model_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Bandwidth-Option/operation/ListBandwidthOptionsForAnUplinkModel)

For this example, the bandwidth has `ID: 13744`.

#### Selecting the RAM size

Select the RAM size based on the `ram` and `max_ram` parameters in the response for the selected server configuration.

| Parameter         | Description                    | Example |
| ----------------- | ------------------------------ | ------- |
| `location_id`     | The identifier of the location | 1       |
| `server_model_id` | The identifier of the server   | 10522   |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models/{server_model_id}/ram" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl server-ram-options list --location-id {location_id} --server-model-id {server_model_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Ram-Option/operation/ListRamOptionsForAServerModel)

For this example, the selected server has a fixed memory size of 32 GB.

#### Getting disk models

At this step, determine which disks will be installed and in which slots.

| Parameter         | Description                    | Example |
| ----------------- | ------------------------------ | ------- |
| `location_id`     | The identifier of the location | 1       |
| `server_model_id` | The identifier of the server   | 10522   |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models/{server_model_id}/drive_models" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl drive-models list --location-id {location_id} --server-model-id {server_model_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Dedicated-Server/operation/ListDriveSlotsForADedicatedServer)

For this example, two `2 TB SATA3 HDDs` with `ID: 10306` will be mounted in each slot.

#### Disk partitioning

For this example, a simple disk partitioning setup with software RAID 0 is used. The server model chosen for this example does not have a hardware RAID controller.

#### Getting the list of available operating systems

| Parameter         | Description                    | Example |
| ----------------- | ------------------------------ | ------- |
| `location_id`     | The identifier of the location | 1       |
| `server_model_id` | The identifier of the server   | 10522   |

```bash
curl -g "https://api.servers.com/v1/locations/{location_id}/order_options/server_models/{server_model_id}/operating_systems" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl server-os-options list --location-id {location_id} --server-model-id {server_model_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Operating-System-Option/operation/GetAnOperatingSystemForAServerModel)

For this example, `Ubuntu 20.04-server x86_64` has `ID: 49`.

### Ordering a server

Once all parameters have been defined, submit the POST request to order the server.

| Parameter             | Description                               | Example     |
| --------------------- | ----------------------------------------- | ----------- |
| `server_model_id`     | The identifier of the server              | 10522       |
| `location_id`         | The identifier of the location            | 1           |
| `ram_size`            | The RAM size in GB                        | 32          |
| `public_uplink_id`    | The identifier of the public uplink       | 10198       |
| `bandwidth_id`        | The identifier of the bandwidth           | 13744       |
| `private_uplink_id`   | The identifier of the private uplink      | 10201       |
| `position_num`        | The slot position number, starting from 0 | 0, 1        |
| `drive_id`            | The identifier of the drive               | 10306       |
| `raid_level`          | The level of the RAID array               | 0           |
| `boot_partition_size` | Boot partition size, in MB                | 1024        |
| `swap_partition_size` | Swap partition size, in MB                | 2048        |
| `root_partition_size` | Root partition size, in MB                | 1997000     |
| `hostname`            | The host name                             | example\_aa |
| `operating_system_id` | The identifier of the operating system    | 49          |

```bash
curl "https://api.servers.com/v1/hosts/dedicated_servers" \
  -d '{
    "server_model_id": {server_model_id},
    "location_id": {location_id},
    "ram_size": {ram_size},
    "uplink_models": {
      "public": {
        "id": {public_uplink_id},
        "bandwidth_model_id": {bandwidth_id}
      },
      "private": {
        "id": {private_uplink_id}
      }
    },
    "drives": {
      "slots": [
        {
          "position": {position_num},
          "drive_model_id": {drive_id}
        },
        {
          "position": {position_num},
          "drive_model_id": {drive_id}
        }
      ],
      "layout": [
        {
          "slot_positions": [
            {position_num},
            {position_num}
          ],
          "raid": {raid_level},
          "partitions": [
            {
              "target": "/boot",
              "size": {boot_partition_size},
              "fill": false,
              "fs": "ext4"
            },
            {
              "target": "swap",
              "size": {swap_partition_size},
              "fill": false
            },
            {
              "target": "/",
              "size": {root_partition_size},
              "fill": true,
              "fs": "ext4"
            }
          ]
        }
      ]
    },
    "ipv6": false,
    "hosts": [
      {
        "hostname": "{hostname}"
      }
    ],
    "operating_system_id": {operating_system_id}
  }' \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer TOKEN"
```

The same request using the [srvctl CLI](/interfaces/cli): save the request body above as `dedicated-server.json` (it mirrors the API body 1:1) and pass it to `add`.

```bash
srvctl hosts ebm add --input dedicated-server.json
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Dedicated-Server/operation/CreateADedicatedServer)

If successful, you will receive a response containing the order details and the ID of the newly created server. If there are any issues with the request, error messages will be displayed in the console.

### Checking the status of a created server

| Parameter   | Description                          | Example |
| ----------- | ------------------------------------ | ------- |
| `server_id` | The identifier of the created server | ex4mp1e |

You can also find the server ID in the Customer Portal:

1. Go to the [Customer Portal](https://portal.servers.com/login).
2. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**.
3. Find the dedicated server by its name and click **Details**.

```bash
curl -g "https://api.servers.com/v1/hosts/dedicated_servers/{server_id}" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl hosts ebm get {server_id}
```

[View the request/response details in the Public API documentation](https://developers.servers.com/api-documentation/v1/#tag/Dedicated-Server/operation/GetADedicatedServer)


# How to create a dedicated server via Terraform (/docs/ebm/create-dedicated-server-via-terraform)



Terraform is an open-source infrastructure-as-code tool that lets you define and provision servers programmatically using configuration files. This guide walks you through installing Terraform, writing a manifest file, and using it to create a dedicated server on Servers.com — so you can automate and version-control your infrastructure instead of managing it manually through the portal.

### Prerequisites

You must have:

* Terraform installed on your local machine
* A valid API token for your Servers.com account\
  See: [How to create a dedicated server via public API](/ebm/create-a-dedicated-server-via-public-api#authentication) → **Authentication** section
* Familiarity with required resource values such as location codes, server model names, etc\
  See: [How to create a dedicated server via public API](/ebm/create-a-dedicated-server-via-public-api/)
* A valid SSH key\
  Make sure you have an SSH key pair generated on your local machine and the public key is added to your Servers.com account\
  See: [How to create a new SSH key pair](/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair)

### Install Terraform

Follow the steps below to install Terraform on macOS using Homebrew:

1. Open the terminal and install the HashiCorp tap (a repository of Homebrew packages):

   ```
   brew tap hashicorp/tap
   ```

2. Install Terraform:

   ```
   brew install hashicorp/tap/terraform
   ```

3. Verify the installation:

   ```
   terraform -help
   ```

For other operating systems, refer to the [official Terraform installation guide](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli).

### Create a manifest file

Create a manifest file (e.g., `main.tf`) in an empty working directory. It should begin with:

```hcl
terraform {
  required_providers {
    serverscom = {
      source = "serverscom/serverscom"
    }
  }
}
provider "serverscom" {
  token = "<PAPI token>"
  endpoint = "<API URL>"
}
```

Replace `<PAPI token>` with your actual API token.

You can find `<API URL>` in the Customer Portal under **Identity and Access** → **API tokens**.

### Define resources in the manifest

In Terraform, a resource is an object on which an operation is performed (create, modify, or destroy). It can be a server, load balancer or any other standalone service.

You can find the list of available resources in the [Servers.com Terraform documentation](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs).

Example manifest:

```hcl
terraform {
  required_providers {
    serverscom = {
      source = "serverscom/serverscom"
    }
  }
}
provider "serverscom" {
  token = "<PAPI token>"
  endpoint = "<API URL>"
}

resource "serverscom_dedicated_server" "dedicated_server_ubuntu22" {
  hostname             = "staging-host1"
  location             = "AMS1"
  server_model         = "Dell R220 / Intel Xeon E3-1231 v3 / 32 GB RAM / 2x2 TB SATA"
  ram_size             = 32
  operating_system     = "Ubuntu 22.04-server x86_64"
  private_uplink       = "Private 1 Gbps without redundancy"
  public_uplink        = "Public 1 Gbps without redundancy"
  bandwidth            = "20002 Gb"
  ssh_key_fingerprints = [
    "<SSH-KEY-FINGERPRINT>"
  ]
  slot {
    drive_model = "2 TB SATA"
    position    = 0
  }

  layout {
    raid = 0
    slot_positions = [0]

    partition {
      target = "/boot"
      size = 1024
      fill = false
      fs = "ext4"
    }

    partition {
      target = "/"
      size = 10240
      fill = false
      fs = "ext4"
    }

    partition {
      target = "swap"
      size = 4096
      fill = false
    }

    partition {
      target = "/home"
      size = 1
      fill = true
      fs = "ext4"
    }
  }
}
```

<Callout>
  The values shown here may become outdated. Always review Terraform error messages and update your configuration accordingly. Use the Public API queries to fetch the latest valid values. See 

  [Public API documentation](https://developers.servers.com/api-documentation/v1/)

  .
</Callout>

**Resource reference breakdown:**

| Field                         | Description                                                                                                                                                                                                                                                              |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `serverscom_dedicated_server` | The name of the provider and the type of resource being managed (in this case, a dedicated server).                                                                                                                                                                      |
| `dedicated_server_ubuntu22`   | The internal name of the resource in Terraform. This name is not passed to the API and must be unique in your configuration.                                                                                                                                             |
| `hostname = "staging-host1"`  | The name of the resource within the Servers.com infrastructure. This value is passed via API to Servers.com and must follow valid DNS format (no spaces or special characters).                                                                                          |
| `ssh_key_fingerprints`        | The fingerprint of an SSH key you previously added via the Customer Portal, in MD5 format. You can find this in the Customer Portal under **Identity and Access** → **SSH & GPG Keys**. Terraform uses the fingerprint to associate the key to the provisioned resource. |

### Initialize the working directory

Run the following command in the directory where your `.tf` manifest file is located:

```
terraform init
```

This is the first required command for any Terraform project. It initializes the working directory based on the configuration defined in the manifest file and prepares dependencies.

You do **not** need to run Terraform initialization every time. Only in the following cases:

* When setting up the provider for the first time
* The provider or backend configuration has changed
* The Terraform or provider version has changed

**Expected output (partial):**

```
Initializing the backend...
Initializing provider plugins...
- Finding latest version of serverscom/serverscom...
...

Terraform has been successfully initialized!
...
```

### Plan infrastructure changes

To preview the changes Terraform will make to your infrastructure without applying them:

```
terraform plan
```

This command:

* Reads the configuration from the `.tf` file
* Compares it with the current infrastructure state (using the `.tfstate` file and API)
* Outputs the changes to be made: created (`+`), updated (`~`), or destroyed (`-`)

### Apply the configuration

To provision the resources defined in your configuration:

```
terraform apply
```

Terraform will display the planned infrastructure changes again and prompt for confirmation. Type `yes` to proceed.

Do **not** close the terminal while the provisioning is in progress.

After successful execution, you will see an output similar to:

```
serverscom_dedicated_server.dedicated_server_ubuntu22: Creation complete after 1h01m255 [id=eXaMp1e]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
```

### Removing resources

List all resources currently managed by Terraform:

```
terraform state list
```

Example output:

```
serverscom_dedicated_server.dedicated_server_debian12
serverscom_dedicated_server.dedicated_server_ubuntu22
serverscom_cloud_computing_instance.cloud_instance
```

To destroy a specific resource (e.g., `dedicated_server_ubuntu22`):

```
terraform destroy -target=serverscom_dedicated_server.dedicated_server_ubuntu22
```

To destroy all resources managed by Terraform:

```
terraform destroy
```

If you have already removed a resource manually (via the Customer Portal or API), but it is still tracked in Terraform, you can remove it from the Terraform state:

```
terraform state rm serverscom_dedicated_server.dedicated_server_ubuntu22
```

This command does not remove the resource from Servers.com infrastructure, it only removes the record from Terraform state.


# Disk management (/docs/ebm/disk-management)



A disk controller is a hardware device that manages the operation of hard drives and solid-state drives in a server. It facilitates communication between the server's central processing unit (CPU) and the drives, controls data reading and writing, and is responsible for RAID (Redundant Array of Independent Disks) management functions.

## Why are there different numbers of disks and possible RAID levels?

Entry-level servers, such as the Dell PowerEdge R210, typically come with fewer disks and support less memory, which is sufficient for small business solutions. On the other hand, models like the Dell PowerEdge R730xd support a larger number of disks and greater memory capacity, offering extensive scalability for large corporate tasks.

We offer server models that support building RAID arrays at various levels. The most commonly used are RAID 0 and RAID 1:

* RAID 0: significantly boosts performance by writing data in parallel across multiple disks but does not provide data protection. Requires a minimum of 2 disks
* RAID 1: ensures data mirroring, significantly enhancing reliability but losing half of the available capacity. Requires a minimum of 2 disks

## How to configure RAID

The Customer Portal provides the ability to configure server disks using RAID technology both when ordering a dedicated server and after provisioning one. This functionality becomes available when:

* The server chassis and the selected operating system support RAID technologies
* More than one disk of the same size is selected in the server slots

To configure RAID, complete the following steps:

1. Select the server where RAID needs to be configured.
2. On the server configuration page:
   * Scroll to the **Operating system** section if the server is being ordered
   * Scroll to the **Disk upgrade** section and click **Upgrade** if the server is already ordered
3. Select the operating system if the server does not have one.
4. In the RAID section:
   * Automatic settings: select the RAID level for creating an array with automatic settings and proceed to step 8
   * Advanced settings: leave **Advanced settings (More HDDs, custom partitioning & more)** selected and scroll to the slots section
5. In the slots section, assign at least two free slots with drives of the same size and mark the checkbox next to each disk.
6. Click **Build RAID**.
7. In the pop-up window, select the RAID level.
   The **Make bootable** option means that the operating system will be installed and boot from this RAID array.
8. Click **Save**.
9. Configure partitions if required. More details can be found here.
10. Complete the server configuration by clicking **Order upgrade** or **Save**.
11. Confirm the action in the pop-up window by clicking **I'm sure, reinstall OS**.
12. Enter your account password in the pop-up window and click **Continue**.

## How to mount a disk drive

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**.
2. Choose the server and click **Details**.
3. Next to the **Disk upgrade** item, click **Upgrade**.
4. To choose a disk for mounting, find an available slot on the page and click **Replace drive**, or choose the default disk provided by the Customer Portal.
5. Click **Mount drive**.
   A **Disk Mount Overview** section will appear, allowing you to manage the disk partitions.
6. Choose a preferred date and time slot for the upgrade.
7. To apply the mounting, click **Order upgrade**.

## Disk partitions

### Linux/Unix-based systems

These settings show the disk space allocation on the main boot disk, including the allocation for boot files, virtual memory, and the main file system.

A mount point (target) is a location in the file system where a file system or storage device is attached.

When a drive is mounted, the operating system links its contents to a specific directory in the file system tree. This allows users and applications to interact with the data on the device as if it were part of the main file system.

Examples of mount points:

* `/boot` — the mount point for the partition containing boot files. This is usually a separate small partition necessary for booting the operating system. The `ext4` file system is commonly used for Linux
* `/` — the root mount point where the entire Linux file system resides. All other files and directories are located within this hierarchical tree
* `/home` — often used as a mount point for a separate partition containing user home directories
* `/mnt/usb` — can be used for mounting USB devices such as flash drives

Mount points allow for the organization and management of access to different file systems and devices within a unified namespace.

#### What is a target?

This configuration window displays the interface for setting up partitions in Linux, where you can select the mount point (target) for a new partition on a non-boot disk.

Here is a brief description of the available mount points:

* `/mount/` — a general folder for mounting additional file systems or devices on a non-boot disk. Used for temporary or permanent attachment of various devices
* `/home` — the directory where user home directories are located. Typically used for storing user data, settings, and files
* `/tmp` — the directory for temporary files. The system and applications use it for temporary data storage, which can be deleted after a reboot
* `/var` — the directory for variable data. This includes log files, mail spools, databases, and other frequently changing files
* `/var/log` — a subdirectory in `/var`, specifically designed for storing log files. System and application logs are recorded here
* `/usr` — the directory for installing software and user utilities. It houses most of the system's applications and utilities
* `/opt` — the directory for additional software packages and applications that are not included in the standard distribution packages. Used for installing third-party software

These mount points allow you to organize and structure the file system on a non-boot disk, distributing various types of data across the appropriate directories.

#### When do I need to change it?

Changing the target (mount point) for a new partition may be necessary in the following cases:

1. Separating user data: mount to `/home` to keep user data separate from system files
2. Improving performance: mount to `/var` or `/var/log` to isolate logs and variable data, reducing load on the main system
3. Security and stability: mount `/tmp` on a separate partition to prevent attacks and avoid filling up the main partition
4. Disk space management: mount to `/usr` or `/opt` for additional software and applications
5. Custom storage requirements: mount to `/mnt/` for applications needing dedicated storage space
6. Backup and restore: separate partitions simplify backup and restore processes
7. Multi-disk configurations: distribute data across multiple disks by mounting partitions on secondary disks, such as `/mnt/data`

Changing the mount point helps optimize performance, enhance security, and simplify system management.

#### What is swap?

Swap is a designated area on the disk that the operating system uses as additional virtual memory. This allows the server to continue operating even if the physical RAM is exhausted.

#### How does swap work?

When the RAM is full, the operating system moves less frequently used data from the RAM to the swap space on the disk. This frees up RAM for more critical tasks. When these data are needed again, they are moved back to the RAM.

### Windows OS

In Windows, mount points perform a similar function but are organized somewhat differently compared to UNIX/Linux systems. Here are the main concepts regarding mount points in Windows:

* Drive letters: mount points are typically represented by drive letters, such as `C:`, `D:`, `E:`, etc. Each storage device or partition usually receives its own drive letter. For example, the main disk where the operating system is installed is often designated as `C:`
* Mount points: you can also use mount points to attach a new partition or disk to an existing directory in the file system. This is similar to the method used in Linux. For instance, a new disk can be attached to the directory `C:\Data` instead of being assigned a separate drive letter
* `C:\Boot` folder: boot files are typically stored in the `C:\Boot` folder or other system directories such as `C:\Windows\Boot`
* Virtual memory (`pagefile`): the equivalent of the swap partition is called `pagefile`. It is located in the root directory of the main disk, usually as `C:\pagefile.sys`, and is used for virtual memory

Key points:

* Drive letters (e.g., `C:`, `D:`) are used to access main partitions and devices
* Mount points can be used to attach partitions to existing directories
* Boot files are stored in system folders (e.g., `C:\Boot`)
* Virtual memory is stored in `pagefile` on the main disk

Thus, mount points in Windows and Linux serve similar functions but are organized and represented in different ways.


# How to get OOB credentials via public API (/docs/ebm/get-oob-credentials-via-public-api)









OOB (Out-of-Band) is a method of remote server management that allows interaction with hardware via a separate network interface, independent of the operating system or primary network state.

You can find more details on accessing and authenticating to OOB and iDRAC in: [How to access the OOB management of a Dell server](/tutorials/idrac-setup/how-to-access-oob-management).

## GPG keys

A GPG (GNU Privacy Guard) key is a cryptographic tool used for encryption, decryption, digital signatures, and data authentication. It is based on asymmetric cryptography and consists of a key pair:

* **Public key** — used for encryption and verifying signatures.
* **Private key** — used for decryption and creating signatures.

GPG keys can be customized to meet specific requirements, including key length, algorithm, expiration date, and other parameters.

## Steps to obtain OOB credentials

The process of obtaining OOB credentials involves the following steps:

1. Add a GPG key to the Customer Portal and obtain its fingerprint.
2. Execute API requests to retrieve the server ID and OOB credentials.
3. Decrypt the received message using GPG decryption.

Detailed instructions for each step are provided below.

## Add a GPG key to the Customer Portal

Since GPG keys are used for sensitive tasks and require strict security control, their creation is the user's responsibility. Only users with the **Owner** role can add them to the Customer Portal. Unlike [SSH key generation](/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair), the Customer Portal only supports adding GPG keys with the RSA/RSA type.

To add your GPG key:

1. In the left-hand menu, navigate to **Identity and Access** → **SSH & GPG keys**.

2. Scroll to the **GPG keys** section and click **Create**.

3. In the **Public key** field, enter or paste your public key.

   Ensure the key is fully copied, including all lines from `-----BEGIN PGP PUBLIC KEY BLOCK-----` to `-----END PGP PUBLIC KEY BLOCK-----`, with no extra spaces or characters.

4. Enter the key name and click **Create**.

The public part of your GPG key will be added.

## Obtain a GPG key fingerprint in the Customer Portal

The GPG key fingerprint is a unique sequence of characters representing the hash of a public key. It is used in API requests and ensures the public key has not been altered during transmission. Additionally, the fingerprint serves as a compact identifier for authentication and key validation.

To display the key fingerprint:

1. In the Customer Portal, navigate to **Identity and Access** → **SSH & GPG keys** → **GPG keys**.
2. The fingerprint is displayed next to the added key.

## Obtain the server ID via Public API

Before you begin, ensure the following prerequisites are met:

* The required server is provisioned and ready.
* An API key has been created in the Customer Portal under **Identity and Access** → **API tokens**.

All Public API requests must include your authentication token and should be executed using `cURL` commands.

To obtain the server ID:

1. Make a GET request to the Public API:

   ```bash
   curl -g "https://api.servers.com/v1/hosts" -X GET \
     -H "Authorization: Bearer TOKEN"
   ```

   Replace `TOKEN` with your API key. The same request using the [srvctl CLI](/interfaces/cli), which reads the token from a saved context instead:

   ```bash
   srvctl hosts list
   ```

2. Find the server ID in the response list.

3. Alternatively, open the Customer Portal and navigate to **Dedicated Servers** → **Manage** → **Your\_Server** → **Details** → **ID**.

For this example, the server ID is `ex4mp1e`.

## Retrieve OOB credentials via Public API

To request OOB credentials via the Public API, you need your GPG key fingerprint. For this example, the fingerprint is `F1NGERPR1NT123456`.

```bash
curl -g "https://api.servers.com/v1/hosts/dedicated_servers/{server_id}/oob_credentials/?fingerprint={fingerprint}" -X GET \
  -H "Authorization: Bearer TOKEN"
```

The same request using `srvctl`:

```bash
srvctl hosts ebm get-oob-credentials {server_id} --fingerprint {fingerprint}
```

| Parameter     | Description                            | Example           |
| ------------- | -------------------------------------- | ----------------- |
| `server_id`   | The server ID                          | ex4mp1e           |
| `fingerprint` | GPG key fingerprint                    | F1NGERPR1NT123456 |
| `TOKEN`       | The API token from the Customer Portal | TtOo123KkEe456Nn  |

The API response will include a string called the **secret**, which contains data encoded in Base64 format.

## Decode the secret from Base64 format

### Linux/macOS

```bash
echo "base64-encoded-secret-string" | base64 --decode > decoded_secret.asc
```

Replace `base64-encoded-secret-string` with the actual secret from the API response. The decoded secret will be saved in `decoded_secret.asc`.

### Windows

1. Save the Base64-encoded secret to a file.
2. Use the `certutil` utility:

   ```
   certutil -decode inputfile decoded_secret.asc
   ```

   Where:

   * `inputfile` is the file containing the secret.
   * `decoded_secret.asc` is the file where the decoded secret will be saved.

After decoding, `decoded_secret.asc` will contain the secret in PGP MESSAGE format, encrypted using your private PGP key.

## Extract the OOB password using GPG decryption

Ensure you have the private key corresponding to the public key used for encryption. The key must be imported into your GPG keyring and have the `[E]` (encryption) attribute.

### macOS / Linux

#### Verify your keys

```bash
gpg --list-secret-keys
```

Example output:

```
sec   rsa4096 2025-01-24 [SC]      F1NGERPR1NT123456
uid           [ultimate] User Name <your-email>
ssb   rsa4096 2025-01-24 [E]
```

Where:

* The main key (`sec`) has `[SC]` attributes for signing and certification.
* The subkey (`ssb`) has the `[E]` attribute for encryption and decryption.

If no key with the `[E]` attribute is listed, you cannot decrypt the PGP message. Refer to [How to create a subkey](#how-to-create-a-subkey).

#### Decrypt the PGP message

```bash
gpg --decrypt decoded_secret.asc
```

Enter the passphrase for your private key if prompted. The output will include the password for OOB access.

### Windows

To decrypt the PGP message on Windows, you can use Kleopatra:

1. Download Kleopatra from its [official website](https://www.openpgp.org/software/kleopatra/) and install it.
2. Open Kleopatra, click **Import**, and select the private key file to import.

<img alt="Click Import in Kleopatra" src={__img0} />

3. Click **Decrypt/Verify**.

<img alt="Decrypt/Verify in Kleopatra" src={__img1} />

4. Select the file containing the decoded secret (e.g., `decoded_secret.asc`).

<img alt="Decoded secret file" src={__img2} />

5. Click **Save all** to save the decrypted output.

The OOB credentials will be saved in a newly created file.

## How to create a subkey

When working with GPG keys, you may encounter the error `used key is not marked for encryption use` when trying to decrypt data. This typically occurs when the main key `[SC]` does not support encryption and decryption. The steps below explain how to create an `[E]` (Encrypt) subkey to resolve this issue.

### macOS / Linux

1. List your keys:

   ```bash
   gpg --list-keys --keyid-format LONG
   ```

   Find the fingerprint for your main key (e.g., `F1NGERPR1NT123456LONG123456789`).

2. Edit the key:

   ```bash
   gpg --edit-key "F1NGERPR1NT123456LONG12345678"
   ```

3. Add a subkey:

   ```
   addkey
   ```

4. Configure the subkey:
   * Choose the subkey type, e.g., RSA (encryption only).
   * Set the key length, e.g., 3072 bits.
   * Define the key expiration date, or choose `0` for no expiration.
   * Confirm the creation and save changes:

     ```
     save
     ```

5. Verify the subkey:

   ```bash
   gpg --list-keys --keyid-format LONG
   ```

   Example output:

   ```
   sec   rsa4096 2025-01-24 [SC]      F1NGERPR1NT123456
   uid           [ultimate] Your Name <your-email>
   sub   rsa4096 2025-01-24 [E]
   ```

6. Export the updated public key:

   ```bash
   gpg --export --armor "your-email" > public_key.asc
   ```

7. Open `public_key.asc` and add the updated key to the Customer Portal under **Identity and Access** → **SSH & GPG keys** → **GPG keys**.

> If the fingerprint has changed, update your API request with the new fingerprint, then obtain and decode a new secret from Base64 format.


# Getting started (/docs/ebm/getting-started)



This article explains how to order a dedicated server through the Customer Portal, including how to configure its hardware, storage, networking, and payment options.

To order a dedicated server, complete the following steps:

1. Go to the Customer Portal.
2. In the left-hand menu, navigate to **Dedicated Servers** and select **Order**.
3. Use the **Filters** button to find a dedicated server that fits your requirements.
   These icons indicate the difference between the server location currency and the account currency.
4. In the configuration window, customize the following settings for your selected dedicated server:
   * **Location:** location where the server will be deployed
   * **RAM size:** amount of RAM
   * **Operating system:** the OS that will be installed on the server after provisioning is complete. You can choose and install the OS after ordering the server
   * Select the authentication method: **SSH key** and/or **Password**. This option will appear once you have selected the operating system in the previous step
   * **User data:** input your user data if necessary
   * **Storage:** configure the storage for your dedicated server:
     * Select the required number of disks
     * Add / Replace drive, where:
       * **Controller:** indicates the available controllers on the server to which drives can be mounted. In this example, the selected server has one controller with two available slots
       * **Type:** the type of disk
       * **Model:** a specific disk model and capacity. The price per month is displayed next to each model
     * **RAID:** configure the RAID array based on your performance and reliability needs, if applicable. Check the boxes next to the drives that will participate in the RAID array, then click **Create RAID**. The available RAID levels will appear depending on the selected disks. More details about RAID can be found in the article How to configure RAID.
       **Backplane:** a disk enclosure. Some servers may have multiple backplanes with separate controllers
     * Manage physical disks, where:
       * **Slot:** the slot number where the hard drive will be mounted
       * **Disk:** the disk model
       * **Mode:** shows if the disk is used as a standalone (`Single`) or as part of a RAID array (e.g., `RAID 1`)
       * **Capacity:** the disk capacity
       * **Price:** the monthly cost of each disk. Disks labeled as **Free** are included in the server configuration
       * **Replace disk** button: opens a list of available drives
       * **Mount** button: mounts the selected disk to the specified slot with further ability to manage disk partitions
       * **Remove disk** button: removes the drive from the slot
   * **Public uplink port:** provides the server with Internet access, allowing it to send and receive data from external sources
   * **Private uplink port:** connects the server to a private network, enabling secure and high-speed communication with other devices within the same network, separate from the public Internet
   * **Networks:** allows users to select additional network options for their server
   * **Bandwidth plan:** a plan based on data traffic usage. The "By traffic amount" option charges users for data usage beyond a specified limit, with overuse billed at a certain rate per GB per month
   * **Group:** groups dedicated servers together. This option is available if you have at least one ordered server. More details about dedicated server groups can be found in the article How to set a group of dedicated servers
   * **Quantity:** specifies the quantity of dedicated servers with the selected configuration
   * **Name:** assigns a name to the dedicated server
5. Once the server is configured, review the final details at the bottom of the window:
   * **Total Price:** the monthly rental price for the configured dedicated server
   * **The total price is calculated from:** a breakdown of selected services and their costs
   * **Cancel:** cancels the selected configuration and returns to the initial list of dedicated servers
6. Save the configuration and proceed to the cart by clicking **Save**.
7. Review the selected items in your cart and click **Buy Now**.
8. Click **Confirm**.
9. Choose a payment method. To pay for the dedicated server from your account balance, top up your account balance to cover the monthly rental. The account balance payment method will be available in the payment details window. More details can be found in the article Pay for the dedicated server from the account balance.

   Please note that when adding a payment method and making the first payment, identity verification may be required as part of the Know Your Customer (KYC) procedure to prevent violations of company policies. Details can be found in this article KYC.
10. Review the terms and conditions, and click **Proceed**.
11. In the new tab, enter your card details and click **Verify**.

Your order will be deployed according to the provisioning timeline.
To check the status of your ordered dedicated servers, click **View My Orders**.


# How to order an additional IP network (/docs/ebm/how-to-order-an-additional-ip)



Additional IP addresses or networks are often used to host multiple services or to implement custom routing and firewall configurations. This article explains how to order them for your dedicated server.

### Order additional IP addresses for a dedicated server

To order additional IP addresses:

1. Log in to the Customer Portal, navigate to **Dedicated Servers** → **Manage**, and select your server.

2. Scroll to the **Networks** section and click **Add Network**.

3. In the **Network type** dropdown, select **Public IP**.

4. Choose the `/32` network size.

   A `/32` network represents a single IP address, not a range. It is used to assign an individual IP alias to an existing network interface without allocating a subnet, gateway, or broadcast address.

   For more details, see the [Network sizes and reserved service addresses](#network-sizes-and-reserved-service-addresses) section below.

5. In the **Quantity** field, select the number of IP addresses to add.

6. Click **Add**.

The additional IP addresses will be provisioned within approximately five minutes.

### Order additional networks

> On Windows servers, only alias IP addresses can be allocated. Ordering a full public subnet is not supported.

To add a new network:

1. Log in to the Customer Portal, navigate to **Dedicated Servers** → **Manage**, and select your server.
2. Scroll to the **Networks** section and click **Add Network**.
3. In the **Network type** dropdown, choose one of the following:
   * Public IP
   * Private IP
   * Public IPv6 (can be assigned to a server only once; not available in locations with reduced redundancy)
4. Select the desired subnet size (for example, `/26`, `/27`, `/28`, etc.).
   Smaller prefixes (such as `/26`) offer more usable IP addresses, while larger prefixes (such as `/29`) provide fewer addresses.
5. Click **Add**.

The new network will be provisioned within approximately five minutes, depending on the number of networks being provisioned.

### Network sizes and reserved service addresses

The available network sizes depend on the type of location and the network architecture at that location. The network size determines the number of available IP addresses in a subnet. Subnets are used to divide larger networks into smaller segments, allowing for easier management of network resources and increased security. CIDR (Classless Inter-Domain Routing) notation is used to designate blocks of IP addresses and subnet masks, formatted as: **IP address** / **number of bits in the subnet mask**.

For example, a `/29` prefix indicates that out of the 32 bits of the subnet, 29 bits are used for the network part of the address, leaving three bits for hosts. This means the subnet can contain eight IP addresses:

* 5 can be assigned to user devices and our infrastructure devices
* 1 is reserved for the network address
* 1 is reserved for the gateway on the switch
* 1 is reserved for the broadcast address

Suppose the network IP address is 213.3.172.48 and the network size is `/29`. In this case, the IP addresses will be allocated as follows:

| IP address                 | Description                                                                            |
| -------------------------- | -------------------------------------------------------------------------------------- |
| 213.3.172.48               | Reserved for the network                                                               |
| 213.3.172.49               | Address of the first (r1) switch in the switch group (rbridge1)                        |
| 213.3.172.50               | Address of the second (r2) switch in the switch group (rbridge2)                       |
| 213.3.172.51               | Address of the virtual switch of the switch group — this is the gateway address        |
| 213.3.172.52               | Interface IP address (the first available IP address assigned to the server interface) |
| 213.3.172.53, 213.3.172.54 | Available unused IPs                                                                   |
| 213.3.172.55               | Reserved broadcast address of the network                                              |

Addresses of private and additional networks are allocated in the same manner.

To ensure redundancy, each dedicated server is allocated two `/29` networks: a private and a public network. This provides three usable IP addresses, of which we provide only one as a service.

You can order IPv4 subnets of the following sizes in the Customer Portal, along with the corresponding number of usable IP addresses:

| Network size | Total IPs | Usable IPs (standard location) | Usable IPs (reduced redundancy location) |
| ------------ | --------- | ------------------------------ | ---------------------------------------- |
| /32          | 1         | 1                              | 1                                        |
| /30          | 4         | unavailable                    | 1                                        |
| /29          | 8         | 3                              | 5                                        |
| /28          | 16        | 11                             | 13                                       |
| /27          | 32        | 27                             | 29                                       |
| /26          | 64        | 59                             | 61                                       |


# Enterprise Bare Metal (/docs/ebm)



**Enterprise Bare Metal** gives you a dedicated physical server exclusively to yourself - no shared components, no virtualization layer, and no noisy neighbors. Get iDRAC out-of-band access, full API and Terraform automation, and Dell hardware ranging from entry-level single-socket to high-density GPU configurations.

* **Full resource isolation** - dedicated CPUs, RAM, and disks with guaranteed performance
* **iDRAC OOB management** - remotely access, diagnose, and reinstall even an unresponsive server
* **API and Terraform automation** - provision, configure, and release servers programmatically
* **Flexible configurations** - entry-level to high-density storage and GPU chassis options

<DocCards>
  <DocCard title="Concepts" description="Understand server models, chassis types, provisioning, and included services." href="/ebm/concepts/" />

  <DocCard title="Billing" description="See how pricing is calculated and how cancellation terms work." href="/ebm/billing/" />

  <DocCard title="Provisioning" description="Learn what happens during server provisioning and expected timelines." href="/ebm/provisioning/" />

  <DocCard title="User Data" description="Pass custom scripts to servers at provisioning time using user data." href="/ebm/user-data/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Order and connect to your first Enterprise Bare Metal server." href="/ebm/getting-started/" />

  <DocCard title="Access Management" description="Connect to your server via SSH, VNC, or RDP." href="/ebm/access-management/" />

  <DocCard title="Create a Server via Public API" description="Provision a dedicated server programmatically using the REST API." href="/ebm/create-a-dedicated-server-via-public-api/" />

  <DocCard title="OOB Management" description="Access and use iDRAC for remote server management." href="/ebm/oob-management/" />
</DocCards>


# Limitations (/docs/ebm/limitations)



Limitations depend on a particular server model and its location. The below list general limitations for the Enterprise Bare Metal service.

### Provisioning

* Provisioning ETA is from 15 minutes when the ordered configuration is available in the rack, and 24 hours or more otherwise. If server hardware needs to be ordered or transported, provisioning time is determined by delivery deadlines.
* UEFI boot mode is supported only on Dell 12th generation and newer servers. Dell 11G, Supermicro, and Fujitsu servers support BIOS only.
* The following operating systems cannot be installed automatically via BIOS and require a UEFI-capable server:
  * VMware ESXi 8.0 x86\_64
  * VMware ESXi 7.0 x86\_64
  * FreeBSD 13 x86\_64

### Networks and IP addresses

* No more than 2 public networks per server: one main public network and one additional network.
* No more than 2 private networks per server: one main private network and one additional network.
* No more than 72 public IP addresses per server.
* No more than 72 private IP addresses in networks per server.
* No more than 64 additional `/32` IP addresses per server.
* Only one `/64` IPv6 network can be assigned per server. IPv6 is not available in locations with reduced redundancy.
* Uplinks can only be changed once per day via the Customer Portal.
* Only one public uplink port and one private uplink port per server.
* Disaggregating an uplink port disables redundancy for that port.

### Disk management

* RAID configuration is only available when the server chassis and selected operating system support RAID, and when more than one disk of the same size is selected.

### User data

* User data scripts cannot be modified after automatic OS installation is complete.
* The maximum user data script size without Base64 encoding is 16 KB.


# Network management (/docs/ebm/network-management)



Configuring the network infrastructure for dedicated servers is a crucial step in ensuring the reliability, security, and performance of your information systems.

In this article, we will cover the key aspects of configuration, including the use of public and private networks, uplink configuration, the application of disaggregation to optimize traffic, and the use of additional IPs (also known as alias IP) for flexible network address management. These elements will help you create an efficient and scalable network infrastructure to meet your business needs.

### Understanding public and private networks

Each server is equipped with at least two NICs (Network Interface Cards). One port on each NIC is used for a private network connection, and the other is for a public network connection.

Combining public and private networks offers several advantages:

1. **Flexibility and scalability:** using both types of networks allows for balancing between accessibility and security, which is especially important for hybrid and cloud solutions
2. **Enhanced security:** data that should not be accessible from the internet can be transmitted through private networks, reducing the risk of information leakage
3. **Load separation:** public networks can handle user requests, while private networks manage internal operations, improving overall system performance and reliability

Thus, public and private networks play key roles in the architecture of dedicated servers, ensuring the availability and security of data and services.

#### Public networks

Public networks are used for interaction between servers and external devices or users via the Internet. They are typically used for hosting websites, web applications, APIs, email servers, and other services accessible to users over the Internet.

Key concepts of public networks include:

1. **IP addresses**: public IP addresses are unique and reachable externally
2. **Security**: public networks employ security measures such as firewalls, VPNs, and other technologies to protect against unauthorized access and cyber threats
3. **Internet accessibility**: servers connected to public networks are accessible from anywhere via the internet

#### Private networks

Private networks are used for internal communication between servers and devices, ensuring secure data transfer for tasks like server-to-server communication, databases, backups, etc., bypassing the public internet.

Key concepts of private networks include:

1. **IP addresses**: devices use private IP addresses that are not routed through the Internet and are not accessible from the outside
2. **Security**: private networks provide a high level of security as access is restricted by internal rules and security policies
3. **Direct connect**: private networks enable direct connect, providing a direct, fast, and reliable connection
4. **L2 segmentation**: private networks enable L2 segmentation to isolate traffic and improve management through the use of virtual local area networks (VLANs)

#### Network size

The available network sizes depend on the type of location and the network architecture at that location. The network size determines the number of available IP addresses in a subnet. Subnets are used to divide larger networks into smaller segments, allowing for easier management of network resources and increased security. CIDR notation (Classless Inter-Domain Routing) is used to designate blocks of IP addresses and subnet masks, formatted as: **IP address** / **number of bits in the subnet mask**.

For example, a `/29` prefix indicates that out of the 32 bits of the subnet, 29 bits are used for the network part of the address, leaving 3 bits for hosts. This means the subnet can contain 8 IP addresses:

* 5 can be assigned to user devices and our infrastructure devices
* 1 is reserved for the network address
* 1 is reserved for the gateway on the switch
* 1 is reserved for the broadcast address

Suppose the network IP address is `213.3.172.48`, and the network size is `/29`. In this case, the IP addresses will be allocated as follows:

* `213.3.172.48` – reserved for the network
* `213.3.172.49` – address of the first (r1) switch in the switch group (rbridge1)
* `213.3.172.50` – address of the second (r2) switch in the switch group (rbridge2)
* `213.3.172.51` – address of the virtual switch of the switch group. This address is the gateway address in the network
* `213.3.172.52` – interface IP address (the first available IP address assigned to the server interface)
* `213.3.172.53`, `213.3.172.54` – available unused IPs
* `213.3.172.55` – reserved broadcast address of the network

Addresses of private and additional networks are allocated in the same manner.

To ensure redundancy, each dedicated server is allocated two `/29` networks: a private and a public network. This provides 3 usable IP addresses, of which we provide only one as a service.

**We cannot add PTR records to the remaining two IP addresses. For this, you can order an additional IP or an additional network and then assign PTR to it.**

### Network configuration

In the Customer Portal, you can view and manage the current network configurations. It is accessible through the following steps:

1. Open the Customer Portal and navigate to **Dedicated Servers** → **Manage**
2. Select the server you need to configure the networks for and scroll down to the **Networks** section

The **Default** network is configured automatically during OS installation, whereas **Additional** networks require manual configuration.

#### How to add a network

To add a network:

1. In the **Networks** section and click **Add Network**
2. In the **Network type** dropdown, select the desired network type and size (e.g., `Public IP` with a `/27` prefix)
   Available options include:

   * **Public IP**
   * **Private IP**
   * **Public IPv6** (can be assigned to a server only once; not available in locations with reduced redundancy)

   Note: available network types and subnet sizes depend on the server's operating system and the location type (standard or reduced redundancy). For more details, see the Network size and Billing and limitations for additional IPs and networks sections.
3. Click **Add**

The new network will be provisioned within approximately 5 minutes, depending on the number of allocated networks.

#### How to remove a network

To remove a network:

1. In the **Networks** section, click the trash can icon next to the network you want to delete
2. Confirm the action by clicking **Proceed**

If the dedicated server has more than one IP address for either the private or public network, you cannot remove the default IP address, only the additional ones.

#### How to order additional IP address(es)

Additional IP addresses can be assigned to one or more network interfaces of a dedicated server. These IPs can be added to an L2 segment.

##### Key aspects

1. **Efficient use of a single interface**: additional IPs enable one interface to handle traffic for multiple IP addresses, saving resources and simplifying network management
2. **Increased network flexibility**: administrators can organize various services and applications on a single server using different IP addresses. This also allows hosting multiple websites on one server, each with its own IP address
3. **Enhanced security and service isolation**: different services (e.g., web server and mail server) can be assigned separate IP addresses, improving security and allowing specific access controls for each application or service
4. **Simplified traffic management**: managing traffic related to different IP addresses is simplified, allowing for more detailed control and routing of network traffic

Additional IP management requires a deployed L2 segment of the public type network. For more details, refer to the L2 Segments - Getting started article.

To order additional IP, complete the following steps:

1. In the **Networks** section, click **Add Network**
2. In the **Network type** dropdown, select **Public IP**
3. Choose the `/32` network size — `/32` represents a single IP address, not a range. It's used to assign an individual additional IP to an existing network interface without allocating a subnet, gateway, or broadcast address
4. In the **Quantity** field, select the number of IP addresses to add. Please note: the Customer Portal has a limit of creating no more than 64 additional IP addresses. For more details, see the Billing and limitations for additional IPs and networks section.
5. Click **Add**

The additional IP address(es) will be allocated within approximately 5 minutes.

#### How to manage uplinks

To manage uplinks:

1. Navigate to **Dedicated Server** → **Manage**
2. Choose the server and click **Details**
3. Scroll to the **Uplinks** section and click **Change**

In the opened window, you can manage the following configurations:

##### Public uplink port

* 1 Gbps with redundancy: this is a public connection with a bandwidth of 1 gigabit per second
* The "with redundancy" option means that there are two or more physical connections providing network or internet access. If one connection fails, traffic automatically switches to the backup connection, enhancing network reliability and fault tolerance

##### Private uplink port

* 1 Gbps without redundancy: this is a private connection with a bandwidth of 1 gigabit per second
* The "without redundancy" option means that there is only one physical connection. If this connection fails, network or internet access will be lost until the issue is resolved. This option is provided for free

##### Public bandwidth plan

* The public bandwidth plan determines the amount of data that can be transmitted through the public connection.
* For example, a plan with "By traffic amount 20002 GB" means the server can send and receive up to 20002 gigabytes of data during the billing period, which is one month. Exceeding this limit will incur additional charges at the rate of €0.03 per additional gigabyte

Uplinks cannot be changed in the Customer Portal more than once per day.

##### How to disaggregate an uplink port

Disaggregating an uplink port means separating or altering the routing of traffic managed by that port. This process may be necessary to redistribute traffic load and enhance overall network performance.

To disaggregate an uplink port:

1. On the uplink configuration page, next to the required port, click **Disaggregate**
2. In an opened window, confirm your action by clicking **Disaggregate**
3. To confirm this action, enter your account password in the pop-up window and click **Continue**

Please note, disaggregating will disable redundancy for the port if it was previously enabled.

#### Tagged trunks in an L2 segment

##### Introduction

Please note that VLAN, VXLAN, and VLAN tagging are complex concepts. This article is not intended as an introduction to those concepts.

The L2 segments service (also known as broadcast domains) allows the creation of virtualized Layer 2 (L2) subnets or segments over an underlying Layer 3 (L3) network. From the technical standpoint, an L2 segment is a set of VLANs interconnected using the VXLAN protocol. VLANs are provisioned per L2 segment, per server rack.

\[Diagram: VLAN and VXLAN configuration]

These are Ethernet frames transmitted without any tags in the standard VLAN configuration with native connections.

These are Ethernet frames to which the trunk ports of network switches add VLAN tags. For example VLAN 2006. This tagging allows for the identification and management of frames as they traverse multiple VLANs.

#### How to configure tagged trunks

When adding a server to an L2 segment with a trunk type connection, proper network operation requires configuring IEEE 802.1Q tagging in the server's operating system. For this, you will need the VLAN ID number.

##### Getting VLAN ID for the server

You can find it in two places in the Customer Portal:

\[Link to server details page]

\[Link to L2 segment details page]

Note that VLAN IDs for different servers within the same L2 segment may vary from rack to rack. Therefore, you should obtain the VLAN ID for each server individually.

##### Using the ip utility

The `ip` utility comes with most Linux distributions. To enable 802.1Q tagging on the `aggi` interface with a static IP address (for example, `172.16.0.1/16`) and VLAN ID (for example, VLAN ID 2006), execute the following command:

```
ip link add link aggi name vlan2006 type vlan id 2006
ip address add 172.16.0.1/16 dev vlan2006
ip link set vlan2006 up
```

Note that this configuration will not persist after a reboot.

##### Using interface configuration files

To create a subinterface with 802.1Q tagging enabled, VLAN ID (e.g., VLAN ID 2006), and a static IP address (e.g., `172.16.0.1/16`) on the Ethernet interface `aggi`, follow the instructions provided below.

###### CentOS

* Add a new configuration file: `/etc/sysconfig/network-scripts/ifcfg-aggi.2006`

  Ensure that the file name follows the naming convention for VLAN interfaces described in the naming scheme for VLAN interfaces.

* Edit the file and add the following configuration:

  ```
  ONBOOT=yes
  TYPE=Ethernet
  VLAN=yes
  DEVICE=aggi.2006
  BOOTPROTO=static
  IPADDR=172.16.0.1
  NETMASK=255.240.0.0
  ```

* Restart the network service:

  ```
  systemctl restart network
  ```

###### Ubuntu

* Install the VLAN package:

  ```
  apt update && apt install vlan
  ```

* Add configuration to the `/etc/network/interfaces` file:

  ```
  auto aggi.2006
  iface aggi.2006 inet static
      address 172.16.0.1
      netmask 255.240.0.0
      vlan_raw_device aggi
  ```

##### Configuring tagged trunks on Windows Server 2012 R2 / 2016 / 2019

When a tagged VLAN is configured on the switches, to configure tagged trunks, you need to specify this VLAN on the server. To do this, complete the following steps:

1. Go to NIC teaming settings and navigate to the **Teams** section
2. Select the team group (in this case, `aggi`) for which you need to create a VLAN interface
3. In the **Adapters and Interfaces** section, click the drop-down list **Tasks** and select **Add Interface**
4. Save the settings by clicking **Apply**, and then click **OK**

The VLAN interface will be created, and you can now configure the necessary network on it.

#### Billing and limitations for additional IPs and networks

|                              | Billing  | Proration                                           | Limitations                                                                                                                                                                                                                                              | Notes                                                                    |
| ---------------------------- | -------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| **Additional IPv4 networks** | Pre-paid | Prorated by days                                    | No more than 2 public networks: one main public network + one additional network. No more than 2 private networks: one main private network + one additional network. No more than 72 public IP addresses. No more than 72 private addresses in networks | All IP addresses in the network are billed, not just the usable ones     |
| **Additional IPv6 networks** | Pre-paid | Monthly cost, regardless of the number of days used | Only one `/64` IPv6 network                                                                                                                                                                                                                              | The network cost is fixed and does not depend on the number of addresses |
| **Additional IP**            | Pre-paid | Prorated by days                                    | No more than 64 additional IPs                                                                                                                                                                                                                           |                                                                          |
| **Uplink (with redundancy)** | Pre-paid | Prorated by days                                    | Only one public port and one private port                                                                                                                                                                                                                |                                                                          |

### Traffic billing

Traffic within the private network is free of charge, including traffic between servers located in different data centers. Incoming traffic is also free and unlimited.

Only outgoing traffic on the public network is billed, regardless of whether the primary, additional public network, or additional IP was used. Traffic overuse is calculated based on the rate.

To monitor traffic expenses, keep an eye on the traffic usage statistics on the server page in the Customer Portal under the **Traffic usage** section.

Do not ignore notifications about traffic consumption. The Customer Portal sends automatic notifications to the **primary** and **technical** contacts when 50%, 80%, and 100% of the traffic package has been consumed.


# OOB management (/docs/ebm/oob-management)



OOB (Out-of-Band) is a method of remote server management and monitoring conducted via a separate and independent communication channel. This method provides access to the hardware integrated into the server's motherboard.

In the Customer Portal, there is a page where you can view and manage the OOB. It is accessible through the following steps:

1. Open the Customer Portal and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. Scroll to the **OOB** section

This section contains the configurations and credentials related to OOB.

### How to access the OOB management of a Dell server

For Dell servers, OOB management is performed using iDRAC (Integrated Dell Remote Access Controller).

iDRAC offers hardware-level access to the server, allowing administrative tasks to be performed even if the primary network fails, the operating system is down, or the server is powered off. iDRAC management is available through both a web interface and a command-line interface. Key features include server power management, hardware sensor monitoring, remote console capabilities, access to virtual media, and remote OS installation, including custom images.

To access iDRAC, you will need the iDRAC IP address and the corresponding credentials.

#### Authentication in iDRAC

Authentication can be done in two ways:

* **Using OOB and VPN credentials**
  For security purposes, the OOB management network for your servers is isolated and accessible via VPN. Use the provided VPN credentials to connect to the OOB network, then access the iDRAC interface with the iDRAC IP address and local credentials
* **Temporary 24-hour access**
  For your convenience, you can temporarily enable access to the iDRAC interface of a specific server over the Internet without needing to connect to the VPN. This temporary access will be active for 24 hours, but you can disable it earlier if needed

##### OOB and VPN credentials

To get access to iDRAC with OOB and VPN credentials, complete the following steps:

1. In the **OOB** section, click **Credentials**
2. Enter your account password and click **Continue**
   In the opened window, you will see the access details
3. Launch VPN on your computer using the provided credentials. In the **Setup manuals** section, you will find instructions for popular operating systems on how to set up and launch the VPN
   * **VPN server**: the access point for connecting to the VPN. The server address and credentials are entered in the VPN client software settings. After successful connection, all data transmitted between the user's device and the VPN server will be encrypted, and the user will receive an IP address associated with this VPN server
   * **Shared secret**: a key used to authenticate both parties (client and server) when establishing a VPN connection. This authentication method is often used in VPN protocols such as L2TP/IPsec and IKEv2. The shared secret is usually specified in the configuration files or settings of the VPN client and server
4. Open your browser and enter the IP address for accessing the iDRAC interface of a specific server
5. Authenticate using the credentials from the OOB credentials section

##### Temporary 24-hour access

To get temporary 24-hour access to iDRAC with OOB credentials, complete the following steps:

1. In the **OOB** section, click **Enable public access for 24 hours**
2. In the opened window, click **Enable**
3. To confirm this action, enter your account password in the pop-up window and click **Continue**

##### How to disable temporary 24-hour access

When the work with iDRAC is complete, you can disable temporary access to the OOB network by clicking the **Disable public access** button.

Please note, this button does not appear immediately. It will become available once the network reconfiguration by our automation system is complete.

##### How to reset OOB credentials

To reset OOB credentials:

1. In the **OOB** section click **Reset OOB credentials**
2. Click **Reset** to confirm
3. In the opened window, enter your account password and click **Continue**

OOB credentials will be reset.

##### How to reset VPN credentials

To reset VPN credentials:

1. In the **OOB** section, click **Reset VPN credentials**
2. Click **Reset** to confirm
3. In the opened window, enter your account password and click **Continue**

VPN credentials will be reset.

#### How to access iDRAC

To access iDRAC, complete the following steps:

1. Type the IP address of your server's iDRAC interface into your browser's address bar. The browser will warn you about an insecure connection due to the self-signed HTTPS certificate
2. Add an exception
3. Enter the previously obtained iDRAC credentials on the iDRAC authentication page

After logging in, you will be able to manage server settings, view the service tag, use the virtual console, and mount virtual media from local or remote (SMB) images.

#### How to configure iDRAC to use the HTML5 plug-in for virtual console

##### iDRAC versions and virtual console plug-in types

iDRAC allows you to switch between Java, ActiveX and HTML5-based plugins for virtual console capabilities and virtual media access. The HTML5 plug-in is the default plug-in in iDRAC 9. iDRAC versions 7 and 8 initially had support for Java and ActiveX. HTML5 support was added in the firmware version `2.30.30.30`.

The majority of our DELL PowerEdge servers are of the 14th, 13th, and 12th generations, meaning iDRAC versions vary from iDRAC 9 to iDRAC 7.

| Generation | Series | iDRAC version | HTML5 support         | Documentation |
| ---------- | ------ | ------------- | --------------------- | ------------- |
| Rx4x       | 14th   | iDRAC 9       | Out of the box        | User Guide    |
| Rx3x       | 13th   | iDRAC 8       | Since FW `2.30.30.30` | User Guide    |
| Rx2x       | 12th   | iDRAC 7       | Since FW `2.30.30.30` | User Guide    |

How to determine the iDRAC version is described in this article How to identify the iDRAC version embedded in a Dell EMC PowerEdge server.

A detailed guide on how to update the iDRAC firmware is provided in this article How to update iDRAC.

##### How to set up the virtual console on iDRAC 7 and 8

To configure virtual console using iDRAC Web interface:

1. In the iDRAC Web interface, navigate to **Overview** → **Server** → **Virtual Console**
   The Virtual Console page is displayed
2. Enable virtual console and specify the required values. For information about the options, see the **iDRAC Online Help** on the official Dell web site
3. In the **Plug-in Type** field, select **HTML5**
4. Click **Apply**

The virtual console is configured.


# Power management (/docs/ebm/power-management)



Power management covers the tools and methods available for controlling your dedicated server's power state — rebooting, switching off, and recovering from critical failures. This article explains how to perform these actions through the Customer Portal and VNC console, and how to use rescue mode to restore a server that is unable to boot normally.

### Power management via Customer Portal

Rebooting and switching down the server via the Customer Portal is done by sending a command to the PDU automation, which turns off the power to the outlet to which the server is connected. This shutdown method can cause software, filesystem, or server component failures. To avoid, protection mechanisms are installed on both the PDU automation and the server.

When the protection is triggered, the PDU will prevent the server from rebooting or shutting down, and the notification will appear on the Customer Portal page:

`"Power management is currently unavailable because of a running operation on the server. Please try again later."`

This occurs when there is an ongoing automation task on the server or the server is in maintenance mode. This could be due to operations performed by the Servers.com team or tasks initiated by the server users, such as firmware updates or failure diagnostics.

#### How to reboot the dedicated server

Rebooting a server may be required to resolve accumulated system errors, apply software updates or other purposes.

The server can be rebooted in two ways: via the Customer Portal and via the VNC console.

##### Customer Portal

To reboot the server via the Customer Portal, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. Scroll to the **Power** section and select **Reboot**
4. To confirm this action, enter your account password in the pop-up window and click **Continue**

The server will be rebooted. You can check the server status in the **Status** field in this section. If the status does not change, try using the **Refresh** button.

If the server does not reboot, refer to the **Power management via Customer Portal** section above for detailed information.

##### VNC console

To reboot the server via the VNC console, complete the following steps:

1. Open the Customer Portal and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. In the **Details** section, click **VNC console** and confirm your action by entering your account password in the opened window
4. In the opened console, click ▹ to open the control bar → **Show Extra keys** → **Send Ctrl+Alt+Delete**

The server will be rebooted.

#### How to switch off the dedicated server

Temporary server shutting down allows for scheduled maintenance, equipment replacement, or upgrades without risking data corruption.

The server can be switched off in two ways: via the Customer Portal and via the VNC console.

##### Customer Portal

To switch off the server via the Customer Portal, complete the following steps:

1. Open the Customer Portal and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. Scroll to the **Power** section and select **Off**
4. To confirm this action, enter your account password in the pop-up window and click **Continue**

The server will be switched off. You can check the server status in the **Status** field in this section. If the status does not change, try using the **Refresh** button.

If the server does not switch off, refer to the **Power management via Customer Portal** section above for detailed information.

##### VNC console

To switch off the server via the VNC console, complete the following steps:

1. Open the Customer Portal and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. In the **Details** section, click **VNC console** and confirm your action by entering your account password in the opened window
4. In the opened console:
   * For Linux-based systems, execute the following command:
     ```
     shutdown -h
     ```
   * For Windows systems, click ▹ to open the control bar → **Show Extra keys** → Click the Windows icon → **Shutdown**

The server will be switched off.

As long as the dedicated server is not canceled, the billing for bare-metal and all its additional services is charged at the standard rate, even if the server is switched off.

#### What is the rescue mode?

Rescue mode is a useful feature for dedicated and cloud servers, allowing you to diagnose, fix problems and restore server functionality in case of failures. This feature is accessible to users via the Customer Portal control panel.

Imagine that something went wrong with the OS configuration; for example, the GRUB loader configuration file is corrupted, and the server shows a black screen and is unable to boot:

In cases where the OS is affected by critical system errors or the server is unable to boot properly, rescue mode may come in handy.

This issue might be solved in a number of ways, one of which is using rescue mode.

#### How to restore a dedicated server using rescue mode

In rescue mode, the server connection occurs via a public IP address, so it's essential that the server has a configured public network to utilize this function.

Please note that when using rescue mode, server power outlets are rebooted, and the server shuts down immediately. This can potentially cause database failures and damage to the OS filesystem. Therefore, when enabling rescue mode, it's crucial to perform a graceful shutdown to allow the operating system to properly terminate all services.

To enter rescue mode, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**

2. In the **My servers** section, choose the server and click **Details**

3. Click the **Reboot to rescue** button and wait for an email with temporary login credentials (this usually takes up to 10 minutes)

   The email will be sent to Contacts with **Primary** and **Technical** roles

4. Use credentials to access the server via SSH:

   ```
   $ ssh 123.45.67.89 -l root
   Warning: Permanently added '123.45.67.89' (RSA) to the list of known hosts.
   root@123.45.67.89's password:
   * Welcome to DMGMTSrvInit 1.0 x86_64 [based on CentOS 6 x86_64]
   Dell OpenManage Deployment Toolkit:
   - RAID:    raidcfg
   - DRAC:    racadm4, racadm5, idracadm7
   - BIOS:    syscfg
   - SYSTEM:  omconfig, omreport, dsu
   Additional utils:
   - RAID:    mdadm
   - FS:      lvm, xfs, jfs, e2fs, nfs, ntfs, dosfs, parted, fdisk, cfdisk, sfdisk, grub
   - EDITORS: vi, nano, joe
   - SYSTEM:  dmidecode, smartmontools, testdisk, hddtemp, lshw, memtester, ipmitool
   - NETWORK: ethtool, tcpdump, mtr, traceroute, tcptraceroute, nmap, dstat
   - TOOLS:   rsync, lftp, curl, wget, nc, screen, mc, chkrootkit
   You can check speedtest files in your browser, url: http://<server ip>/
   ```

   A list of useful commands is displayed upon login

5. To recover the GRUB configuration file, complete the following steps:
   1. Get the list of available disks and partitions using the `lsblk` command

      ```
      [root@dmgmtsrvinit.pxe ~]# lsblk
      NAME                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
      sdb                                 8:16   0  1.8T  0 disk
      ├─sdb1                              8:17   0    1M  0 part
      ├─sdb2                              8:18   0  500M  0 part
      │ └─md127                           9:127  0  500M  0 raid1
      └─sdb3                              8:19   0  1.8T  0 part
        └─md126                           9:126  0  1.8T  0 raid1
          ├─C1500302784I0-home (dm-0)   253:0    0  1.8T  0 lvm
          ├─C1500302784I0-rootfs (dm-1) 253:1    0   10G  0 lvm
          └─C1500302784I0-swap (dm-2)   253:2    0    2G  0 lvm
      sda                                 8:0    0  1.8T  0 disk
      ├─sda1                              8:1    0    1M  0 part
      ├─sda2                              8:2    0  500M  0 part
      │ └─md127                           9:127  0  500M  0 raid1
      └─sda3                              8:3    0  1.8T  0 part
        └─md126                           9:126  0  1.8T  0 raid1
          ├─C1500302784I0-home (dm-0)   253:0    0  1.8T  0 lvm
          ├─C1500302784I0-rootfs (dm-1) 253:1    0   10G  0 lvm
          └─C1500302784I0-swap (dm-2)   253:2    0    2G  0 lvm
      ```

      Seems like disk `/dev/mapper/C1500302784I0-rootfs` contains the root partition and disk `/dev/md127` contains `/boot`

   2. Mount these partitions:

      ```
      mkdir /mnt/root
      mount /dev/mapper/C1500302784I0-rootfs /mnt/root
      mount /dev/md127 /mnt/root/boot
      ```

      You'll also need to mount several other partitions in order to make the `grub2-mkconfig` command work properly:

      ```
      mount -o bind /dev /mnt/root/dev
      mount -o bind /sys /mnt/root/sys
      mount -t proc none /mnt/root/proc
      ```

   3. Change the root directory using the `chroot` command:

      ```
      chroot /mnt/root
      ```

   4. Execute the `grub2-mkconfig` command, which will generate new GRUB configuration file:

      ```
      [root@dmgmtsrvinit.pxe /]# grub2-mkconfig -o /boot/grub2/grub.cfg
      Generating grub configuration file ...
      WARNING: Failed to connect to lvmetad. Falling back to device scanning.
      WARNING: Failed to connect to lvmetad. Falling back to device scanning.
      Found linux image: /boot/vmlinuz-3.10.0-514.26.2.el7.x86_64
      Found initrd image: /boot/initramfs-3.10.0-514.26.2.el7.x86_64.img
      Found linux image: /boot/vmlinuz-3.10.0-514.el7.x86_64
      Found initrd image: /boot/initramfs-3.10.0-514.el7.x86_64.img
      Found linux image: /boot/vmlinuz-0-rescue-7dafe89409d74ef2a70c495f0148d7e3
      Found initrd image: /boot/initramfs-0-rescue-7dafe89409d74ef2a70c495f0148d7e3.img
      WARNING: Failed to connect to lvmetad. Falling back to device scanning.
      WARNING: Failed to connect to lvmetad. Falling back to device scanning.
      done
      ```

      The command executed successfully, apart from a few warning messages

   5. Exit the chroot and shut down the server properly:

      ```
      [root@dmgmtsrvinit.pxe /]# exit
      [root@dmgmtsrvinit.pxe ~]# shutdown -h now
      Broadcast message from root@dmgmtsrvinit.pxe (/dev/pts/0) at 18:29 ...
      The system is going down for halt NOW!
      [root@dmgmtsrvinit.pxe ~]# Connection to 123.45.67.89 closed by remote host.
      ```

#### How to exit rescue mode

As soon as recovery work is finished, click the **Exit rescue mode** button in the Customer Portal. The server will exit rescue mode and boot normally the OS installed on its disks.


# Prometheus metrics in Public API (/docs/ebm/prometheus-metrics-in-public-api)



Servers.com provides data on traffic consumption for dedicated servers and the number of servers in the OpenMetrics format, which can be handled by [Prometheus](https://prometheus.io/), [VictoriaMetrics](https://victoriametrics.com/), or other monitoring software. To access the data, make an [API request to the /v1/metrics/hosts endpoint](https://developers.servers.com/api-documentation/v1/#tag/Metrics).

### Metrics format

The metrics are provided in the following formats:

#### 1. Number of hosts within a location: `serverscom_hosts_count`

```
serverscom_hosts_count{chassis_name="Dell R450",host_type="dedicated_server",location_id="1",location_code="AMS1",rack_id="eX4mPle",rack_type="shared"} 5
```

| Label           | Description                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------- |
| `chassis_name`  | A human-readable name of a chassis.                                                                     |
| `host_type`     | Indicates whether it's a standalone dedicated server or a server included as part of a managed service. |
| `location_id`   | A unique identifier of a location.                                                                      |
| `location_code` | Another identifier of a location.                                                                       |
| `rack_id`       | A unique identifier of a rack.                                                                          |
| `rack_type`     | A private or shared rack.                                                                               |
| *(value)*       | The quantity of hosts at the moment of the request.                                                     |

#### 2. Outgoing traffic from a host: `serverscom_host_monthly_sent_bytes_total`

```
serverscom_host_monthly_sent_bytes_total{host_id="eX4mPle",title="test-host-server-ams1",traffic_type="private",chassis_name="Dell R220",host_type="dedicated_server",location_id="1",location_code="AMS1",rack_id="eX4mPle",rack_type="shared"} 77972
```

| Label           | Description                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------- |
| `host_id`       | A unique identifier of a host.                                                                          |
| `title`         | A human-readable identifier of a host.                                                                  |
| `traffic_type`  | Private or public traffic.                                                                              |
| `chassis_name`  | A human-readable name of a chassis.                                                                     |
| `host_type`     | Indicates whether it's a standalone dedicated server or a server included as part of a managed service. |
| `location_id`   | A unique identifier of a location.                                                                      |
| `location_code` | Another identifier of a location.                                                                       |
| `rack_id`       | A unique identifier of a rack.                                                                          |
| `rack_type`     | A private or shared rack.                                                                               |
| *(value)*       | A counter of traffic in bytes.                                                                          |

#### 3. Inbound traffic to a host: `serverscom_host_monthly_received_bytes_total`

```
serverscom_host_monthly_received_bytes_total{host_id="eX4mPle",title="test-host-server-ams1",traffic_type="private",chassis_name="Dell R220",host_type="dedicated_server",location_id="1",location_code="AMS1",rack_id="eX4mPle",rack_type="shared"} 77972
```

Labels are the same as for `serverscom_host_monthly_sent_bytes_total` above.

***

> The metrics counter displays the value for the current month and is reset to zero on the first day of each new month (UTC timezone). All traffic metrics are shown in bytes.

### Use cases

You can process metrics using your own scripts and tools or with third-party software. The most common setup uses Prometheus alongside Grafana.

Below is an example Prometheus configuration to fetch metrics from the Servers.com API endpoint:

```yaml
scrape_configs:
  - job_name: 'serverscom_hosts'
    scrape_interval: 60s
    authorization:
      type: "Bearer"
      credentials: "eX4mPle_oF_puBlicAp1.TokEN"
    static_configs:
      - targets: ['api.servers.com']
    metrics_path: /v1/metrics/hosts
    scheme: https
```

The `credentials` value is your Public API token, available in the [Public API section](https://portal.servers.com/profile/api-tokens) of the Customer Portal.

> Each call to the endpoint counts against your request limit — typically 2,000 requests per hour. For up-to-date limit information, see the [Rate limits section](https://developers.servers.com/api-documentation/v1/#section/Rate-limits) of the Public API documentation.

Refer to the [Prometheus](https://prometheus.io/docs/introduction/first_steps/) and [Grafana](https://grafana.com/docs/grafana/latest/setup-grafana/installation/) documentation for guidance on setting up monitoring.

### Metrics gap

In case of a connectivity issue, there may be a gap when metrics are not sent. When connectivity is restored, all delayed data will flow out rapidly, causing a spike in charts. This peak does not represent actual traffic consumption — it contains delayed data from a previous period.


# Provisioning (/docs/ebm/provisioning)



Server provisioning is an automated process that prepares a server after it is ordered. It includes configuring network settings, checking connections, setting up necessary services, and installing the operating system.

Provisioning ETA:

* From 15 minutes - the ordered server configuration is available in the rack
* 24 hours or more - the ordered server is not currently in the rack or configuration changes are needed

If server hardware needs to be ordered or transported, the server provisioning time is determined by the delivery deadlines.

For tasks where provisioning ETA is critical, we offer the [Scalable Bare Metal](/sbm) solution. These pre-configured servers with fixed configurations are integrated into the infrastructure, significantly speeding up provisioning.

During provisioning, the server appears as "Pending" in the Customer Portal. Once completed, the server reboots into the selected OS (if ordered), and its status changes to "Active", meaning it is ready for use.

### Server selection

At this stage, the server is selected based on the following criteria:

* It matches the ordered configuration and is available for installation
* The firmware has been recently updated via our automated system for unleased servers
* New servers are placed near your existing servers in the same location to minimize private network latency
* When conditions are equal, we place servers in the least occupied rack (POD) to maximize future scalability

### Powering on the server

Unlike many hosting providers, we keep servers powered off until they are leased (except during brief firmware updates). This helps to reduce wear on the hardware and save energy.

Before provisioning starts, the selected server is powered on.

### Switch groups

At this stage, we determine which switches the server connects to:

* Two private network switches
* Two public network switches
* One out-of-band (OOB) management switch

### Cloud private network (CPN) assignment

When you order a dedicated server for the first time, we notify all Servers.com cloud regions about the new client and assign you a private network.

The Cloud Private Network provides secure communication between your dedicated and cloud servers across all our data centers.

### Private, public, out-of-band management network and alias IP allocation

At this stage, the necessary networks are assigned to your server.

By default, a `/23` subnet from the `10.0.0.0/8` private range is allocated using a sparsest allocation strategy, allowing easy future expansion without changing IP addresses (only adjusting the subnet mask).

### UEFI and BIOS

Servers are configured in UEFI mode by default, supported by modern servers and operating systems.

Supported boot modes by server model are as follows:

* Dell 11G - BIOS
* Dell 12G and newer - UEFI, BIOS
* Supermicro - BIOS
* Fujitsu - BIOS

UEFI is supported only on Dell 12th generation and newer servers.

Some operating systems cannot be installed automatically via BIOS, including:

* VMware ESXi 8.0 x86\_64
* VMware ESXi 7.0 x86\_64
* FreeBSD 13 x86\_64

### OS installation

The OS is installed using official installers and repositories.

Your network settings and disk partitioning scheme are applied using automatically generated kickstart files.

This is the longest stage, taking up to 90% of the provisioning time.

### Availability check

After OS installation, we verify that the server boots correctly and is accessible over public, private, and OOB networks.

### VNC access setup

At this stage, we set up access to your server via the VNC console.

We create a WebSocket-to-VNC proxy, linked to the specific server.

Access is provided through iDRAC Enterprise - an integrated KVM-over-IP solution for Dell servers.

### Notification

An email with the server access credentials is sent once the provisioning is complete.

Billing starts only after the email is sent.


# Server maintenance (/docs/ebm/server-maintenance)



Server maintenance covers the essential operations for managing the lifecycle and availability of your dedicated server. This section walks you through how to reboot or shut down a server, use rescue mode to recover from critical failures, and cancel a service when it's no longer needed.

## Power management via Customer Portal

In the [Customer Portal](https://portal.servers.com/), you can initiate a reboot or shutdown of the server. Special commands are sent to the PDU (Power Distribution Unit) automation, which triggers the power to the outlet connected to the server to be turned off or restored. Both the PDU and the server have built-in protection, significantly reducing the risk of software malfunctions, file system issues, or hardware failures during power outages.

When the protection is triggered, the PDU will prevent the server from rebooting or shutting down, and the notification will appear on the Customer Portal page:

```
"Power management is currently unavailable because of a running operation on the server. Please try again later."
```

This occurs when there is an ongoing automation task on the server or the server is in maintenance mode. This could be due to operations performed by the Servers.com team or tasks initiated by the server users, such as firmware updates or failure diagnostics.

## How to reboot a dedicated server

Rebooting a server may be required to resolve accumulated system errors, apply software updates or other purposes.

The server can be rebooted in two ways: via the Customer Portal and via the VNC console.

### Customer Portal

To reboot the server via the [Customer Portal](https://portal.servers.com/), complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. Scroll to the Power section and select **Reboot**
4. To confirm this action, enter your account password in the pop-up window and click **Continue**

The server will be rebooted. You can check the server status in the **Status** field in this section. If the status does not change, try using the **Refresh** button.

If the server does not reboot, refer to the **Power management via Customer Portal** section above for detailed information.

### VNC console

To reboot the server via the VNC console, complete the following steps:

1. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. In the Details section, click **VNC console** and confirm your action by entering your account password in the opened window
4. In the opened console, click ▹ to open the control bar → Show Extra keys → Send Ctrl+Alt+Delete

The server will be rebooted.

## How to switch off the dedicated server

Temporarily shutting the server down allows for scheduled maintenance, equipment replacement, or upgrades without risking data corruption.

The server can be switched off in two ways: via the Customer Portal and via the VNC console.

### Customer Portal

To switch off the server via the Customer Portal, complete the following steps:

1. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. Scroll to the Power section and select **Off**
4. To confirm this action, enter your account password in the pop-up window and click **Continue**

The server will be switched off. You can check the server status in the **Status** field in this section. If the status does not change, try using the **Refresh** button.

If the server does not switch off, refer to the **Power management via Customer Portal** section above for detailed information.

### VNC console

To switch off the server via the VNC console, complete the following steps:

1. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **Details**
3. In the **Details** section, click **VNC console** and confirm your action by entering your account password in the opened window
4. In the opened console:
   * For Linux-based systems, execute the following command:
     ```
     shutdown -h
     ```
   * For Windows systems, click ▹ to open the control bar → show extra keys → click the Windows icon → shutdown

The server will be switched off.

> As long as the dedicated server is not cancelled, the billing for bare-metal and all its additional services is charged at the standard rate, even if the server is switched off.

## What is rescue mode?

Rescue mode is a useful feature for dedicated and cloud servers, allowing you to diagnose, fix problems and restore server functionality in case of failures. This feature is accessible to users via the [Customer Portal](https://portal.servers.com/) control panel.

In cases where the OS is affected by critical system errors or the server is unable to boot properly, rescue mode may come in handy.

## How to restore a dedicated server using rescue mode

In rescue mode, the server connection occurs via a public IP address, so it's essential that the server has a configured public network to utilize this function.

Please note that when using rescue mode, server power outlets are rebooted, and the server shuts down immediately. This can potentially cause database failures and damage to the OS filesystem. Therefore, when enabling rescue mode, it's crucial to perform a graceful shutdown to allow the operating system to properly terminate all services.

To enter rescue mode, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**

2. In the **My servers** section, choose the server and click **Details**

3. Click the **Reboot to rescue** button and wait for an email with temporary login credentials (this usually takes up to 10 minutes)

   The email will be sent to Contacts with primary and technical roles.

4. Use credentials to access the server via SSH:

```
ssh 123.45.67.89 -l root
Warning: Permanently added '123.45.67.89' (RSA) to the list of known hosts.
root@123.45.67.89's password:
* Welcome to DMGMTSrvInit 1.0 x86_64 [based on CentOS 6 x86_64]

Dell OpenManage Deployment Toolkit:
- RAID:    raidcfg
- DRAC:    racadm4, racadm5, idracadm7
- BIOS:    syscfg
- SYSTEM:  omconfig, omreport, dsu

Additional utils:
- RAID:    mdadm
- FS:      lvm, xfs, jfs, e2fs, nfs, ntfs, dosfs, parted, fdisk, cfdisk, sfdisk, grub
- EDITORS: vi, nano, joe
- SYSTEM:  dmidecode, smartmontools, testdisk, hddtemp, lshw, memtester, ipmitool
- NETWORK: ethtool, tcpdump, mtr, traceroute, tcptraceroute, nmap, dstat
- TOOLS:   rsync, lftp, curl, wget, nc, screen, mc, chkrootkit

You can check speedtest files in your browser, url: http://<server ip>/
```

A list of useful commands is displayed upon login.

To recover the GRUB configuration file, complete the following steps:

1. Get the list of available disks and partitions using the `lsblk` command:

```
[root@dmgmtsrvinit.pxe ~]# lsblk
NAME                              MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sdb                                 8:16   0  1.8T  0 disk
├─sdb1                              8:17   0    1M  0 part
├─sdb2                              8:18   0  500M  0 part
│ └─md127                           9:127  0  500M  0 raid1
└─sdb3                              8:19   0  1.8T  0 part
  └─md126                           9:126  0  1.8T  0 raid1
    ├─C1500302784I0-home (dm-0)   253:0    0  1.8T  0 lvm
    ├─C1500302784I0-rootfs (dm-1) 253:1    0   10G  0 lvm
    └─C1500302784I0-swap (dm-2)   253:2    0    2G  0 lvm
sda                                 8:0    0  1.8T  0 disk
├─sda1                              8:1    0    1M  0 part
├─sda2                              8:2    0  500M  0 part
│ └─md127                           9:127  0  500M  0 raid1
└─sda3                              8:3    0  1.8T  0 part
  └─md126                           9:126  0  1.8T  0 raid1
    ├─C1500302784I0-home (dm-0)   253:0    0  1.8T  0 lvm
    ├─C1500302784I0-rootfs (dm-1) 253:1    0   10G  0 lvm
    └─C1500302784I0-swap (dm-2)   253:2    0    2G  0 lvm
```

Disk `/dev/mapper/C1500302784I0-rootfs` contains the root partition and disk `/dev/md127` contains `/boot`.

2. Mount these partitions:

```
mkdir /mnt/root
mount /dev/mapper/C1500302784I0-rootfs /mnt/root
mount /dev/md127 /mnt/root/boot
```

You'll also need to mount several other partitions in order to make the `grub2-mkconfig` command work properly:

```
mount -o bind /dev /mnt/root/dev
mount -o bind /sys /mnt/root/sys
mount -t proc none /mnt/root/proc
```

3. Change the root directory using the `chroot` command:

```
chroot /mnt/root
```

4. Execute the `grub2-mkconfig` command, which will generate a new GRUB configuration file:

```
[root@dmgmtsrvinit.pxe /]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Found linux image: /boot/vmlinuz-3.10.0-514.26.2.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-514.26.2.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-514.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-514.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-7dafe89409d74ef2a70c495f0148d7e3
Found initrd image: /boot/initramfs-0-rescue-7dafe89409d74ef2a70c495f0148d7e3.img
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
  WARNING: Failed to connect to lvmetad. Falling back to device scanning.
done
```

5. Exit the `chroot` and shut down the server properly:

```
[root@dmgmtsrvinit.pxe /]# exit
[root@dmgmtsrvinit.pxe ~]# shutdown -h now

Broadcast message from root@dmgmtsrvinit.pxe
    (/dev/pts/0) at 18:29 ...

The system is going down for halt NOW!
[root@dmgmtsrvinit.pxe ~]# Connection to 123.45.67.89 closed by remote host.
Connection to 123.45.67.89 closed.
```

## How to exit rescue mode

As soon as recovery work is finished, click the **Exit rescue mode** button in the [Customer Portal](https://portal.servers.com/). The server will exit rescue mode and boot normally from the OS installed on its disks.

## How to cancel the dedicated server service

If you decide to cancel one of your dedicated servers as a service, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**

2. In the **My servers** section, choose the server you wish to cancel and click **Details**

3. Scroll to the **Services** section

4. Click **Cancel Service**

5. Choose the date and time for the server to be unlinked from your account

   Keep in mind that the service cancellation will take effect 30 days from the cancellation date. Since service termination is irreversible, it will be impossible to recover data after the expiration. Therefore, make sure to back up your data stored on the server. You will be billed up until the service termination date. To immediately remove the server, send an email to [sales@servers.com](mailto:sales@servers.com).

6. To confirm this action, click **Cancel service** and enter your account password in the pop-up window and click **Continue**


# Service management (/docs/ebm/service-management)



This section covers service management operations for dedicated servers, including grouping servers for invoicing, upgrading hardware components, and cancelling a server service.

## How to set a group of dedicated servers

In the Customer Portal, users have the option to consolidate selected dedicated servers into groups and request a pending invoice for each group. This is very convenient for tracking and planning expenses. The pending invoice will include only a specific group of dedicated servers and directly associated services (additional IPs, OS, etc.).

Before setting up a group for dedicated servers, you need to create the group if it doesn't already exist.

To create the group, complete the following steps:

1. In the left-hand menu, navigate to **Billing** → **Group invoices**
2. Click **Create group**
3. Fill the form with information about the created group and click **Create**

To add a dedicated server to the group, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Choose the server and click **Details**
3. Click **Set group**
4. Select a group from the list and click **Save**

## How to upgrade RAM

You can upgrade RAM to an already ordered dedicated server. To do this, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Choose the server and click **Details**
3. Next to the **Upgrade RAM** item, click **Upgrade**
4. Select the available RAM configuration
5. Since the RAM upgrade requires shutting down the server, choose a preferred date and time slot for the upgrade
6. Click **Save**
7. To confirm this action, enter your account password in the pop-up window and click **Continue**

## How to upgrade storage drives

You can upgrade storage drives to an already ordered dedicated server. To do this, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Choose the server and click **Details**
3. Next to the **Disk upgrade** item, click **Upgrade**
4. In the opened window, choose an empty storage drive slot and click **Assign drive** to select available HDD/SDD drives or select the default option, which in this example is the **1TB SATA**
5. Choose a preferred date and time slot for the upgrade
6. Click **Order upgrade**
7. To confirm this action, enter your account password in the pop-up window and click **Continue**

## How to cancel the dedicated server service

If you decide to cancel one of your dedicated servers as a service, complete the following steps:

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. In the **My servers** section, choose the server you wish to cancel and click **Details**
3. Scroll to the **Services** section
4. Click **Cancel Service**
5. Choose the date and time for the server to be unlinked from your account

   Keep in mind that the service cancellation will take effect 30 days from the cancellation date. Since service termination is irreversible, it will be impossible to recover data after the expiration. Therefore, make sure to back up your data stored on the server. You will be billed up until the service termination date. To immediately remove the server, send an email to [sales@servers.com](mailto:sales@servers.com).


# User data (/docs/ebm/user-data)



User data refers to the user-specific configuration parameters of the server's operating system. The primary use of User data is to automate server settings. These parameters are defined during the operating system installation phase and are specified as cloud-config scripts in a text file with YAML syntax or as bash scripts. While cloud-config scripts are primarily used for Linux-based systems, Windows-based systems can achieve similar automation using PowerShell scripts. More detailed information can be found in the [cloud-init](https://cloudinit.readthedocs.io/en/latest/index.html) documentation and [Microsoft PowerShell](https://learn.microsoft.com/en-us/powershell/) documentation.

The scripts are automatically encoded in Base64 and sent to the server, where they are executed by the cloud-init agent upon the first boot of the operating system. They are not re-applied on subsequent reboots of the same server.

In the scripts, you can specify both individual configuration parameters of the operating system and entire sequences of parameters. For example:

## Scripts reference

The following scripts illustrate common automation scenarios. Examples are provided in both cloud-config and bash formats where applicable.

### Script 1: Sets the timezone and locale

* Cloud-config

```yaml
#cloud-config
# Sets the timezone to UTC
timezone: "Etc/UTC"
 
# Verifies the change
runcmd:
  - timedatectl set-timezone UTC
 
# Sets the system locale to en-US
locale: "en_US.UTF-8"
```

* Bash script

```bash
#!/bin/bash
 
# Sets the timezone to UTC
timedatectl set-timezone UTC
 
# Verifies the change
timedatectl
 
# Sets the system locale to en-US
localectl set-locale LANG=en_US.UTF-8
localectl set-keymap us
```

### Script 2: Installs a set of packages

* Cloud-config

```yaml
#cloud-config
 
#Updates the package list
package_update: true
 
#Upgrades all installed packages
package_upgrade: true
 
#Installs specified packages, in this case,
#nginx, mysql-server, and apache2
packages:
- nginx
- mysql
- apache2

 
#Sets up a basic page for an Apache web server
write_files:
  - path: /var/www/html/index.html
    content: |
      <html>
      <head><title>Welcome</title></head>
      <body><h1>Welcome to your dedicated server!</h1>.</body>
      </html>
 
 
#Executes commands after package installation to start
#and enable services at system boot.
runcmd:
  - systemctl start nginx
  - systemctl enable nginx
  - systemctl start mysql
  - systemctl enable mysql
  - systemctl enable apache2
  - systemctl start apache2
```

* Bash script

```bash
#!/bin/bash
 
# Updates the package list
apt-get update
 
# Upgrades all installed packages
apt-get -y upgrade
 
# Installs specified packages
apt-get install -y nginx mysql-server apache2
 
# Sets up a basic page for an Apache web server
cat <<EOF > /var/www/html/index.html
<html>
<head><title>Welcome</title></head>
<body><h1>Welcome to your dedicated server!</h1>.</body>
</html>
EOF
 
#Executes commands after package installation to start
#and enable services at system boot
systemctl start nginx
systemctl enable nginx
systemctl start mysql
systemctl enable mysql
systemctl start apache2
systemctl enable apache2
```

### Script 3: Configures the system

* Cloud-config

```yaml
#cloud-config
 
# Sets the hostname
hostname: my-dedicated-server
 
# Creates users and adds SSH keys
users:
# User 1
  - name: username
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    home: /home/username
    shell: /bin/bash
    lock_passwd: false
    passwd: $6$rounds=4096$abcdefghijklmnopqrstuv...
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7...
 
# User 2
  - name: new_username
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    groups: sudo
    home: /home/new_username
    shell: /bin/bash
    lock_passwd: false
    passwd: $6$rounds=4096$abcdefghijklmnopqrstuv...
    ssh-authorized-keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7...
```

* Bash script

```bash
#!/bin/bash
 
# Sets the hostname
hostnamectl set-hostname my-dedicated-server
 
# Creates users and sets up SSH keys
# User 1
username1="username"
password1="your_hashed_password1"
ssh_key1="ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7..."
 
#-m: Creates a home directory for the user. 
#-s /bin/bash: Sets the shell for the user.
useradd -m -s /bin/bash $username1
echo "$username1:$password1" | chpasswd -e
usermod -aG sudo $username1
 
mkdir -p /home/$username1/.ssh
echo $ssh_key1 > /home/$username1/.ssh/authorized_keys
chown -R $username1:$username1 /home/$username1/.ssh
chmod 700 /home/$username1/.ssh
chmod 600 /home/$username1/.ssh/authorized_keys
 
# User 2
username2="new_username"
password2="your_hashed_password2"
ssh_key2="ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA7..."
 
useradd -m -s /bin/bash $username2
echo "$username2:$password2" | chpasswd -e
usermod -aG sudo $username2
 
mkdir -p /home/$username2/.ssh
echo $ssh_key2 > /home/$username2/.ssh/authorized_keys
chown -R $username2:$username2 /home/$username2/.ssh
chmod 700 /home/$username2/.ssh
chmod 600 /home/$username2/.ssh/authorized_keys
```

### Script 4: Enables/installs SSH on Windows

* PowerShell

```powershell
Start-Transcript -path C:\postinstall.log -append
  
#Activates the administrator account:
net user Administrator /active:yes
 
#Disables administrator password expiration:
wmic UserAccount where Name='Administrator' set PasswordExpires=False
  
Disable-NetAdapterBinding -Name "*" -ComponentID ms_tcpip6
  
# RDP switch port
# https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/change-listening-port
$portvalue = 21337
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -name "PortNumber" -Value $portvalue
New-NetFirewallRule -DisplayName 'RDPPORTLatest-TCP-In' -Profile 'Public' -Direction Inbound -Action Allow -Protocol TCP -LocalPort $portvalue
New-NetFirewallRule -DisplayName 'RDPPORTLatest-UDP-In' -Profile 'Public' -Direction Inbound -Action Allow -Protocol UDP -LocalPort $portvalue
  
# RDP AccountLockout
# https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-remote-access-client-account-lockout
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout" -Name "ResetTime (mins)" -Value "0x05"
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout" -Name "MaxDenials" -Value "10"
  
# wait for internet availability
while (!(test-connection chocolatey.org -Quiet -Count 5)) {
    sleep 5
}
  
# choco install/configuration
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
choco feature enable -n allowGlobalConfirmation
choco allow-empty-checksums
  
# sshd install/configuration
net stop sshd
taskkill /F /IM sshd.exe
choco install openssh -params "/SSHServerFeature" --force
  
wget "url_to_pub_key" -outfile $HOME\.ssh\authorized_keys
wget "url_to_sshd_config_file" -outfile "%PROGRAMDATA%\ssh\sshd_config"
  
Set-Service sshd -StartupType Automatic
Restart-Service -name sshd
  
Stop-Transcript
```

### Script 5: Replaces mirrors

* Cloud-config

```yaml
#cloud-config
#This script replaces mirrors with mirrors.servers.com
#for VMs operating in gp-only mode
apt:
  preserve_sources_list: false
  primary:
    - arches: [default]
      uri: http://mirror.servers.com/debian
  security:
    - arches: [default]
      uri: http://mirror.servers.com/debian-security
```

* Bash script

```bash
#!/bin/bash
 
#This script replaces mirrors with mirrors.servers.com
#for VMs operating in gp-only mode
# Backup the current sources list
cp /etc/apt/sources.list /etc/apt/sources.list.bak
 
# Replace the sources list with the new mirrors
cat < /etc/apt/sources.list
deb http://mirror.servers.com/debian $(lsb_release -cs) main
deb http://mirror.servers.com/debian-security $(lsb_release -cs)/updates main
EOF
 
# Update the package list
apt-get update
```

### Script 6: Creates a directory and downloads files into it over the network

* Cloud-config

```yaml
#cloud-config
 
#Creates a directory
runcmd:
- mkdir -p /run/newdir
 
#Downloads files into it over the network
- [
    wget,
    "http://example.com",
    -O,
    /run/newdir/index.html
  ]
 
#Where
#http://example.com: The URL address of the file to be downloaded. 
#-O /run/newdir/index.html: Specifies the path
#and filename where the content will be saved.
```

* Bash script

```bash
#!/bin/bash
 
# Creates a directory
mkdir -p /run/newdir
 
# Downloads a file into the created directory over the network
wget "http://example.com" -O /run/newdir/index.html
```

### Script 7: Configures a new user with admin rights and sets up WinRM

* Windows (Batch)

```batch
#Activates the administrator account
echo 'Enable Administrator user'
net user Administrator /active:yes
echo 'Creating %Usertname% user'
 
#Creates a new user and adds them to the administrators group:
net user %Usertname% %Password% /add
net localgroup Administrators %Usertname% /add
 
#Configures WinRM
echo 'Starting to configure winrm'
winrm quickconfig -q
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
winrm set winrm/config '@{MaxTimeoutms="1800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
echo 'Starting to configure firewall rules'
netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow
netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow
net stop winrm
cmd /c sc config winrm start=auto
net start winrm
echo "setting ExecutionPolicy"
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine -Force
```

### Script 8: Changes the boot order

* Cloud-config

```yaml
#cloud-config
runcmd:
- efibootmgr -o $(efibootmgr | grep BootCurrent | cut -d' ' -f2),$(efibootmgr | grep BootOrder | cut -d' ' -f2 | cut -d',' -f1)
```

* Bash script

```bash
#!/bin/sh
efibootmgr -o $(efibootmgr | grep BootCurrent | cut -d' ' -f2),$(efibootmgr | grep BootOrder | cut -d' ' -f2 | cut -d',' -f1)
```

## Setting user data

In the Customer Portal, there is a **User data** field where you can enter the script.

<Callout>
  After the automatic installation is complete, it will no longer be possible to change the text in this field. The maximum script size without Base64 encoding is 16 KB.
</Callout>


# How often do you back up Forex VPS (/docs/forex-vps/back-up-forex-vps)



We back up Forex VPS services daily and keep these copies for 15 days. When you terminate a Forex VPS instance, we keep its latest backup copy for 30 days.

### Recovering from a backup

To recover a VPS from a backup, send us a [support ticket](https://portal.servers.com/requests). We can:

* Provide a list of existing backup copies for your VPS
* Restore an existing VPS to an earlier point in time
* Recover specific files or folders, as specified by you
* Mount a backup copy to a working VPS so you can select any files you need from it
* Restore a terminated VPS instance (note that in this case the IP address will likely differ from the original)

Any operations involving backups are performed during European working hours only.


# How to copy Expert Advisors from your home PC to a VPS (/docs/forex-vps/copy-expert-advisors-from-home-pc-to-vps)













When you order a Forex VPS, copying your Expert Advisors (EAs) and their settings to the new server saves you from having to configure everything manually. This guide outlines the steps to transfer your EAs.

### Connect your home PC's disk to the VPS

First, create a connection between your home PC and the VPS to enable file transfer. Follow the steps in our dedicated article: [How to connect to a Windows server](/tutorials/windows-administration/connect-to-windows-server/).

### Allow experts to run on the VPS

Once you've set up the connection, allow EAs to run on the VPS:

1. Open MetaTrader on the VPS.
2. In the main menu, select **Tools** → **Options**.
3. Switch to the **Expert Advisors** tab.
4. Make sure the following options are checked:
   * **Allow algorithmic trading**
   * **Allow DLL imports**

<img alt="Expert Advisors options in MetaTrader" src={__img0} />

### Export EA files from your home PC

EAs consist of several files located in the `Experts`, `Libraries`, and `Presets` folders inside the MetaTrader data folder.

1. Open MetaTrader on your PC.
2. In the main menu, go to **File** → **Open Data Folder**.

<img alt="Open Data Folder option in MetaTrader File menu" src={__img1} />

3. A new Explorer window will open. Find the `MQL5` or `MQL4` folder and open it.

<img alt="MQL5 folder in MetaTrader data directory" src={__img2} />

4. Copy the `Experts`, `Libraries`, and `Presets` folders from that location to your desktop or another easily accessible location.

<img alt="Copying Experts, Libraries and Presets folders" src={__img3} />

5. On the VPS, navigate to your home PC's connected drive and find the exported folders there. Copy them to the VPS desktop.

### Import EA into MetaTrader on the VPS

1. On the VPS, open MetaTrader.
2. In the main menu, go to **File** → **Open Data Folder**.
3. In the Explorer window that opens, navigate to the `MQL5` or `MQL4` folder.
4. Copy the `Experts`, `Libraries`, and `Presets` folders from the VPS desktop into this folder. Confirm overwriting if prompted.
5. In MetaTrader, in the **Navigator** panel, expand **Expert Advisors**, then expand **Advisors**. Right-click the **Advisors** folder and select **Refresh**. The newly copied EA should appear.

<img alt="Refreshing the Advisors folder in MetaTrader Navigator" src={__img4} />


# Forex VPS (/docs/forex-vps)



**Forex VPS** is a service built specifically for retail brokers: each instance runs 24/7 in our data centers with Windows and MetaTrader/cTrader pre-installed, dedicated resources per trader, automated daily backups, and direct API integration with your Trader's Room and CRM.

<DocCards>
  <DocCard title="Overview" description="Learn about Forex VPS concepts, limitations, billing, and cancellation." href="/forex-vps/overview/" />
</DocCards>

<DocCards>
  <DocCard title="Copy Expert Advisors to VPS" description="Transfer MetaTrader EAs and settings from your PC to a VPS." href="/forex-vps/copy-expert-advisors-from-home-pc-to-vps/" />

  <DocCard title="Match Statement with Invoice" description="Reconcile your Forex VPS monthly statement against an invoice." href="/forex-vps/match-a-forex-monthly-statement-with-an-invoice/" />
</DocCards>


# How to match a Forex monthly statement with an invoice (/docs/forex-vps/match-a-forex-monthly-statement-with-an-invoice)



This guide explains how to reconcile a monthly Forex VPS statement with an invoice by cross-referencing two CSV files — one downloaded from the Customer Portal or API, and one received by email. Follow the steps below to match each VPS entry in your statement to its corresponding cost on the invoice.

1. Download the invoice in CSV format through the [Customer Portal](https://portal.servers.com/billing/invoices) or the [API](https://developers.servers.com/api-documentation/v1/#tag/Invoice).
2. Find the email with the subject starting "Forex VPS Statement for period" and open the attached monthly statement CSV file.
3. Take a VPS name from the `VPS` column in the monthly statement CSV file.
4. Search for this VPS name in the `title` column of the invoice CSV file.
5. Check the `subtotal` column of the matching invoice row — this is the cost of the VPS.


# Overview (/docs/forex-vps/overview)



This article describes the key concepts, limitations, and billing terms for the Forex VPS service.

### Concepts

Forex VPS (Virtual Private Server) is a service that enables retail brokers to grow revenue and enhance trader activity. The platform operates on virtual machines (cloud servers) running 24/7 in our secure data centers.

Each VPS comes with a licensed Windows operating system and is pre-installed with all necessary tools and trading terminals, customized to the broker's preferences. Traders use [Forex VPS](https://www.servers.com/products/forex-vps) to run MetaTrader Expert Advisors and cTrader cBots, enabling fully automated and uninterrupted order execution on broker servers, generating commission fees with every trade.

#### Key features

* Each Forex VPS is assigned a dedicated set of resources and a unique public IPv4 address, ensuring full isolation and protecting traders from impacting each other
* Direct integration with your Trader's Room and CRM via an API
* Pre-installed Windows operating system, configured per your specifications
* Uninterrupted, fast access to your trading servers, allowing your customers to run Expert Advisors and cBots 24/7
* Automatic daily backups, retaining the last 15 copies
* 24/7 support

### Getting started

The setup process is fully handled by your account manager. They will grant platform access, provide a demo, and configure your VPS fleet according to your requirements, including MetaTrader terminal installation and any necessary software configurations.

### Limitations

To optimize VPS costs and minimize management efforts, we automate and streamline a lot of things in our Forex VPS service. This includes certain limitations that should not significantly affect you.

* **Windows-only service.** MetaTrader terminal is a Windows application. We automatically deploy your preferred Windows Server version from regularly updated and tested images.
* **Self-service tool instead of VNC console.** When a VPS or cloud server loses network connection, users typically use VNC console for recovery. To relieve you of manual work, we provide a self-service tool that automatically resets and corrects the VPS configuration, restoring the network connection in 99% of cases. The tool can be called via our API and can be easily integrated into Trader's Room — just add a button for your customers and reduce the workload on your support team.
* **Single network adapter & IP address.** Since the VPS acts solely as a client and is used by a single trader, multiple IP addresses are unnecessary. This simplifies management and reduces additional IPv4 costs. If you need your VPS to connect to trading servers through our Global Private Network (GPN) for faster access, contact your account manager.
* **One storage volume per VPS.** MetaTrader terminal is a lightweight application that does not store a lot of data locally nor write extensively to disk. This is why we support only one storage volume per VPS, used for both the operating system and MetaTrader terminals. If you are on the "1 Terminal" plan and need more storage space, you can upgrade your instances through our [Customer Portal](https://portal.servers.com/) or the API. If you need a custom VPS configuration, your account manager can assist you.
* **Automated backups only.** To protect customer data, we take daily backups of each VPS and store them for 15 days, without requiring manual snapshots. This process is fully automated and does not impact trading. Backups are included in the service at no extra charge.
* **Auto-generated VPS names.** To simplify service integration with your CRM, VPS names are generated automatically. Each new instance's name is provided in API responses and VPS readiness emails. There is no need to develop a name generation code in your CRM.

### Billing

The service is provided on a postpaid basis. Your account will be charged at the end of the month according to actual usage. Billing is calculated proportionally, based on the number of days the service was active.

#### Cancellation terms

The service can be cancelled at any time by contacting your account manager. Please note that any outstanding payments up to the deletion date must still be paid.


# Data centers (/docs/infrastructure/data-centers)



A data center is a secure facility with infrastructure that hosts servers and network equipment to provide uninterrupted hosting service operation.

This article outlines the key principles we follow when designing infrastructure, ensuring availability, and security.

## Locations

Our data centers are distributed globally to minimize network latency and support geographic redundancy when required. Within each facility, we use the concept of locations – these can represent an entire data center or a technically isolated independent segment. This approach provides architectural flexibility and enhances isolation when hosting customer infrastructure and delivering services.

A full list of locations and provided services is available under Data Center Locations.

## Security

Each facility is secured following modern best practices in physical and network levels. They are protected against physical intrusion, unauthorized access with a multi-level security system that includes CCTV cameras, biometric access, and ID check systems.

## Compliance and certifications

All our data centers are certified and meet various industry standards. Most facilities are rated Tier III or Tier IV by Uptime Institute – an internationally recognized system for evaluating data center reliability and availability.

Key certifications:

* Tier III (availability of 99.982%) and Tier IV (availability of 99.995%)
* ISO 27001:2013 and PCI DSS (at most locations) — required for processing payment card data in compliance with Visa and MasterCard standards
* ISO 9001:2008 – quality management system used in all our data centers
  A full list of locations and certifications is available under Data Center Locations.

## Redundancy

Redundancy ensures continuous infrastructure and service operation in case of hardware failure by duplicating critical systems and components.

By default, our locations feature redundant power and network infrastructure. For use cases where fault tolerance is not a priority, we offer data center locations with reduced redundancy. Learn more here.

### Network redundancy

Our network uses a Leaf-Spine architecture with redundant switches and routers, allowing traffic to reroute automatically in case of a failure.
Each server is equipped with two dual-port network interface controllers (NICs), and a separate NIC is used for out-of-band (OOB) management (not visible in the OS).

Network ports:

* Two connected to private network switches
* Two connected to public network switches
* One connected to the OOB management network
  Link aggregation (bonding) is configured for both public and private pairs.

### Power redundancy

Each rack is powered by two independent power sources:

* Single PSU servers: an automatic transfer switch (ATS) switches power to the backup source.
* Dual PSU servers: each PSU is connected to a separate power distribution unit (PDU) in the server rack, one for each power line.

### Reduced redundancy locations

In some locations, we offer infrastructure with reduced redundancy for cost-sensitive use cases like distributed computing, testing, or temporary projects. In the Customer Portal, these are marked with a special icon Servers.com Locations.
In these locations:

* Power and network redundancy is not provided
* Some features or services (such as L2 segments) may be unavailable

## Top carriers

To ensure fast network performance and high availability, we provide access to major Tier 1 carriers, including: Level 3, Telia, NTT, and several regional carriers. You can view available carriers for each location on the [list of our providers](https://www.servers.com/about/network/available-ip-carriers).

## Cooling systems

Thermal management is handled using redundant, energy-efficient cooling systems designed to support continuous operation and maximize equipment lifespan.

* Redundant 2N cooling configuration
* Hot and cold aisle containment cooling scheme

## Energy efficiency

Energy usage is optimized through a combination of modern technologies and monitoring systems.

* Use of green energy and energy-efficient technologies
* Low PUE (Power Usage Effectiveness) ratings


# Infrastructure (/docs/infrastructure)



The Servers.com **Infrastructure** section covers the physical foundation - globally distributed, carrier-grade data centers built to strict security standards, connected by a redundant leaf-spine L3 fabric that delivers low latency and fault tolerance across all locations.

<DocCards>
  <DocCard title="Data Centers" description="Learn about our facility design, physical security, and redundancy standards." href="/infrastructure/data-centers/" />

  <DocCard title="Network" description="Understand the leaf-spine topology and L3 fabric powering our infrastructure." href="/infrastructure/network/" />
</DocCards>


# Network (/docs/infrastructure/network)







The Servers.com data center network is built for resilience and performance. This page explains the underlying infrastructure — from the leaf-spine topology and L3 fabric architecture to link aggregation and private networking.

## Network infrastructure

The Servers.com data center network infrastructure is based on three physically isolated networks:

* Public network (Internet) – for external traffic
* Private network (Global Private Network, GPN) – for secure, isolated communication between servers
* Out-of-band (OOB) management network – for access and remote server management (e.g. iDRAC)

The public and private networks are based on a resilient Layer 3 fabric using a two-tier leaf-spine topology.

## Leaf-spine topology

The leaf-spine is a modern network architecture that includes two layers of switches:

* Leaf switches (also known as Top-of-Rack, or ToR switches)
* Spine switches (aggregation/core layer)

Each leaf switch connects to at least two spine switches, creating a highly resilient full-mesh architecture. This architecture minimizes latency and guarantees that traffic between any two servers can traverse the network in no more than three hops.
Leaf-spine topology scheme:

<img alt="Network scheme" src={__img0} />

### Leaf switches

Leaf switches are installed in server racks and provide direct connections to the servers. Each server is connected to two independent leaf switches - one link per switch. The leaf switches aggregate traffic from servers and forward it to the spine layer.

### Spine switches

Spine switches form the network backbone, interconnecting all leaf switches. These switches do not connect directly to servers. Instead, they forward traffic between leaf switches and up to the core routing layer, maintaining balanced traffic distribution and low latency.

### Redundancy

At Servers.com, every network layer - leaf, spine, and core – is fully redundant in both the private and public networks.
The core layer is composed of routers that connect the infrastructure to external carriers and other Servers.com data center locations. Each public network core router connects to multiple Tier 1 providers. Private network routers maintain at least two independent connections to the rest of the infrastructure.

This hardware-level redundancy protects against component failures, including:

* Carrier outages
* Hardware failures at any network layer
* Network interface failure on a server

## L3 fabric

In addition to physical redundancy built into the hardware layer, the L3 fabric architecture provides protocol-level protection and efficient routing behavior to ensure network resilience under load or attack.
L3 fabric (also known as IP fabric) is a network architecture built on Layer 3 of the OSI model (the IP layer). Unlike traditional Layer 2 networks with VLAN domains, L3 fabric enables scalable and reliable network designs without losing performance. It also allows seamless integration of networking hardware from different vendors.

**Features:**

* Active/active routing: unlike Layer 2 networks, which select only a single "best path", L3 fabric uses all available paths simultaneously. This approach improves both fault tolerance and performance.
* Failure domains: L3 fabric eliminates switching loops and is resilient to unknown unicast flooding. Even in the case of a DoS attack targeting a single client, the overall network remains stable.
* Commodity hardware: there is no need to invest in expensive, high-end switches upfront. The architecture allows gradual scaling by adding cost-effective switches as needed.
* Global Private Network (GPN): every customer is provisioned with GPN by default. It connects all their servers across different locations into a unified private network, without excessive background broadcast traffic. More details are available in this [GPN article](/gpn/).

### L2 support within an L3 environment

By default, L3 fabric does not provide native Layer 2 connectivity between servers. Here are the key considerations:

* Each server resides in its own isolated Layer 2 segment that includes only the server and its gateway
* Additional IP addresses are routed aliases and cannot be shared across multiple servers, unlike in a traditional Layer 2 setup

If full Layer 2 connectivity is required, the L2 Segments service is available. It allows you to group multiple servers into one or more shared L2 domains within a single data center. A server can belong to multiple L2 domains simultaneously, and you can add or remove servers from segments independently via the Customer Portal.

## Link aggregation

Link aggregation is a networking technology that combines multiple physical connections into a single logical link. This solution increases overall bandwidth and improves network resilience.

**Features:**

* Increased bandwidth: the aggregated physical links deliver higher bandwidth than each individual link
* High availability: if one link fails, traffic is automatically rerouted through the remaining active links, ensuring continuous connectivity
* Scalability: additional links can be added as needed without major changes to the network infrastructure

We use the LACP (Link Aggregation Control Protocol) as defined by IEEE 802.3ad standard (now known as 802.1AX). LACP automatically manages link bundling and load-balances traffic across active interfaces.

### Servers with link aggregation

These servers have two dual-port NICs and a total of five physical network ports:

* Two ports connect to two different switches in the private network
* Two ports connect to two switches in the public network
* One port connects to the out-of-band (OOB) management switch

In our infrastructure, we use the following interface naming convention:

| NIC  | Interface name | Network |
| ---- | -------------- | ------- |
| NIC1 | int1           | private |
| NIC1 | ext1           | public  |
| NIC2 | int2           | private |
| NIC2 | ext2           | public  |
| OOB  |                | OOB     |

Both LACP and redundancy are enabled by default. IP addresses are always assigned to the aggregated interfaces, regardless of whether redundancy is enabled. The logical scheme looks as follows:

<img alt="Network scheme" src={__img1} />

Link aggregation is configured for each pair of public and private ports, in line with our interface naming convention:

| Physical interfaces in the LACP link aggregation group | Link aggregation interface | Network |
| ------------------------------------------------------ | -------------------------- | ------- |
| int1, int2                                             | aggi                       | private |
| ext1, ext2                                             | agge                       | public  |

In our environment, public and private interfaces are either assigned directly to physical ports (e.g., `int1`, `ext1`) or to logical aggregation interfaces (e.g., `aggi`, `agge`) when link aggregation is in place.

### Servers without link aggregation

Servers with a single dual-port network interface controller (NIC) do not support link aggregation. Instead, public and private IPs are assigned directly to physical interfaces (`int1` and `ext1`). Network traffic flows directly through physical interfaces, without logical bundling or failover provided by LACP.

These servers are connected as following:

| NIC  | Interface name | Network |
| ---- | -------------- | ------- |
| NIC1 | int1           | private |
| NIC1 | ext1           | public  |
| OOB  |                | OOB     |


# CLI (srvctl) (/docs/interfaces/cli)



`srvctl` is the open-source command-line tool for Servers.com. It is built on the Public API and lets you create, inspect, and manage your infrastructure without leaving the terminal — including dedicated servers, cloud instances, load balancers, networking, and more.

The source code is available on [GitHub](https://github.com/serverscom/srvctl).

### Use cases

* **Automation and scripting**: integrate infrastructure management into your CI/CD pipelines, shell scripts, or custom workflows.
* **Power-user workflows**: work faster by staying in the terminal and composing commands with familiar UNIX tools.
* **Programmatic access**: combine `srvctl` output (JSON or YAML) with tools like `jq` or `yq` to build lightweight automation without a full SDK.

### Key concepts

| Term              | Description                                                                                                                        |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Resource**      | An object you manage via the CLI, such as a dedicated server or load balancer.                                                     |
| **Command**       | An operation performed on a resource, such as `add`, `get`, or `delete`.                                                           |
| **Option / flag** | Additional arguments that modify a command. A flag stands alone (e.g., `-f`); an option carries a value (e.g., `--output=json`).   |
| **Context**       | A named set of credentials and configuration for one account or API token. Multiple contexts allow you to switch between accounts. |
| **Configuration** | A YAML file that stores your contexts and global settings.                                                                         |

### Installation

#### macOS

```bash
brew tap serverscom/serverscom
brew install srvctl
```

#### Linux

1. Download the archive for your architecture from [GitHub releases](https://github.com/serverscom/srvctl/releases). For example, `srvctl_0.1.0_linux_amd64.zip` for Linux on AMD64.

2. Extract and make the binary executable:

```bash
unzip srvctl_*_linux_amd64.zip
chmod +x srvctl
```

3. Move `srvctl` to a directory on your `PATH` (e.g., `/usr/local/bin`) or add its directory to `~/.bashrc`:

```bash
export PATH=/path/to/srvctl/folder:$PATH
source ~/.bashrc
```

#### Windows

1. Download the archive for your architecture from [GitHub releases](https://github.com/serverscom/srvctl/releases).
2. Extract the archive.
3. Run the `srvctl.exe` executable.

### Getting started

1. Generate a Public API token in the [API Tokens](https://portal.servers.com/iam/api-tokens) section of the Customer Portal.

2. Log in to create your first context:

```bash
srvctl login my-account
```

You will be prompted for the API token. The new context is set as default automatically.

3. Verify the context was created:

```bash
srvctl context list
```

4. Explore available resources and commands using the built-in help:

```bash
srvctl --help
srvctl <resource> --help
srvctl <resource> <command> --help
```

### Command structure

All commands follow the same pattern:

```
srvctl <resource> <command> [<options>]
```

Standard commands available on most resources:

| Command       | Description                     | Example                                          |
| ------------- | ------------------------------- | ------------------------------------------------ |
| `list` / `ls` | List resources                  | `srvctl hosts list`                              |
| `add`         | Create a new resource           | `srvctl ssh-keys add --input ssh-key.json`       |
| `get`         | Get details of a resource by ID | `srvctl hosts ebm get <id>`                      |
| `update`      | Update a resource by ID         | `srvctl ssh-keys update <fingerprint> -n <name>` |
| `delete`      | Remove a resource by ID         | `srvctl ssh-keys delete <fingerprint>`           |

Sub-resource commands follow the pattern `list-<subresource>`, `get-<subresource>`, and so on. For example:

```bash
srvctl hosts ebm list-connections <id>
srvctl hosts ebm list-networks <id>
```

### Global flags

These flags are available on every command:

| Flag           | Alias | Description                                        |
| -------------- | ----- | -------------------------------------------------- |
| `--all`        | `-A`  | Fetch all pages of results                         |
| `--output`     | `-o`  | Output format: `text` (default), `json`, or `yaml` |
| `--no-header`  |       | Suppress column headers in text output             |
| `--field`      | `-f`  | Limit output to specific fields: `-f ID -f Status` |
| `--field-list` |       | List available fields for the current resource     |
| `--verbose`    | `-v`  | Show the full HTTP request and response            |
| `--config`     | `-c`  | Path to a custom configuration file                |

### Creating resources with JSON input

Resources such as dedicated servers, load balancers, and L2 segments are created using a JSON file that mirrors the Public API request body. The `add` command provides a template link when you run it without input.

```bash
srvctl hosts ebm add --input dedicated-server.json
```

Example `ssh-key.json`:

```json
{
  "name": "my-key",
  "public_key": "ssh-rsa AAAA..."
}
```

### Configuration file

The default configuration path is `$HOME/.config/srvctl/config.yaml`. You can override it with the `SRVCTL_CONFIG_PATH` environment variable or the `--config` flag.

Example configuration:

```yaml
globalConfig:
  http-timeout: 30
  output: text
defaultContext: default
contexts:
  - name: default
    endpoint: https://api.servers.com/v1
    token: <your-api-token>
    config:
      verbose: false
  - name: staging
    endpoint: https://api.servers.com/v1
    token: <staging-api-token>
```

Settings are resolved in order of increasing priority:

1. **Global config** — applied to all contexts unless overridden.
2. **Context config** — overrides global config for the active context.
3. **Command-line flags** — override everything for the current command.

To update configuration without editing the file:

```bash
srvctl --http-timeout 60 config global update
srvctl --output json config context update
```

### Context management

| Command                                  | Description                                           |
| ---------------------------------------- | ----------------------------------------------------- |
| `srvctl login <name>`                    | Create a new context and authenticate                 |
| `srvctl context list`                    | List all contexts                                     |
| `srvctl context update <name> --default` | Set a context as default                              |
| `srvctl context delete <name>`           | Delete a context (`--force` required for the default) |

### Available resources

| Resource             | CLI command                        | Description                                      |
| -------------------- | ---------------------------------- | ------------------------------------------------ |
| Account balance      | `srvctl account balance`           | View current account balance                     |
| Hosts (all types)    | `srvctl hosts list`                | List all servers across types                    |
| Dedicated servers    | `srvctl hosts ebm <command>`       | Manage dedicated (enterprise bare metal) servers |
| Scalable Bare Metal  | `srvctl hosts sbm <command>`       | Manage SBM servers                               |
| Invoices             | `srvctl invoices <command>`        | View and retrieve invoices                       |
| SSH keys             | `srvctl ssh-keys <command>`        | Manage SSH keys                                  |
| Locations            | `srvctl locations <command>`       | List and inspect locations                       |
| Server models        | `srvctl server-models <command>`   | Browse available server models                   |
| Racks                | `srvctl racks <command>`           | Manage private racks                             |
| SSL certificates     | `srvctl ssl <command>`             | Manage custom and Let's Encrypt certificates     |
| L2 segments          | `srvctl l2-segments <command>`     | Manage private L2 network segments               |
| Kubernetes clusters  | `srvctl k8s <command>`             | Manage Kubernetes clusters                       |
| Load balancers       | `srvctl lb <l4\|l7> <command>`     | Manage L4 and L7 load balancers                  |
| Network pools        | `srvctl network-pools <command>`   | Manage network pools and subnets                 |
| Remote Block Storage | `srvctl rbs <command>`             | Manage RBS volumes                               |
| Cloud instances      | `srvctl cloud-instances <command>` | Manage cloud computing instances                 |
| Cloud regions        | `srvctl cloud-regions <command>`   | Browse regions, images, flavors, snapshots       |
| Cloud volumes        | `srvctl cloud-volumes <command>`   | Manage cloud block storage volumes               |
| Cloud backups        | `srvctl cloud-backups <command>`   | Manage cloud volume backups                      |


# Customer Portal (/docs/interfaces/customer-portal)













The Customer Portal is a web interface to manage your Servers.com resources and services. This article guides you through the main elements that you may navigate while using the portal. We are constantly improving and updating our customer portal. Because of this, whilst screenshots provided in this article are provided to aid understanding, they may differ slightly from our current portal interface.

**The left-side menu** allows you to navigate through all services, billing and account settings.

<img alt="portal's left side menu" src={__img0} title="The left-side menu" />

**The top-right menu** lets you switch between accounts and reach your account and user settings instantly.

<img alt="portal's top right menu" src={__img1} title="The top-right menu" />

The search bar allows you to search through all your Servers.com resources and instantly get access to them.

A **color theme** is a palette of your user interface. You can choose between two color themes for your user interface:

* Light mode
* Dark mode

There is also a system mode that sets a theme in accordance with your operating system settings. The feature can be managed by clicking the **Change color theme** icon in the top-right corner.

<img alt="change color theme" src={__img2} title="Change color theme" />

When you make an order your products are sent to a cart, where they are stored before purchase. You can reach your cart by clicking the cart icon on the top-right.

<img alt="portal's cart option" src={__img3} title="Cart option" />

The dashboard is the main Customer Portal page and contains basic information about:

* Balance: current balance and estimated balance for the beginning of the next billing period
* Invoices: a list of unpaid invoices
* Latest requests: a list of requests starting with the most recent activity

<img alt="customer portal dashboard" src={__img4} title="Customer Portal dashboard" />

The **I trust this computer** flag will appear when entering your two factor authentication (2FA) token during login. If you do not want to go through 2FA every time you log in to your account, select this option. However, if a session is logged out manually, it is necessary to go through 2FA again.

A **dangerous action** is an operation that may significantly impact on a service or lead to irreversible changes.


# Interfaces (/docs/interfaces)



**Interfaces** covers every way to manage your Servers.com infrastructure - from the Customer Portal web UI and Public REST API to the Terraform provider for infrastructure-as-code and the `srvctl` CLI for terminal-based and scripted workflows.

<DocCards>
  <DocCard title="Customer Portal" description="Navigate the web UI for day-to-day infrastructure management." href="/interfaces/customer-portal/" />

  <DocCard title="Public API" description="Automate and integrate Servers.com via the RESTful API." href="/interfaces/public-api/" />

  <DocCard title="Terraform Provider" description="Manage Servers.com infrastructure as code using Terraform." href="/interfaces/terraform-provider/" />

  <DocCard title="CLI (srvctl)" description="Manage your infrastructure from the terminal with the open-source CLI." href="/interfaces/cli/" />
</DocCards>


# Labels (/docs/interfaces/labels)



A **label** is a key-value pair assigned to a resource. Resources that support labels include dedicated servers, firewalls, load balancer instances, and Kubernetes clusters. Labels allow you to group resources and retrieve them based on specific criteria, and can be managed via the public API.

### Pattern

A label consists of a key and a value:

```
"<key>": "<value>"
```

A key can be specified in two ways:

1. `"<prefix>/<name>": "<value>"` — with an optional prefix that enables a two-level hierarchy
2. `"<name>": "<value>"` — without a prefix

The `<prefix>` segment is optional and helps organize labels into logical namespaces.

### Limitations

* A resource can have several labels, but each key must be unique within that resource
* Each resource can have up to 64 labels
* The `servers.com/` prefix is reserved and not allowed to be used

### Use cases

Labels allow resources to be placed together under logical categories. The following examples show how labels can work in practice.

### Separate infrastructure between testing and production environments

To distinguish between testing and production servers in a simple infrastructure:

```
"environment": "production"
"environment": "testing"
```

### Independent applications within one Servers.com account

For two independent applications (`app1` and `app2`) with servers distributed between frontend and backend teams:

```
"app1/backend": "production"
"app1/frontend": "production"
"app1/backend": "testing"
"app1/frontend": "testing"
"app2/backend": "production"
"app2/frontend": "production"
"app2/backend": "testing"
"app2/frontend": "testing"
```

### Purpose-based differentiation

For a complex infrastructure with different groups of servers working towards a shared purpose:

```
"purpose": "billing"
"purpose": "core"
"purpose": "database"
```

### Management

Labels can be assigned to a resource during creation or at any other point in its lifecycle. The following operations are available:

* Create a new label
* Update an existing label
* Delete an existing label
* Retrieve a resource by label

To learn how to manage labels via the public API, refer to the [public API documentation](https://developers.servers.com/api-documentation/v1/#section/Labels).


# Operating systems (/docs/interfaces/operating-systems)



Servers.com allows you to select an operating system that will be automatically installed and configured on your server. You can get the most up-to-date list of available operating systems when ordering a cloud or dedicated server in the Customer Portal.

### Concepts

An **operating system** (OS) is basic software installed on a server during provisioning to manage hardware resources and allow other programs to run. When working with cloud servers, the operating system is referred to as an **image**.

An **OS family** is a group of operating systems sharing common principles and core components. There are two main OS families: Linux and Windows.

An **OS distribution** (distro) is a particular operating system within an OS family.

Operating systems can also be classified by how updates are delivered:

* **Rolling release** — updates are delivered continuously as soon as they are ready. The OS always has the latest software but may be less stable.
* **Standard release** — changes are collected into a single major update released on a schedule. This provides more stability but may delay access to the latest software.

### Use cases

### AlmaLinux

AlmaLinux is a free, community-driven operating system designed as a CentOS replacement. It provides enterprise stability and binary compatibility with Red Hat Enterprise Linux (RHEL), and offers 10 years of security support per major version.

Use cases: web servers, enterprise applications, hosting control panels, database servers.

### CentOS Stream

CentOS Stream is a rolling-release distribution positioned between Fedora and RHEL. Updates flow from Fedora to CentOS Stream and then land in RHEL, making CentOS Stream a preview of future RHEL versions.

Use cases: pre-production testing, development targeting RHEL ecosystems, continuous integration setups.

### Debian

Debian is a community-driven Linux distribution and the foundation of Ubuntu. It is known for a conservative approach to updates and is preferred in environments where stability, predictability, and uptime matter more than having the latest software versions.

Use cases: production servers, long-lived systems, research clusters, critical infrastructure.

### Rocky Linux

Rocky Linux was founded by the original creator of CentOS and shares a similar philosophy with AlmaLinux — stable, production-ready, and with long-term support. Some users prefer Rocky Linux for its CentOS heritage and community-first focus.

Use cases: enterprise servers, hosting, RHEL-compatible applications.

### Ubuntu

Ubuntu is a Debian-based operating system by Canonical that offers a more user-friendly experience and newer packages. Its large ecosystem and broad community support make it popular for cloud deployments and development environments.

Use cases: cloud servers, container hosts (Docker/Kubernetes), general-purpose Linux systems.

### Windows Server

Windows Server is Microsoft's server operating system designed to run enterprise applications, directory services, file services, and workloads built on the Microsoft ecosystem. Servers.com offers the Standard and Datacenter editions.

Use cases:

* **Microsoft stack integration** — ideal for extending infrastructure into the cloud with tight integration with Active Directory, Group Policies, Exchange Server, and .NET applications.
* **Remote desktop infrastructure** — Windows Server's graphical environment makes it straightforward to provide remote app access or full desktop sessions to employees.
* **SQL Server** — while SQL Server has supported Linux since 2017, some advanced features are only available or better supported on Windows. Many third-party management, monitoring, and compliance tools also assume a Windows Server platform.

### No operating system

Servers.com allows you to order a server without any operating system. In this case, you can reach the server via an out-of-band (OOB) connection and set it up according to your needs.

Use cases: custom projects.


# Public API (/docs/interfaces/public-api)



Public API is another way to manage Servers.com resources built upon the RESTful architecture. It gives you an opportunity to automate manual operations and programmatically integrate Servers.com into your infrastructure.

You can learn more in the Public API documentation, in the [API tokens](https://portal.servers.com/iam/api-tokens) section of the Customer Portal.

Public API terms of use are available in the [legal section](https://www.servers.com/company/legal/public-api-terms-of-use) of the Servers.com website.

### Use case

During periods of peak user activity, you may need additional capacity to process increasing workloads. You can set up monitoring on your side to detect when your existing infrastructure is approaching its resource limits. Once this happens, the monitoring will trigger an order of Servers.com Scalable Bare Metal (SBM) servers to meet hardware requirements. When peak activity has dropped, you can set up a trigger to remove the SBM servers.


# Terraform provider (/docs/interfaces/terraform-provider)



Terraform is an open-source infrastructure-as-code software built on the Servers.com Public API. This tool allows you to manage your hardware infrastructure as code and carry out practices like descriptive coding and versioning.

### Concepts

Below are some basic concepts that you will encounter when using Terraform.

1. **Terraform provider**: a module to manage the services of a certain vendor. Servers.com has its own provider as well.
2. **Resource**: an object on which an operation is performed. It can be a server, load balancer or any other standalone service.
3. **Data source**: an entity to fetch data outside of the current Terraform configuration. For example, data about network pools.

We recommend you start by getting acquainted with our [Terraform documentation](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs).

### Authentication

Servers.com Terraform providers use the Public API token as a means of authentication. You can get one in the [API Tokens page](https://portal.servers.com/iam/api-tokens) within the Customer Portal.

### Use case

You plan to roll out a new version of your application that requires another hardware setup. In this case, you can also apply versioning to your infrastructure and describe hardware configurations for both the current and new application versions.

### Getting started

To get started, follow the guides provided in [Terraform’s official documentation](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs).

The **Use Provider** button in the top-right corner explains how to use the Servers.com Terraform provider.


# Billing (/docs/l2-segments/billing)



The L2 Segment service is billed per usage for the previous month. Using the service does not impact traffic pricing — it remains individual for each server.

Payment is applied for the following services:

* Server in the segment: billing depends on the total number of servers in the segment for a specific period. If a server is connected to multiple segments in trunk mode, this will be billed for each of them.
* Additional IP: a charge applies for each additional public IP in the segment. Additional private IP is free. All additional IPs assigned to the server will be associated with the L2 Segment upon its transfer.


# Concepts (/docs/l2-segments/concepts)



L2 Segments service allows you to unite servers within a location group in a broadcast domain and enhance networks by connecting isolated groups of devices. This provides better control, customization, and optimal performance.

By choosing Servers.com as a hosting provider for your applications, you retain control over the definition of your network environment. Whether it's the usage of IP address spaces, creation of subnets, or floating IP addresses, you can have it.

Using VXLAN technology, we have built a service called L2 Segments, also known as the broadcast domain.

### Features

* Available in both public and private networks
* All additional networks associated with the dedicated server come under the management of the L2 Segment
* The Direct Connect (DC) service can be added in multiple L2 Segments.
* Allows the use of custom IP addressing
* ACL rules do not have an impact on the L2 Segment

The L2 Segment service is delivered through our L3 Fabric network which employs VXLAN technology. There's no need to relocate servers between switches, all whilst retaining the advantages of the L3 Fabric network including reliability, scalability, and increased network availability.

### Use cases

Here are some of the main use cases for L2 Segments:

#### Network segmentation

The basic use case is the network segmentation, or subnetting. A single client can allocate multiple L2 Segments and assign servers with different roles to different segments. Because of this, servers with different roles will be in different networks. For example, the servers hosting a public website can be isolated from the servers running a CRM application. This increases the security within the network.

#### Floating IP addresses

A more complex use case involves floating IP addresses. This use case is typical amongst services demanding high availability. Floating IP address can be transferred between multiple servers allowing for a failover or upgrade of production software. For a floating IP address to be transferred between physical servers, data link layer connectivity is required between those servers.

Private cloud is another instance requiring floating IP addresses. Floating IP addresses allow for the migration of a virtual server between physical servers in a virtualized environment. When a Virtual Machine (VM) is moved to a new bare metal server, the new server announces the takeover of an IP address of the moved VM, so that the VM can remain reachable by its IP address regardless of physical location.

#### Custom IP addressing

The next use case is to fulfil the specific needs of the proprietary or legacy software systems. Custom IP addressing provides the flexibility to use almost any IP address space within L2 Segments. This service allows the clients to deploy their own DHCP and PXE servers.

#### Multicast

A large amount of software relies on Ethernet multicast to reduce CPU and bandwidth consumption in one-to-many communications. Use cases include audio, video, and quote broadcasting. Multiplayer video game servers are another example; they can use L2 broadcast segments for multicast communications.


# Configuring tagged trunks (/docs/l2-segments/configuring-tagged-trunks)



The L2 Segments service on the Servers.com platform allows for the creation of virtualized Layer 2 subnets or segments over an underlying Layer 3 network. From the technical standpoint, a single L2 Segment is a set of VLANs interconnected using the VXLAN protocol. VLANs are provisioned per L2 Segment per server rack.

### Example 1: All member servers of the L2 Segment are located in the same server rack.

A single VLAN is provisioned for the L2 Segment.

### Example 2: Member servers of the L2 Segment are located in three different server racks.

A separate VLAN is provisioned for the L2 Segment in each rack, totalling three VLANs. A VXLAN is configured to interconnect all three VLANs. Different VLAN IDs are mapped to the same VXLAN VNI.

VLANs and VXLANs are provisioned automatically after adding or removing servers to or from an L2 Segment in the Customer Portal. The clients only need to configure IEEE 802.1Q tagging on their servers when using tagged trunk ('Trunk') links. Please see the sections below for details.

### Types of links used to connect a server to an L2 Segment

When you're connecting (adding) a server to the previously created L2 Segment in the Customer Portal, you have to choose if you would like to connect the server using a 'Trunk' link or a 'Native' link. A single Ethernet interface can host a single native link (Ethernet frames are untagged) and multiple trunks (Ethernet frames are tagged) simultaneously.

The differences between the link types are shown in the table below:

| **Link type** | **Description**                                                                                                                                                                                                                                                                                                                                                                   | **Requires OS configuration** | **Number of VLANs per Ethernet interface** |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ------------------------------------------ |
| Native        | 'Native' link is used to transport data for a single VLAN. It does not require additional configuration on the server. A server may have only one native link per Ethernet interface. The network switch treats all untagged traffic on a native link as being tagged with the default VLAN ID.                                                                                   | NO                            | One                                        |
| Trunk         | 'Trunk' is the type of link that may be used to transport data for multiple VLANs. Using a trunk link requires IEEE 802.1Q VLAN tagging to be configured in the server's operating system. A server may have multiple trunks per Ethernet interface. The network switch stripes the VLAN tag with the default VLAN ID from Ethernet frames before sending them via a native link. | YES                           | Multiple                                   |

### Example 1: Four servers in the L2 Segment. All with native links to the segment in the Customer Portal.

No additional configuration is needed on the servers. Servers can communicate on layer 2.

### Example 2: Four servers in the L2 Segment. First three with native links to the segment in the Customer Portal. The fourth server is connected with a trunk.

No additional configuration is needed on the first three servers. On the fourth, 802.1Q tagging has to be set up. Servers can communicate on layer 2.

### Getting VLAN ID for a server

You will need to set up IEEE 802.1Q tagging in the server's operating system if you chose 'Trunk' while adding the server to an L2 Segment in the Customer Portal. You will need the VLAN ID number to set up IEEE 802.1Q tagging. Please note that VLAN ID numbers for different servers in the same L2 Segment may differ from rack to rack. That is why you should retrieve the VLAN ID for each server individually.

You can find the VLAN ID of a server on its details page and on the L2 Segment details page.

### Configuring tagged trunks using the ip utility

The `ip` utility comes with most of the Linux distributions. To enable 802.1Q tagging on the `agge` interface with VLAN ID `2005` and static IP address, run:

```bash
ip link add link aggi name vlan2005 type vlan id 2005
ip address add 172.16.0.1/16 dev vlan2005
ip link set vlan2005 up
```

Please note that this configuration will not persist a reboot.

### Configuring tagged trunks using interface configuration files in CentOS

To create a subinterface with 802.1Q tagging enabled, VLAN ID `2005` and static IP address on the `agge` Ethernet interface:

1. Add a new configuration file. Please note that the file name should be in accordance with [Naming Scheme for VLAN Interfaces](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/networking_guide/sec-naming_scheme_for_vlan_interfaces).

```
/etc/sysconfig/network-scripts/ifcfg-agge.2005
```

2. Edit the file to add the following configuration:

```
ONBOOT=yes
TYPE=Ethernet
VLAN=yes
DEVICE=agge.2005
BOOTPROTO=static
IPADDR=172.16.0.1
NETMASK=255.240.0.0
```

3. Restart the network service:

```bash
systemctl restart network
```

### Configuring tagged trunks using interface configuration files in Ubuntu

To create a subinterface with 802.1Q tagging enabled, VLAN ID `2005` and static IP address on the `agge` Ethernet interface:

1. Install the `vlan` package:

```bash
apt update && apt install vlan
```

2. Add configuration to the `/etc/network/interfaces` file:

```
auto agge.2005
iface agge.2005 inet static
address 172.16.0.1
netmask 255.240.0.0
vlan_raw_device agge
```

### IP addressing

You can order IP aliases and additional IP networks for a server in the Customer Portal and use them within an L2 Segment of your choice. But only on the condition that IP aliases and networks are ordered for a server that is connected to the chosen L2 Segment via a 'Native' link. This is because IP aliases and additional IP networks provisioned by Servers.com are always configured for a default (ie 'Native') VLAN on the network switch port. And when a server is connected to an L2 Segment via a 'Native' link, the default VLAN ID for that server is the VLAN ID of the L2 Segment.

Additional IPs ordered for the server connected via a 'Native' link can be used by all other members of the L2 Segment relying on the ARP protocol within the L2 Segment.


# Getting started (/docs/l2-segments/getting-started)



L2 Segments by Servers.com are easily configurable. In just a few clicks you can create them in the [Customer Portal](https://portal.servers.com) and add or remove servers from a segment. No need to create support tickets. No need to wait.

Our L2 Segment service gives our clients an option to use the data link layer (OSI Layer 2) over our [Layer 3 Fabric Network](/infrastructure/network/#l3-fabric). With L2 Segments, our clients can implement many things that are otherwise only available in on-premises environments.

Our clients can combine servers into multiple L2 Segments within a data center, and one server can be a member of multiple L2 Segments at the same time. Such a member will have one native VLAN link and multiple tagged trunks.

This instruction describes how to engage the L2 Segment service between two servers. It is assumed that at least two dedicated servers have been ordered.

To order the L2 Segment service, perform the following steps:

1. Log in to the Customer Portal and navigate to **Networks** → **L2 Segments**
2. Click **Add segment**
3. In the **Type** section, select the network type **Private** or **Public**, in which the service will be deployed.
   The selected network type will determine available locations, and for Public type, there is the possibility to add Alias IP
4. Select an available location in the **Location** section
5. Select the servers to be added to the segment in the **Hosts** section
6. Assign a segment name in the **Name** section
7. (Public type only). In the **Alias IP count** section, use the **+** / **-** buttons to select the number of additional IP addresses
   The monthly price and other summary details will appear at the bottom of the window
8. Click **Save**


# L2 Segments (/docs/l2-segments)



**L2 Segments** let you group servers at a location into a single broadcast domain using VXLAN, giving you custom IP addressing, floating IPs, and network isolation - without moving physical hardware between switches or changing your L3 fabric setup.

* **VXLAN-based segmentation** - create private subnets across your servers without hardware changes
* **Floating IPs** - reassign IPs between servers instantly for failover and high availability
* **Custom addressing** - define your own subnets and IP ranges within each segment

<DocCards>
  <DocCard title="Concepts" description="Understand L2 Segments architecture, VXLAN, and key use cases." href="/l2-segments/concepts/" />

  <DocCard title="Billing" description="See how L2 Segments usage and pricing are calculated." href="/l2-segments/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Create and configure your first L2 Segment." href="/l2-segments/getting-started/" />

  <DocCard title="Configuring Tagged Trunks" description="Set up VLAN-tagged trunk ports for advanced network topologies." href="/l2-segments/configuring-tagged-trunks/" />
</DocCards>


# Limitations (/docs/l2-segments/limitations)



The following limitations apply when using this service:

* Only available within data center locations or for dedicated servers
* Each L2 Segment can have only one Direct Connect service
* One dedicated server is required to create an L2 Segment
* Allows no more than 64 additional IP per segment
* Unable to order additional IPv4 and IPv6 networks
* One dedicated server can participate in 34 segments: 1 primary public, 1 primary private, 16 public trunks, 16 private trunks


# Billing (/docs/load-balancer/billing)



The service is billed per usage. Charges are calculated based on actual usage and are included in the invoice for the upcoming billing period.

**The service cost includes**:

* A fixed fee for each load balancer instance
* The sum of fixed fees for additional options associated with each instance
* Traffic usage in GB

**Additional options**:

* SSL termination - the fixed fee is charged for this option
* GEO IP - the fixed fee is charged for this option
* Storing logs - the fixed fee is charged for this option; storing logs in the cloud storage is charged separately
* Additional IPv4 addresses
* Each HTTPS rule

**Traffic**:

* Inbound and outbound traffic is charged between the load balancer and request initiators from internet
* Traffic is not charged between the load balancer and the upstream servers through the private network
* Outbound traffic is charged in the following cases:
  * From the load balancer, if the upstream server interacts with it via a public IP
  * From the upstream server, if it sends data to the load balancer via a public IP. The invoice will include the traffic usage for this server (not for the load balancer)
* Traffic is not charged if a private IP is used for interaction between the load balancer and the upstream server
  * If the load balancer receives 1 TB of data from the internet, a charge will apply for 1 TB received by the load balancer
  * If the upstream server sends 1 TB of data to the load balancer, charges will apply for 1 TB of outbound traffic from the server and 1 TB of outbound traffic from the load balancer

### Cancellation terms

The service can be canceled at any time by removing it. Billing stops at the end of the cancellation day, with the full day being charged on the day the service is canceled.


# Concepts (/docs/load-balancer/concepts)





A load balancer is responsible for distributing the workload among upstreams for either dedicated or cloud servers.

**Key functions**:

* Distributing traffic among upstreams
* Enhancing fault tolerance and redundancy
* Ensuring scalability without system downtime

## How it works

<img alt="load balancer scheme" src={__img0} title="The Load Balancer scheme" />

| Component               | Description                                                                                                                                                                                                                                                                                                |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Load balancing cluster  | A pool of at least three load balancer nodes and switches. There are two types of cluster: **Shared cluster** – all system resources are shared among multiple accounts or clients. **Dedicated cluster** – all system resources are allocated exclusively to a single account or client                   |
| Load balancing node     | A pre-configured physical server. Each node, along with pre-configured switches, handles incoming traffic and distributes requests to upstream servers. If a node fails, it is replaced by another using clustering mechanisms.                                                                            |
| Upstream servers        | A pool of cloud or dedicated servers among which the traffic load is distributed.                                                                                                                                                                                                                          |
| Load balancing instance | A set of load balancing configurations on a node, linked to a specific pool of upstream servers. Each client is allocated an isolated load balancer instance on a node. These instances are individually configured, providing isolated and customizable load balancing within the overall infrastructure. |
| Public IP               | Is the entry point for client traffic and is used by all nodes in the cluster.                                                                                                                                                                                                                             |

The load balancer serves as the entry point for client requests, isolating the upstream server pool from direct client access. The service operates on a complex system of interconnected components. The key components are outlined below.

## Key components

The load balancer utilizes BGP (Border Gateway Protocol) and XDP (eXpress Data Path) solutions:

* BGP is a standardized protocol for exchanging routing information between systems
* XDP is a framework for fast packet processing in the Linux kernel

Depending on the cluster, XDP or ECMP (Equal-Cost Multi-Path Routing) may be utilized to optimize traffic routing and enhance performance.

Using the assigned public IP address, the load balancer instance accepts client requests and distributes them among available upstream servers. The distribution is performed based on the health and state of the servers, as well as the distribution algorithms.

## Algorithms

A load balancer uses algorithms to determine how requests are distributed among upstream servers.

Our L4 and L7 load balancers use the following algorithms:

* Random least connections. Routes the request to two servers randomly chosen from the entire pool and selects the server with the least number of active connections
* Weighted least connections. Routes requests to the server with the fewest active connections, with the ability to assign priorities to upstream servers based on weight
* Round robin. Distributes requests sequentially in a cyclic order among servers in the pool

## Types of load balancing

We offer two types of load balancing based on traffic type, aligned with the OSI model. Both types of load balancers support storing logs in cloud storage that saves information about requests processed by the load balancer into log files in the NGINX format.

### L7 load balancer (HTTP/HTTPS)

Works as a reverse proxy server, suitable for working with web applications and APIs that require content-based routing.

Key features:

* Operates at the application layer (layer 7) of the OSI model
* Supports protocols HTTP, HTTPS, and HTTP/2
* Enables uploading and managing SSL certificates for processing HTTPS requests
* Supports SSL termination, handling encryption and decryption of HTTPS traffic
* Verifies the availability of upstream servers using health checks feature with protocols such as HTTP, HTTPS, gRPC, and gRPCS
* Routes traffic based on the content of HTTP/HTTPS requests, including headers, URIs, parameters, and methods (e.g., GET, POST)
* Implements session persistence (sticky sessions) to bind client requests to a specific server for the duration of the session
* Identifies the user's geolocation based on their IP address using the Geo IP feature

The L7 load balancer has the ability to pass the client's real IP address to upstream servers using specific headers in HTTP requests. This allows upstream servers to see the original IP address of the request instead of the load balancer's IP address, which is important for analytics, logging, and access control.

The following options are available in the [Customer Portal](https://portal.Servers.com/):

| Setting         | Description                                                                                                                                                                       |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Disabled        | The load balancer does not use headers to pass the real IP address. Upstream servers will see the load balancer's IP address                                                      |
| X-Real-IP       | The load balancer extracts the real IP address from the `X-Real-IP` header                                                                                                        |
| X-Forwarded-For | The load balancer uses the `X-Forwarded-For` header, which may contain a list of IP addresses from all intermediate proxies. The real IP address is the first address in the list |

Additionally, the **Trusted networks** field is available, where you can specify trusted networks in CIDR format (e.g., `X.X.X.X/16..32`). Real IP addresses will only be accepted from these networks, enhancing security and preventing inaccurate data from unverified sources.

#### Domain names

At least one domain name must be specified when setting up an L7 load balancer instance. The load balancer only processes requests to the configured domain names. HTTP/HTTPS requests with no matching domain name are dropped and the connection is closed.

#### SSL termination and forwarding rules

SSL termination relieves application servers of the burden of encrypting and decrypting traffic, with the load balancer handling this instead. Forwarding rules define how traffic is forwarded from the load balancer to upstream servers — each rule maps a scheme, port, and request path on the load balancer side to a scheme, port, and request path on the upstream side. At least one forwarding rule is required.

* Each rule using the HTTPS scheme on the load balancer adds €5.00 per month for the SSL Termination service.
* The "Redirect HTTP to HTTPS" option is available when there is only one HTTPS (443) incoming rule.

#### Multiple domain names and SSL certificates

You can add multiple domain names to a single load balancer instance. However, only one SSL certificate can be assigned per instance, which will be used for all requests to that instance. To protect multiple domain names with a single certificate, you will need either:

* A **wildcard certificate**, if all domains are subdomains of the same second-level domain
* An **SSL certificate with SAN (Subject Alternative Name) extension**, for multiple unrelated domains

If you do not intend to use SAN or wildcard certificates, it is recommended to create separate load balancer instances on a per-domain basis.

#### Additional HTTP headers

To identify the client IP address, the original host, and the port requested by the client, the load balancer injects the following HTTP header fields into requests sent to upstream servers:

| Header                 | Description                                                      |
| ---------------------- | ---------------------------------------------------------------- |
| `X-Forwarded-For`      | The originating IP address of the client. E.g., `23.108.209.172` |
| `X-Forwarded-Host`     | The domain name of the forwarded server. E.g., `servers.com`     |
| `X-Forwarded-Port`     | The port of the forwarded server. E.g., `443`                    |
| `X-Forwarded-Protocol` | The protocol of the forwarded server. E.g., `https`              |
| `X-SCLB-NodeID`        | Load balancer node ID. E.g., `s1599`                             |
| `X-SCLB-RequestID`     | NGINX Request ID. E.g., `bd438656d26a07981169ad4cbf56c0d2`       |

Where SCLB stands for "Servers Com Load Balancer".

### L4 load balancer (TCP)

L4 load balancers are designed for high-performance systems and applications operating at the TCP level, such as databases, file servers, VoIP, gaming, and more.

Key features:

* Operates at the transport layer (layer 4) of the OSI model
* Balances TCP traffic
* Routes traffic based on IP addresses and ports without inspecting packet content
* Supports proxy protocol, forwarding the client's real IP address to the upstream server. Without this, upstream servers only see the load balancer's IP address
* Verifies the availability of upstream servers using the health checks feature

## Health checks

The load balancer regularly checks the status of each upstream server through health checks. It sends these checks at set intervals, using the specified port, protocol, and path. If a health check fails, the upstream is temporarily removed from the pool of available nodes. Once the upstream passes a subsequent health check, it is automatically reinstated into the pool.

The load balancer directs traffic only to healthy upstreams. For L7 instances, the load balancer expects an HTTP 2xx or 3xx response from a functioning upstream server. Each upstream server is checked approximately every 5 seconds.

## Geo IP

Geo IP is a load balancer feature that determines the geographic location of a client based on their IP address. It is useful for geographically distributed systems, enabling the following:

* Routing requests based on the client location
* Managing access (allow or restrict) to specific resources based on the client geographic location
* Optimizing the route of requests to reduce latency by directing requests to the nearest servers

For L7 load balancers, the Geo IP service maps the client IP address against the MaxMind GeoIP® database and injects the following header fields into HTTP requests sent to upstream servers:

| Header                    | Description                                        |
| ------------------------- | -------------------------------------------------- |
| `X-SCLB-GEO-CITY-NAME`    | City name, e.g., "Amsterdam", "Washington"         |
| `X-SCLB-GEO-POSTAL-CODE`  | Postal code, e.g., `190000`                        |
| `X-SCLB-GEO-STATE-NAME`   | USA state name, e.g., "Texas"                      |
| `X-SCLB-GEO-STATE-CODE`   | USA state code, e.g., "TX"                         |
| `X-SCLB-GEO-GPS-LAT`      | Latitude                                           |
| `X-SCLB-GEO-GPS-LONG`     | Longitude                                          |
| `X-SCLB-GEO-AS-NUM`       | Autonomous system number                           |
| `X-SCLB-GEO-AS-ORG`       | Autonomous system organization                     |
| `X-SCLB-GEO-COUNTRY-CODE` | 2-letter country code, e.g., "NL", "US"            |
| `X-SCLB-GEO-COUNTRY-NAME` | Country name, e.g., "Netherlands", "United States" |

These headers can be used for content personalization, fraud detection, ad targeting, traffic analysis, compliance, and more.

## Access logs

The **Logs storing** feature allows logging information about requests processed by the load balancer to NGINX-style access log files. Logs are stored in the cloud storage of your Servers.com account in one-minute segments, with new files added in batches of five every five minutes.

### Enabling and disabling

Logs storing can be enabled during the creation of a new load balancer instance or toggled on or off in the **Load Balancer Details** of an existing instance. When enabling, you will be prompted to select a cloud storage region.

### Accessing log files

Log files can be accessed via Swift API, FTP, or the Customer Portal. A `load-balancer-logs` folder is created automatically in the selected cloud storage region, containing a subfolder named after the load balancer's ID.

Segment filename format:

```
%lb_hashid%_%location_code%_%lb_host_id%.YYYY-MM-DD_HH-MM.gz
```

### Log format

TCP (Layer 4):

```
$msec  $remote_addr:$remote_port $protocol [$upstream_addr] [$proxy_protocol_port] [$session_time] $status $bytes_sent $bytes_received
```

HTTP/HTTPS (Layer 7):

```
'$msec $request_id@$xsclbnodeid [$scheme://default:$server_port] $remote_addr:$remote_port '
'[$upstream_addr] [$upstream_status] [$upstream_connect_time] [$upstream_header_time] [$upstream_response_time] '
'$status $request_time "$request" "$http_referer" "$http_user_agent"'
```

### Pricing

The Logs storing option has a fixed monthly price, billed in addition to the fixed fee of the load balancer instance. Cloud storage is billed separately at its regular price.


# Getting started (/docs/load-balancer/getting-started)



To create a load balancer, you need at least one provisioned server.

1. In the left-hand menu, navigate to **Load Balancers** and click **Create new balancer**.
2. Select the type of balancer. See [Types of load balancing](/load-balancer/concepts/#types-of-load-balancing).
3. Choose one of the available locations.
4. Configure the load balancer settings. The settings are divided into sections in the interface. Fill in the fields in each section:

### Upstream groups

Here you can configure the upstream groups.

* **Group name** — the name of the pool of upstream servers
* **Protocol** — the protocol used by the load balancer to communicate with upstream servers (for HTTPS L7 load balancer):
  * `HTTP(S)` — supports standard HTTP/HTTPS for web requests and requires an SSL certificate
  * `gRPC(S)` — supports gRPC over HTTP/2 for high-performance service-to-service communication and requires an SSL certificate
* **Upstream server** — create the upstream servers pool by selecting servers from the dropdown list and clicking **Add upstream server**. When selecting an upstream server, it is recommended to use the server's private IP address, as traffic routed through the GPN is free of charge. If a public IP address is used, the traffic will be routed through the internet, incurring additional charges. For each upstream server, specify:
  * **Port** — the port to which the load balancer will forward requests for that server
  * **Weight** — the priority for distributing traffic; servers with higher weights will receive more requests
* **Algorithm** — choose one of the available traffic distribution algorithms. See [Algorithms](/load-balancer/concepts/#algorithms)
* **Sticky cookie** — tick the checkbox if you want to enable session persistence, binding all user requests to the same upstream server (for HTTPS L7 load balancer)

### Health check settings

In this section, configure the health check parameters for the upstream servers.

For HTTPS L7 load balancer:

* **Domain** — the domain used in health check requests
* **Health check path** — the path on the upstream server used to check availability
* **Request method** — the HTTP method for health checks:
  * `GET` — requests the full response from the server
  * `HEAD` — requests only response headers, reducing server load
* **Checks to fail** — the number of consecutive failed checks required to mark a server as unhealthy
* **Checks to pass** — the number of consecutive successful checks required to mark a server as healthy
* **Inspect new upstream servers** — if enabled, the load balancer performs health checks on new upstream servers before adding them to the active pool

For both load balancer types:

* **Interval** — the time in seconds between health checks for the upstream servers
* **Jitter** — a random value to be added to the check interval, reducing network load and improving stability

### Forwarding rules

Here you can configure forwarding rules.

For both load balancer types:

* **Rule name** — the name of the rule
* **Ports** — the ports through which the load balancer will accept incoming requests

For HTTPS L7 load balancer:

* **Domains** — the domains handled by the specified forwarding rule
* **Protocol** — defines the protocol for incoming request handling:
  * `HTTP` — for unencrypted connections
  * `HTTPS` — for encrypted connections using SSL/TLS
  * `HTTP/2` — if enabled, the load balancer supports requests using the HTTP/2 protocol
* **Redirect HTTP to HTTPS** — if enabled, all HTTP requests are automatically redirected to HTTPS
* **Minimum TLS version** — sets the minimum allowed TLS version for HTTPS connections:
  * `TLSv1.2` — widely supported version with high compatibility
  * `TLSv1.3` — provides enhanced security and performance but may not be supported by older clients
* **SSL certificate** — allows selecting a pre-created SSL certificate to encrypt HTTPS connections on the load balancer

### Rewrites

Enables path rewriting for incoming requests, redirecting them to a specified path and corresponding upstream server group (for HTTPS L7 load balancer).

* **Location** — the original path or URI to be rewritten
* **Upstream path** — the new path or URI to which the request will be redirected
* **Upstream group** — the upstream server group to which the request will be directed after path rewriting

### Set real IP from header

Here you can configure the forwarding of the client's real IP address to the upstream server (for HTTPS L7 load balancer).

* **Disabled** — the real IP address is not forwarded; upstream servers see the load balancer's IP address
* **X-Real-IP** — uses the `X-Real-IP` header to forward the client's real IP address
* **X-Forwarded-For** — uses the `X-Forwarded-For` header, where the client's real IP address is listed first

### Custom error pages

Here you can configure custom error pages for specific HTTP codes (for HTTPS L7 load balancer).

* **Error code** — displays a custom page when a specified HTTP error code occurs
* **Redefine HTTP code** — replaces the displayed HTTP code with another (e.g., change 500 to 404)
* **Upload file** — uploads a custom error page file (maximum size: 4096 bytes)
* **File name** — the name of the uploaded file
* **File size** — the size of the uploaded file
* **Content type** — selects the content type of the uploaded file (e.g., `text/html`)

### Ports

Here you can configure ports (for TCP L4 Load Balancer).

* **Proxy Protocol** — enables forwarding of the client's real IP address to upstream servers. When enabled, upstream servers see the client's original IP instead of the load balancer's IP
* **Upstream group** — selects the upstream server group to which requests will be forwarded

### Additional options

Here you can configure additional options.

* **Geo IP** — if enabled, the load balancer determines the client's geographical location based on their IP address. This information can be used for request routing or access restrictions (for HTTPS L7 load balancer)
* **Logs storing** — tick the checkbox if you want to save logs of requests processed by the load balancer. Logs will be stored in the cloud storage in NGINX format

5. In the **Cluster** section, specify the name of the dedicated cluster (if applicable).
6. In the **Name** section, provide a name for the load balancer to distinguish it from others in the list.
7. Click **Create**.

Your load balancer instance will be created.


# Load Balancer (/docs/load-balancer)



The **Load Balancer** distributes traffic across pools of dedicated and cloud servers at both L4 and L7, with health checks, session persistence, SSL termination, and Geo IP routing - backed by BGP anycast for high availability without downtime.

* **L4 and L7 load balancing** - cover TCP traffic, HTTP/HTTPS APIs, databases, VoIP, and gaming
* **Health checks and automatic failover** - route traffic away from unhealthy upstreams instantly
* **SSL termination** - offload TLS processing from your application servers
* **Session persistence** - keep user sessions pinned to the same upstream when needed

<DocCards>
  <DocCard title="Concepts" description="Understand components, algorithms, and load balancing types." href="/load-balancer/concepts/" />

  <DocCard title="Billing" description="See how Load Balancer usage and pricing are calculated." href="/load-balancer/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Create and configure your first Load Balancer instance." href="/load-balancer/getting-started/" />

  <DocCard title="Service Management" description="Manage upstreams, health checks, and load balancer settings." href="/load-balancer/service-management/" />
</DocCards>


# Limitations (/docs/load-balancer/limitations)



The balancer has the following limitations:

* Up to 32 public IP addresses per load balancer (the cost of the first IP address is included in the base price of the load balancer)
* Up to 16 forwarding rules per load balancer
* Up to 500 upstream servers per load balancer
* Port range: 1 to 65535
* Weight range: 1 to 999999
* Number of domains for HTTP/S load balancer (L7) is unlimited
* Using identical rules for a single domain (vhost) is not allowed
* An SSL certificate is required if at least one rule is configured for HTTPS (currently, only one certificate can be attached per load balancer)

Removing of uplinks or private IP addresses is forbidden for Upstream Hosts in the Customer Portal because it will break the communication between the load balancer and its upstream.


# Service management (/docs/load-balancer/service-management)



Managing your load balancer doesn't stop at initial setup — you may need to scale your upstream pool up or down as your infrastructure changes, or decommission a load balancer instance entirely. This article covers both operations.

### How to add or remove an upstream in an existing load balancer

You can manage the pool of upstream servers in your load balancer by adding or removing upstreams. To do so, complete the following steps:

1. In the left-hand menu, navigate to **Load Balancers** and select the load balancer instance you created
2. Click **Edit** and scroll to the **Upstream groups** section
   * To add an upstream to the pool, click **Add upstream server** and select a server from the list
   * To remove an upstream from the pool, click the **trash bin** icon next to the server
3. Click **Save** to apply the changes

### How to delete the load balancer

To delete a load balancer instance, complete the following steps:

1. In the left-hand menu, navigate to **Load Balancers** and select the load balancer instance you created
2. Scroll to the **Services** section and click **Cancel service**
3. In the confirmation window, click **Cancel service** to confirm your action

The load balancer instance will be deleted, and you will no longer be billed for the service.


# Billing (/docs/managed-kubernetes/billing)



A Kubernetes cluster price consists of the following components:

* Control plane cloud servers are free.
* Worker nodes are charged at a price of a regular dedicated server.
* Load balancers created for the needs of ingress controller and cloud controller manager are charged at the regular load balancer rate.

### Cancellation terms

When a Kubernetes cluster is cancelled, control plane nodes will be deleted immediately, and worker nodes will move to regular dedicated servers. These dedicated servers will continue to be billed. To cancel them, initiate our regular dedicated server cancellation procedure.


# Cloud controller manager (/docs/managed-kubernetes/cloud-controller-manager)



The cloud controller manager (CCM) is a Kubernetes component responsible for interaction with external cloud providers via an agreed interface. When a Kubernetes cluster needs to create a resource on the provider's side, CCM triggers the provider's API. CCM is installed automatically on each node of the control plane during cluster creation.

There are two scenarios that involve the Servers.com CCM:

* Node initialization
* Load balancer creation

### Node initialization

Node initialization is a process of accepting a node as a part of a Kubernetes cluster. When a server is provisioned on the Servers.com side, it is integrated into the cluster with the help of the CCM.

### Load balancer creation

When you create a `LoadBalancer` service, Kubernetes sends a command to the CCM to create an L4 (TCP) load balancer. This load balancer is located outside of the Kubernetes cluster and serves to route traffic to your applications. CCM creates a new load balancer for each service object with the `LoadBalancer` type.

#### IP address assignment

The actual creation of the load balancer happens asynchronously, and information about the provisioned balancer and its IP address is pushed back into the `.status.loadBalancer` field of a service object. Once the service object is destroyed, its IP address is returned to the shared pool and will eventually be assigned to another object.

#### Billing

A load balancer created via CCM will be billed at its regular price as a standalone service.

#### Annotations

Annotations manage parameters of a TCP (L4) load balancer. They are specified within a `Service` object.

| Name                                    | Default     | Example                 | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| --------------------------------------- | ----------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `servers.com/load-balancer-name`        | (automatic) | `ams1-cluster-balancer` | By default, a load balancer gets an automatically generated name. This annotation allows giving it a custom name when creating a service object.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| `servers.com/load-balancer-location-id` | (automatic) | `1`                     | By default, a load balancer is created in an automatically selected location. To define a specific one, specify its [Public API ID](https://developers.servers.com/api-documentation/v1/#tag/Location/operation/ListLocations) during service object creation.                                                                                                                                                                                                                                                                                                                                                                                                                                         |
| `servers.com/proxy-protocol`            | `false`     | `true`                  | The proxy protocol enables applications to receive the client IP address, the load balancer IP address, and both port numbers. Requests originating from outside the cluster follow this path and work as expected. However, requests originating from a Pod and sent to the Service may be handled by Kubernetes as cluster-internal Service traffic and routed directly to the Service backend without traversing the external load balancer. In that case, the connection does not pass through the L4 load balancer, the PROXY protocol header is not injected, and applications expecting it may reject the connection or parse it incorrectly. Managed by the boolean values `true` and `false`. |
| `servers.com/cluster-id`                | `nil`       | `ex4mp1e`               | When a cluster ID is specified, a load balancer for the CCM will be created in the dedicated cluster. When not specified, a load balancer will be created in a public cluster.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |

This is an example of a `LoadBalancer` service with the proxy protocol annotation:

```yaml
---
apiVersion: v1
kind: Service
metadata:
  name: hello-world-svc
  annotations:
    servers.com/proxy-protocol: "true"
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: hello-world-app
  type: LoadBalancer
```


# Concepts (/docs/managed-kubernetes/concepts)



Kubernetes is an open-source system for automating the deployment, scaling and management of containerized applications.

In this article, we introduce Kubernetes entities and explain how they work with Servers.com infrastructure. You can refer to this [official Kubernetes documentation](https://kubernetes.io/docs/home/) to learn more about each component.

### Control plane

Control plane is a set of components used to manage a Kubernetes cluster. It consists of three cloud servers running on different computing nodes.

Control plane nodes are not accessible to users via SSH and are not displayed in the Customer Portal. Instead, you will have cluster-level administrative rights to manage any Kubernetes API objects that you need for your workloads using the Kubernetes command-line client - `kubectl`.

### Worker node

A worker node runs applications within a Kubernetes cluster. Servers.com provides you with worker nodes running on dedicated servers. Once a node is ready, you can access it via Secure Shell (SSH). The main requirement for a dedicated server to be a Kubernetes node is an ability to build disks in RAID level 1. To prevent resource overuse, Servers.com configures resource reservation in `kubelet` based on the characteristics of a specific node.

Just like dedicated servers, you can request RAM and disk upgrades for Kubernetes bare metal worker nodes.

### Node removal

When a worker node is removed, all of its pods will migrate to another node. A removed node will become a regular dedicated server to use at your disposal. You may also choose to cancel it by following our server cancellation procedure.

### Service

A service is a set of Kubernetes pods managed under the same policy. This entity plays an important role when working with the ingress and cloud controller managers as they may interact with the following service types:

* **LoadBalancer**: requests are sent to a load balancer's IP address. This service initiates the creation of the Servers.com TCP (L4) load balancer via the cloud controller manager.
* **NodePort**: requests are sent to a node's IP address and to a specific port. Unlike LoadBalancer, NodePort doesn't trigger the creation of a load balancer.

Because the ClusterIP service is not intended for interaction with external networks, it does not utilise the cloud controller manager or ingress controller.

### Ingress controller

An ingress controller is a tool that routes and balances traffic from external networks across services within a Kubernetes cluster. Rules that define traffic routing are called **ingress rules**. A specification describing ingress rules is called an **ingress resource**.

You can learn more in the [Servers.com ingress controller](/managed-kubernetes/ingress-controller) article.

To install a third-party ingress controller, follow [these instructions](/managed-kubernetes/third-party-ingress-controller).

### Cloud controller manager

A cloud controller manager is responsible for interacting with external resources. In the case of Servers.com, a cloud controller manager triggers the provisioning of a TCP load balancer after a service with the LoadBalancer type has been created.

### Storage

Storage solutions for Kubernetes can be roughly divided into these two groups:

* Local storage - the one hosted on a worker node itself
* External storage - storage using infrastructure outside of a Kubernetes cluster


# Getting started (/docs/managed-kubernetes/getting-started)



To create a Kubernetes cluster, complete the following steps:

1. Log in to the [Customer Portal](https://portal.servers.com/) and navigate to **Kubernetes**
2. Click **Create**
3. Select a location and a Kubernetes version that is compatible with your deployment environment. If there are no specific compatibility requirements, it is recommended to use the latest stable version
4. In the **Nodes** field, click **Add Node** and select the dedicated servers that will be used as worker Kubernetes nodes
5. Configure each node with parameters that meet the requirements of your deployed applications, including:

* OpenEBS: a software-defined storage (SDS) solution for Kubernetes used to manage persistent volumes (PV). This setting is useful if there is no external storage (e.g., EBS, NFS) or if flexible disk management is required

6. Click **Add**
7. In the **Options** field, tick the **Public access to master nodes** check box if you need to allow access to master nodes from the public network. By default, nodes are only accessible via a private network. Please note, this setting is irreversible after cluster creation
8. Enter a cluster name
9. In the **Upgrade Settings** section, specify **Maintenance Frequency** to determine how often automatic updates will be applied to cluster components
10. Click **Order** and then **Buy Now**

A cluster will appear on the [Kubernetes page](https://portal.servers.com/k8s) with the status, **Pending**.

Dedicated servers selected for worker nodes can be viewed on the [Manage](https://portal.servers.com/servers/my) page.

Keep in mind that:

* Control Plane nodes won't be shown on the Cloud Servers list
* The cluster provisioning time depends on the availability and provisioning times of all servers ordered for the cluster
* Master nodes of a newly created cluster are only accessible from the private network by default. To expose them to the Internet, enable the **Allow access to cluster master nodes from the public network** checkbox.


# How to access a Kubernetes cluster (/docs/managed-kubernetes/how-to-access-a-kubernetes-cluster)



To access and execute commands in a Kubernetes cluster, you can use the `kubectl` command-line utility. It allows you to deploy applications, manage cluster resources and view event logs.

The utility is cross-platform and can be installed on various operating systems, including Linux, macOS, and Windows.

For more detailed information, including a full list of available commands, refer to the official documentation.

### Getting started with kubectl

To avoid unexpected issues, ensure that the `kubectl` version differs from the cluster version by no more than one minor version.

For example, a client running version v1.31 can interact with control planes running versions v1.30, v1.31, and v1.32.

To check the client version:

1. Go to the Customer Portal
2. In the left-hand menu, navigate to **Kubernetes** and select your cluster
3. The cluster version will be displayed in the **Version** field

### Installing kubectl

This guide provides step-by-step instructions on how to install `kubectl` on macOS using `curl`.
For other operating systems, refer to the official documentation.

#### Installing the kubectl binary with curl on macOS

1. Download the suitable version by executing the following command in the terminal:

   ```
   curl -LO https://dl.k8s.io/release/{version}/bin/darwin/{CPU}/kubectl
   ```

   Replace:

   * `{version}` with the required version, e.g., `v1.31.0`
   * `{CPU}` with the correct architecture:
     * For Intel: use `amd64`
     * For Apple Silicon: use `arm64`

2. Validate the binary file (optional):

   * Download the checksum file:

     ```
     curl -LO https://dl.k8s.io/release/{version}/bin/darwin/{CPU}/kubectl.sha256
     ```

   * Validate the binary against the checksum:

     ```
     echo "$(cat kubectl.sha256)  kubectl" | shasum -a 256 --check
     ```

   * If successful, the output will display:

     ```
     kubectl: OK
     ```

   * If the check fails, you will see:

     ```
     kubectl: FAILED
     shasum: WARNING: 1 computed checksum did NOT match
     ```

   * Download the same version of the binary and try again

3. Make the `kubectl` binary executable:

   ```
   chmod +x ./kubectl
   ```

4. Move the `kubectl` binary to a directory included in your system PATH by executing the following commands:

   ```
   sudo mv ./kubectl /usr/local/bin/kubectl
   sudo chown root: /usr/local/bin/kubectl
   ```

   Note: ensure `/usr/local/bin` is included in your PATH environment variable. If you receive an error such as **No such file or directory**, create the directory using the following command:

   ```
   sudo mkdir -p /usr/local/bin
   ```

5. Verify the installed version:

   ```
   kubectl version --client
   ```

If successful, the output will display the version of the `kubectl` client.

### Configuring KUBECONFIG

To use the `kubectl` utility with a Kubernetes cluster, you need a configuration file (`kubeconfig`). This allows you to locate and access one or multiple clusters and seamlessly switch between them. For more details, refer to the official documentation.

1. Download the configuration file for your cluster from the **Kubernetes cluster details** page in the Customer Portal.

2. Export the `KUBECONFIG` environment variable, specifying the path to the configuration file:

   ```
   export KUBECONFIG={path to config file}
   ```

3. Ensure that `kubectl` is properly configured by getting the cluster information:

   ```
   kubectl cluster-info
   ```


# Managed Kubernetes (/docs/managed-kubernetes)



**Managed Kubernetes** runs your container workloads on a fully managed control plane with Enterprise Bare Metal worker nodes - you get `kubectl` access and full cluster control while we handle node provisioning, upgrades, load balancer integration, and storage.

* **Bare metal worker nodes** - dedicated hardware performance without any virtualization overhead
* **Managed control plane** - we operate etcd, the API server, and scheduler so you don't have to
* **Persistent storage** - attach Remote Block Storage volumes to any node in your cluster
* **Native integrations** - built-in ingress controller and cloud controller manager

<DocCards>
  <DocCard title="Concepts" description="Understand how Managed Kubernetes is structured, priced, and operated." href="/managed-kubernetes/concepts/" />

  <DocCard title="Billing" description="See how cluster and node pricing is calculated." href="/managed-kubernetes/billing/" />

  <DocCard title="Persistent Storage Options" description="Attach block storage volumes to your Kubernetes workloads." href="/managed-kubernetes/persistent-storage-options/" />

  <DocCard title="Ingress Controller" description="Route external traffic to services using the built-in ingress controller." href="/managed-kubernetes/ingress-controller/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Deploy your first Kubernetes cluster on Servers.com." href="/managed-kubernetes/getting-started/" />

  <DocCard title="Service Management" description="Scale nodes, manage node groups, and configure your cluster." href="/managed-kubernetes/service-management/" />

  <DocCard title="How to Access a Kubernetes Cluster" description="Connect to your cluster using kubectl and kubeconfig." href="/managed-kubernetes/how-to-access-a-kubernetes-cluster/" />

  <DocCard title="Install the Web UI Dashboard" description="Deploy and access the Kubernetes Dashboard on your cluster." href="/managed-kubernetes/installing-web-ui-dashboard/" />
</DocCards>


# Ingress controller (/docs/managed-kubernetes/ingress-controller)



Exposing complex applications running within a Kubernetes cluster to the internet and traffic routing requires a comprehensive approach.
The ingress controller is a tool that solves these tasks along with a variety of additional options.
It offers the following key features:

* External access to services within a cluster
* Traffic load balancing
* SSL/TLS termination

The advantage of the ingress controller is that it can serve several services at once (unlike a Kubernetes Service with the load balancer).
The Servers.com ingress controller is built upon our HTTP(S) (L7) load balancer and shares its wide set of features.

## Limitations

Routing via multiple paths to a single service (multi-path routing) is not supported.

## Services

It is helpful to get acquainted with the following particularities that come with using Kubernetes Services with the ingress controller:

* **ClusterIP** - this service is not intended for interaction with external networks so it's not used along with the ingress controller
* **LoadBalancer** - the LoadBalancer service uses a cloud controller manager that works on top of the Servers.com TCP (L4) Load Balancer. In this case, you will have two load balancers: one for the cloud controller manager and one for the ingress controller
* **NodePort** - unlike the LoadBalancer service, NodePort doesn't need an additional TCP (L4) Load Balancer

## Annotations

An annotation is a Kubernetes entity that helps manage ingress resources and service objects. In the Servers.com ingress controller, annotations are based on the Servers.com L7 Load Balancer's features.
They are briefly described in this article below (for more details, refer to HTTP Load Balancer features).

## Ingress controller annotations

This set of annotations is applied to the ingress resource. It means they will work on all the services under the ingress controller.

| Name                                                             | Default | Example       | Description                                                                                                                                                                                                                                                                                                                                                        |
| ---------------------------------------------------------------- | ------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| servers.com/load-balancer-store-logs-region-code                 | nil     | NL01          | Defines a location for cloud storage that will keep logs from the balancer. When this annotation is not specified or has the nil value, the feature will be disabled. The value must coincide with the cloud region code that you can find in the table at the end of this article. It's allowed to define this parameter both ways: NL01 or nl01.                 |
| servers.com/load-balancer-geo-ip-enabled                         | false   | true          | Enables the GeoIP option.                                                                                                                                                                                                                                                                                                                                          |
| servers.com/load-balancer-min-tls-version                        | 1.3     | 1.2           | Defines the minimum TLS version. Both the 1.2 and 1.3 values are available.                                                                                                                                                                                                                                                                                        |
| servers.com/load-balancer-real-ip-trusted-networks (coming soon) | nil     | 172.10.1.0/24 | Specifies trusted networks for the X-Real-IP header. A trusted network is one that will receive real IP addresses instead of the balancer's IP. More details in this NGINX documentation. If this annotation is specified, the X-Real-IP feature is enabled; otherwise, disabled. **Please note:** this annotation is not yet released but will be available soon. |
| servers.com/cluster-id                                           | nil     | ex4mp1e       | When a cluster ID is specified, a load balancer for the ingress controller will be created in the dedicated cluster. When this annotation is not specified, a load balancer will be created in a public cluster.                                                                                                                                                   |

An example of the ingress configuration with an annotation:

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    servers.com/load-balancer-geo-ip-enabled: "true"
```

## Service annotations

The below annotations are applied to a specific Kubernetes Service (NodePort or LoadBalancer).

| Name                                          | Default                    | Examples                                     | Description                                                                                  |
| --------------------------------------------- | -------------------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------- |
| servers.com/load-balancer-balancing-algorithm | random\_least\_connections | random.least\_conn, round-robin, least\_conn | Manages the balancing algorithm: random\_least\_connections, least\_connections, round-robin |
| servers.com/app-protocol                      | http                       | http2                                        | Defines whether HTTP or HTTP2 is used.                                                       |
| servers.com/app-healthcheck-path              | /healthz                   | /example                                     | A path for healthcheck starting from slash.                                                  |
| servers.com/app-healthcheck-domain            | nil                        | example.com                                  | The domain for healthcheck.                                                                  |
| servers.com/app-healthcheck-requests-method   | GET                        | POST                                         | An HTTP method for a healthcheck: GET or POST                                                |
| servers.com/app-healthcheck-checks-to-fail    | 1                          | 2                                            | A number of checks to consider as failed. Range: 1-100                                       |
| servers.com/app-healthcheck-checks-to-pass    | 3                          | 1                                            | A number of checks to consider as passed. Range: 1-100                                       |
| servers.com/app-healthcheck-interval          | 5                          | 10                                           | An interval between checks in seconds. Range: 1-60                                           |
| servers.com/app-healthcheck-jitter            | 0                          | 1                                            | The jitter in seconds. Range: 1-10                                                           |

An example of a configuration with service annotations:

```
apiVersion: v1
kind: Service
metadata:
  name: example-service
  annotations:
    servers.com/load-balancer-balancing-algorithm: "random_least_connections"
```

## TLS settings

For enhanced security, you can set up TLS (Transport Layer Security) protocol within the Servers.com ingress controller. There are two ways to do this:

* Using an SSL certificate from the Servers.com Customer Portal
* Creating a secret object in Kubernetes

### Using an SSL certificate from the Customer Portal

An SSL certificate from the Customer Portal can be added to the ingress resource using the following annotation:

```
servers.com/certificate-my.example.com: "sc-certmgr-cert-id-<certificate ID>"
```

* **servers.com/certificate-my.example.com** - the annotation name
* **my.example.com** - a domain associated with the SSL certificate
* **`<certificate ID>`** - a unique identifier of an SSL certificate. ID can be found on the SSL certificates page or fetched by performing the relevant API request

The configuration may look like this for an SSL certificate with ID - ex4mp1e1D:

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    servers.com/certificate-my.example.com: "sc-certmgr-cert-id-ex4mp1e1D"
```

### Creating a secret object in Kubernetes

To create a secret object in Kubernetes, use this command:

```
kubectl create secret tls certificate−name−−key{key-file} --cert ${certificate-file}
```

Key and certificate files are hosted locally on a machine from where `kubectl` is executed.
This is what the secret object may look like:

```
apiVersion: v1
kind: Secret
metadata:
  name: example-tls
  namespace: default
data:
  tls.crt: base64 encoded cert
  tls.key: base64 encoded key
type: kubernetes.io/tls
```

Once the secret object is created, it can be used within the ingress object configuration.
Here is an example of the ingress object with TLS configured:

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  ingressClassName: serverscom
  tls:
    - hosts:
        - example.com
      secretName: example-tls
```

## Useful materials

### Cloud regions

This table contains a list of cloud region codes to use in the `servers.com/load-balancer-store-logs-region-code` annotation.

| **Region** | **Region code** |
| ---------- | --------------- |
| Amsterdam  | NL01            |
| Dallas     | US01            |
| Luxembourg | LU01            |
| Singapore  | SIN01           |


# How to install Web UI Dashboard (/docs/managed-kubernetes/installing-web-ui-dashboard)







Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized applications, and manage the cluster resources.

<img alt="Kubernetes Web UI Dashboard overview" src={__img0} />

Below is a step-by-step guide on installing the Kubernetes Dashboard and accessing it using a token issued in the [Customer Portal](https://portal.servers.com/login).

### Deploying the Kubernetes Dashboard

The installation command depends on the Dashboard version. In case of errors in the console output or updates, refer to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/#deploying-the-dashboard-ui).

Kubernetes Dashboard supports only Helm-based installation currently, as it is faster and gives better control over all dependencies required by Dashboard to run.

1. Install `Helm`.

2. Add the Kubernetes Dashboard repository:

   ```bash
   helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
   ```

3. Deploy the Kubernetes Dashboard:

   ```bash
   helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard \
     --create-namespace --namespace kubernetes-dashboard
   ```

The Kubernetes Dashboard will now be deployed in your cluster.

### Accessing the Dashboard UI

#### Create a Dashboard user

This example demonstrates how to create a user account with administrative rights. If you need to create a new user, assign permissions, and generate an individual token for that user, refer to the [creating a sample user](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) guide.

1. Create a manifest file (e.g., `dashboard-adminuser.yaml`) and add the following snippets to it:

   **Creating a `ServiceAccount`** with the name `admin-user` in namespace `kubernetes-dashboard`:

   ```yaml
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: admin-user
     namespace: kubernetes-dashboard
   ```

   **Creating a `ClusterRoleBinding`** for the `ServiceAccount`:

   ```yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: admin-user
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: cluster-admin
   subjects:
     - kind: ServiceAccount
       name: admin-user
       namespace: kubernetes-dashboard
   ```

2. Save the file and apply it:

   ```bash
   kubectl apply -f dashboard-adminuser.yaml
   ```

The user account has now been successfully created.

#### Command line proxy

You can enable access to the Dashboard using the `kubectl` command-line tool by running:

```bash
kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443
```

`kubectl` will make Dashboard available at [https://localhost:8443](https://localhost:8443).

In the **Bearer Token** field, enter the value obtained from the [Customer Portal](https://portal.servers.com/login) → **Kubernetes Cluster Details** → **Secret** field.

<img alt="Kubernetes Dashboard Bearer Token login screen" src={__img1} />

The UI can only be accessed from the machine where the command is executed. Use `kubectl port-forward --help` for more options.


# Limitations (/docs/managed-kubernetes/limitations)



Keep the following limitations in mind when using the Managed Kubernetes service on Servers.com.

* It's advised not to use more than 110 pods per node (as per [Kubernetes' official recommendation](https://kubernetes.io/docs/setup/best-practices/cluster-large/))
* Dedicated servers that you have already ordered cannot be selected for worker nodes
* There is no autoscaling
* Control plane nodes are not accessible to users via SSH and are not displayed in the Customer Portal
* The **Public access to master nodes** setting is irreversible after cluster creation
* Servers.com does not offer provider-specific storage options for Kubernetes

Some features come with their own specific limitations beyond those listed above. Refer to the [Node groups](/managed-kubernetes/node-groups/) and [Kubernetes upgrades](/managed-kubernetes/upgrades/) articles for details.


# Node groups (/docs/managed-kubernetes/node-groups)



A Kubernetes **node group** is a set of worker nodes united under the same name as one collection. Such a group helps you distinguish workloads within a cluster.

This feature does not perform any technical adjustments — it is purely for grouping worker nodes for better management and does not limit interaction between worker nodes from different groups.

## Use cases

Some examples of how you can group worker nodes within a cluster:

* **Resource segregation** — worker nodes with databases in a "High-memory" group, nodes for web services in a "Performance" group
* **Environment isolation** — "Production" and "Testing" groups
* **Temporary resource labeling** — a "Temporary" group for resources during peak loads

All clusters created before the feature release are assigned a **default** group that contains all worker nodes.

## Management

### Customer Portal

Node groups can be managed in several ways:

* During the cluster order, it is mandatory to create a node group in the **Add node** modal window.
* When a cluster is active, you can manage groups on the **Kubernetes cluster** page under the **Node groups** tab:
  * Add node groups
  * Delete node groups
  * Add nodes to node groups
* You can also **move nodes between groups** on the **Kubernetes cluster** page under the **Nodes** tab.

### Public API

Node groups can be managed via the public API using the following requests:

* [List node groups for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/ListNodeGroupsForAKubernetesCluster)
* [Create a node group for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/CreateANodeGroupForAKubernetesCluster)
* [Update a node group for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/UpdateANodeGroupForAKubernetesCluster)
* [Delete a node group for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/DeleteANodeGroupForAKubernetesCluster)
* [Move nodes to a group for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/MoveNodesToAGroupForAKubernetesCluster)
* [Update a node for a Kubernetes cluster](https://developers.servers.com/api-documentation/v1/#tag/Kubernetes-Cluster/operation/UpdateANodeForAKubernetesCluster) — to reassign a node to another group

## Limitations

* A node group must be associated with a specific cluster and can belong to only one cluster.
* One cluster can have a maximum of 128 node groups.
* Deleting a cluster will delete all associated node groups.
* An empty node group can exist.
* A group containing nodes cannot be deleted.
* Only active nodes can be moved.


# Persistent storage options (/docs/managed-kubernetes/persistent-storage-options)



Servers.com does not offer provider-specific storage options for Kubernetes at the moment. We suggest you to consider one of the following publicly available options.

### Local Persistent Volumes

A local persistent volume (LPV) represents a mounted local storage device such as a disk, partition or directory on a worker node. With the Local Persistent Volume plugin being shipped alongside Kubernetes, Kubernetes workloads can now consume high performance local storage using the same volume APIs that app developers have become accustomed to.

Kubernetes scheduler understands which node a Local Persistent Volume belongs to and ensures that a pod using a Local Persistent Volume is always scheduled to the same node. However, local volumes are still subject to the availability of the underlying node and are not suitable for all applications.

Please refer to the Kubernetes documentation for details and example configurations.

The `path` field in a PersistentVolume spec specifies an absolute path to the local storage device on a node. The recommended path in the Servers.com environment is `/mnt`.

Please be aware that the following RAID configurations are used on your dedicated worker nodes:

| **Number of disks in a bare-metal server** | **RAID configuration** |
| ------------------------------------------ | ---------------------- |
| 2                                          | RAID 1                 |
| 4                                          | RAID 10                |
| > 4                                        | RAID 6                 |

The amount of disk space available on a single node can be found by using `kubectl describe nodes <NODENAME>`.

#### Persistent volumes using volume plugins shipped with Kubernetes

Kubernetes comes with a number of plugins for persistent volume provisioning, including plugins for OpenStack Cinder and Ceph RBD. Please refer to the Kubernetes documentation for details and example configurations.

#### Persistent volumes using CSI-enabled plugins

An industry standard called "Container Storage Interface" (CSI) allows storage vendors to develop plugins working across a number of container orchestration systems. Kubernetes has support for CSI 1.0. Check out a list of publicly available plugins.

#### Rook.IO — a storage orchestrator for Kubernetes

Rook is an open source storage orchestrator for Kubernetes. Rook turns storage software, such as Ceph, into a self-managing, self-scaling, and self-healing storage service running on top of a Kubernetes cluster. Rook automates deployment, bootstrapping, configuration, provisioning, scaling, upgrading, migration, disaster recovery, monitoring, and resource management.

Please refer to the Rook's Ceph Storage Quickstart manual for the basic procedure of setting up of a Ceph cluster on top of your Kubernetes cluster.

#### Velero.io — backup and disaster recovery tool for Kubernetes

Velero is an open source tool to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. Read how it works on its official website.


# Service management (/docs/managed-kubernetes/service-management)



This page explains how to manage the lifecycle of your Kubernetes cluster — adding and removing worker nodes, and canceling a cluster when it is no longer needed.

### How to add a node

You can add worker nodes to a cluster at any time in the [Customer Portal](https://portal.servers.com/k8s/) by following these steps:

1. In the left-hand menu, navigate to **Kubernetes** and select your cluster
2. In the **Kubernetes cluster details**, click **Add node**, select and configure the dedicated server that will be used as a worker Kubernetes node
3. Click **Add** then click **Buy now**

The node will be added to your cluster.

### How to remove a node

You can remove worker nodes from a cluster at any time in the [Customer Portal](https://portal.servers.com/k8s/).
The released servers will remain in your account under the **Dedicated Servers** section and will be billed as regular dedicated servers until manually canceled. To reuse the servers, only an OS reinstallation is required.

To remove worker nodes from a cluster, complete the following steps:

1. In the left-hand menu, navigate to **Kubernetes** and select your cluster
2. In the **Kubernetes cluster details**, tick the checkbox next to the node you want to remove and click **Remove nodes**
3. In the opened window, confirm your action by clicking **Continue**

The node will be removed from your cluster.

### How to cancel a cluster

Before canceling a cluster, ensure that all running containers, workloads, persistent volumes, and networking configurations are properly migrated or backed up. Once the cluster is canceled, all associated pods, deployments, services, and storage will be permanently deleted, and this operation is irreversible.
The released servers will remain in your account and will be billed as regular dedicated servers until manually canceled.

To proceed with a cluster cancellation, complete the following steps:

1. In the left-hand menu, navigate to [Kubernetes](https://portal.servers.com/k8s)
2. Select your cluster and click **Cancel service** in the **Services** section

When the cancellation process is complete, the cluster will be canceled.


# Third-party ingress controller (/docs/managed-kubernetes/third-party-ingress-controller)



The ingress controller facilitates access to services within the Kubernetes environment from outside the cluster. Read more about the Servers.com [ingress controller in this article](/managed-kubernetes/ingress-controller).

If you want to install an ingress controller other than the Servers.com one, follow the steps listed below:

You will be able to choose which ingress controller you wish to use, but for the purposes of this guide we will demonstrate using the NGINX controller and the Helm package manager.

1. Install and configure the Helm package manager on your computer. For more information on how to install Helm package manager consult the following Helm documentation – [Installing Helm](https://helm.sh/docs/intro/install/)
2. Install or upgrade (if already installed) the `ingress-nginx` Helm chart in your Kubernetes cluster using one of the following commands:

**Option A**: if you want to enable the Proxy Protocol, use this command:

```
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace \
  --set controller.config.use-proxy-protocol=true \
  --set controller.service.annotations."servers\.com\/proxy-protocol"=true
```

**Option B**. If you do not need to configure the Proxy Protocol, use this command:

```
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace
```

After the ingress controller has been deployed, the [load balancer](https://www.servers.com/products/load-balancing-service) will be created. It's built upon the Servers.com L4 (TCP) load balancer and facilitates access to the cluster.

Now, you are ready to configure the ingress object within Kubernetes.

### Proxy Protocol

The Proxy Protocol transfers the real IP address of a user connecting to the ingress controller. It works in a similar way to Forwarded or X-Forwarded-For HTTP headers. Since the load balancer takes part in this process, the Proxy Protocol has to be configured on both sides: L4 load balancer and ingress controller.

Once the feature is disabled, you will see the IP address of the balancing node as the user's IP.


# Upgrade notes (/docs/managed-kubernetes/upgrade-notes)



This page highlights breaking changes and important considerations for Kubernetes minor version upgrades. It is not a full changelog - for complete details, follow the official Kubernetes changelog link in each section.

If you are planning an upgrade, review the relevant version section before proceeding, paying close attention to pre-upgrade requirements and component changes.

## Upgrade to 1.36

[Official Kubernetes 1.36 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md)

### What changes during upgrade

During an upgrade to Kubernetes 1.36, the following components are updated automatically:

* **containerd** is upgraded from `1.6.x` to `2.2.x`. The `containerd`, `containerd.io`, and `runc` apt packages are removed; containerd and runc are installed from upstream releases instead.
* **Calico**, **CoreDNS** and **OpenEBS** are upgraded. A rolling restart of DaemonSets occurs across nodes during the upgrade.
* **kube-proxy** mode is switched from `iptables` to `nftables`.
* **serverscom-rbs-csi** is installed as a new component. This is the Servers.com RBS CSI driver for persistent volume support.

### Pre-upgrade requirements

Kubernetes 1.36 removes fallback compatibility with containerd 1.x. Before upgrading, verify that your workloads meet the following requirements:

* **Container images:** All images must use Schema 2 or OCI manifests. Pulling Schema 1 images (`application/vnd.docker.distribution.manifest.v1+prettyjws`) was deprecated in containerd v1.7 and is not supported in containerd 2.x.

* **CRI integration:** All CRI integrations must use CRI v1. CRI v1alpha2 is not present in containerd 2.0 or later, so anything depending on v1alpha2 will not work after the upgrade.

* **Runtime plugins:** Workloads must not depend on Go `.so` runtime plugins. These were removed before the 2.x line and are not supported in containerd 2.2.

* **Custom containerd configuration:** If you have modified the containerd TOML configuration, verify that your configuration is compatible with containerd v2 before upgrading. Incompatible settings may cause conflicts with the new version.

### Component versions

| Component          | Version |
| ------------------ | ------- |
| containerd         | 2.2     |
| runc               | 1.3     |
| Calico             | 3.31    |
| CoreDNS            | 1.14    |
| OpenEBS            | 1.8     |
| serverscom-rbs-csi | 0.1     |

## Upgrade to 1.35

[Official Kubernetes 1.35 changelog](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md)

### What changes during upgrade

No breaking changes occur when upgrading to Kubernetes 1.35.

### Component versions

| Component  | Version |
| ---------- | ------- |
| containerd | 1.6     |
| runc       | 1.1     |
| Calico     | 3.26    |
| CoreDNS    | 1.11    |
| OpenEBS    | 1.2     |


# Upgrades (/docs/managed-kubernetes/upgrades)



The Kubernetes version follows the pattern **A.B.C**, where:

* **A** is a major version
* **B** is a minor version
* **C** is a patch version

For example, version `1.33.7` has major version `1`, minor version `33`, and patch version `7`.

The Servers.com Customer Portal allows you to upgrade both patch and minor versions. We strongly recommend performing upgrades in a timely manner to maintain security and ensure access to the latest Kubernetes features.

## Upgrade settings

You can configure your upgrade preferences from the Customer Portal when:

* Ordering a Kubernetes cluster — in the **Upgrade settings** block (defines the allowed time slot for patch version upgrades only).
* After a cluster is created — on its **Details** page → **Version** field → **Upgrade** button → **Upgrade settings** → **Minor versions** or **Patch versions** tab.

Settings for minor and patch versions are located on separate tabs.

## Minor versions

Before starting a minor version upgrade, make sure your cluster meets the following requirements:

* The cluster has **Active** status
* There are no pending nodes (in cart, ordered, or being created)
* The current Kubernetes version is 1.28 or higher
* The Servers.com SSH keys on worker nodes have not been deleted
* The initial check has **Passed** status

The [version upgrade notes](/managed-kubernetes/upgrade-notes/) walk you through breaking changes and key considerations for each Kubernetes minor version upgrade.

It is only possible to upgrade to one minor version higher than your current version. For example, if you have version `1.32`, you can only upgrade to `1.33`.

### Key terms

A minor version upgrade involves pod-level processes, so it's important to understand the following key terms before configuring any settings.

An **upgrade strategy** is a set of conditions and rules applied during the upgrade process. A strategy primarily defines the behavior during the following operations:

* **Drain** — evict pods safely from a node before performing maintenance. See [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) and [kubectl drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/).
* **Cordon** — mark a node as unschedulable so that new pods cannot be created. Does not affect existing pods. See [Kubernetes documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/).
* **Uncordon** — mark a node as schedulable so that new pods can be created. See [Kubernetes documentation](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_uncordon/).
* **Halt** — pause the entire upgrade until manual intervention is carried out.
* **Skip** — continue the upgrade, bypassing one or several nodes.
* **Force** — perform the upgrade regardless of circumstances.

A **batch** is a group of worker nodes that are simultaneously upgraded.

### Parameters

The **Minor versions** tab contains the following parameters:

* **Status** — displays the actuality of the Kubernetes version:
  * `Latest version` — the cluster has the newest available version
  * `Upgrade available` — a newer version is available for upgrade
  * `Failed` — the last upgrade was not completed; manual action is likely needed
  * `Upgrading` — the cluster is currently being upgraded
* **Initial check** — displays whether the cluster is ready for upgrade (nodes are reachable and no deprecated APIs are in use):
  * **Check** button — initiates the check process
  * **Result** — displays the check result: `Passed`, `Failed`, or `Not checked`
* **Current version** — Kubernetes version currently running on the cluster
* **Target version** — the version the cluster will be on after the upgrade
* **Upgrade strategy**:
  * `drain_haltupgrade` — try `kubectl drain` for up to 30 minutes; if pods cannot be evicted, keep the node cordoned and pause the entire upgrade until manual intervention
  * `drain_skipnode` — try `kubectl drain` for up to 30 minutes; if pods cannot be evicted, uncordon, skip, and continue with the cluster upgrade
  * `drain_forceupgrade` — try `kubectl drain` for up to 30 minutes; if pods cannot be evicted, stop draining and force the upgrade (pod restart, package update) even if pods remain
  * `forceupgrade` — perform package updates and restart kubelet without draining pods
* **Batch size** — the number of worker nodes to be simultaneously upgraded
* **Batch delay** — the time interval before taking a new batch

### Getting started

To begin the upgrade using your specified settings, click the **Upgrade** button on the **Upgrade Settings** page under the **Minor Versions** tab. The process follows these steps:

1. Verification of version compatibility (you will be informed if there are any issues).
2. The cluster receives **Upgrading** status and the upgrade starts on the control plane.
3. Worker nodes are upgraded in batches. Each node receives **Upgrading** status and returns to **Active** only once the process is fully complete.
4. Once the last node has been upgraded, the cluster version is updated to the new one.

### Skip node via annotation

You can use a cluster-side annotation to specify whether a worker node should be skipped during the upgrade. Assign the `servers.com/upgrade-strategy=skipnode` annotation to the node object:

```yaml
apiVersion: v1
kind: Node
metadata:
  name: worker-node-01
  annotations:
    servers.com/upgrade-strategy: skipnode
```

### Limitations

* A cluster is non-operational during the upgrade process and the process cannot be suspended.
* Downgrade to a lower version is not possible.

## Patch versions

Before starting a patch version upgrade, make sure your cluster meets the following requirements:

* The cluster has **Active** status
* The Servers.com SSH keys on worker nodes have not been deleted

The patch version upgrade always targets the latest available patch within the current minor version. For example, if you have `1.32.1` and the latest is `1.32.7`, you will get `1.32.7` after a single upgrade operation.

### Parameters

The **Patch versions** tab contains the following parameters:

* **Current version** — Kubernetes version currently running on the cluster
* **Target version** — the version the cluster will be on after the upgrade
* **Automatically upgrade** checkbox — once enabled, allows setting a **Maintenance frequency**:
  * `Anytime` — upgrade can be performed at any time
  * `On selected days` — select specific weekdays and a time slot
  * `Daily` — upgrade can be performed every day within the selected time window

### Getting started

There are two options to start a patch version upgrade:

* **Manual** (starts immediately) — click **Force upgrade**
* **Automatic** (starts at a specified time slot) — enable **Automatically upgrade** → set **Maintenance frequency** → click **Save**

The automatic upgrade procedure is as follows:

1. You will be notified about the upcoming upgrade by email.
2. When the upgrade begins, the cluster assumes **Upgrading** status and becomes temporarily unavailable.
3. Control plane nodes are upgraded one by one; worker nodes are upgraded in groups of up to 10 servers per group.

If the upgrade exceeds the maintenance window, it will be paused and the cluster will return to **Active** status. The Kubernetes version will remain unchanged. The upgrade resumes in the next available time slot and the version is updated only after the last worker node has been upgraded.

### Limitations

* A cluster is non-operational during the upgrade process and the process cannot be suspended.
* Downgrade to a lower version is not possible.


# Version support policy (/docs/managed-kubernetes/version-support-policy)



The Kubernetes service is provided on a managed basis, which means the software needs to stay up to date. Once a Kubernetes version is no longer supported, service reliability can no longer be guaranteed. This policy is intended to explain and set clear timelines for a Kubernetes minor version lifecycle.

## Key terms

A **managed Kubernetes cluster** is one where the control plane is supported, maintained, and monitored, and automation is provided by Servers.com. You manage only worker nodes.

A **self-managed Kubernetes cluster** is one where you support and maintain both the control plane and worker nodes, without Servers.com automation or monitoring.

A **supported version** is a minor version within its active support window that receives regular patch releases. Kubernetes supports only the three most recent minor versions.

A **maintenance period version** is a minor version that has passed its standard support period but hasn't reached end-of-life yet. This gives you time to upgrade, and only critical security fixes may still be released.

An **end-of-life (EOL) version** is a minor version for which all support and maintenance has expired. It no longer receives patch releases, security updates, or bug fixes. You can find the full list of EOL versions in the [Kubernetes documentation](https://kubernetes.io/releases/#end-of-life-releases).

An **automatic forced upgrade** is an upgrade performed automatically if you didn't upgrade your cluster in time.

A **forced upgrade date** is the day when an automatic forced upgrade will be performed.

**Conversion to self-managed** is the process when your cluster moves from a managed to a self-managed service.

## Overview

Servers.com follows Kubernetes version releases and monitors clusters so that they are upgraded in time. Once a version reaches end-of-life, it's no longer available for creating new clusters and existing clusters must undergo an upgrade.

You'll receive notifications about upcoming events and are expected to upgrade your cluster within the maintenance period. If a version isn't upgraded in time, the upgrade will be performed automatically. Clusters that can't be safely upgraded will be converted to self-managed. All events are preceded by advance notifications.

<Callout type="warn">
  The best outcome is when 

  **you upgrade your clusters yourself**

  , without waiting for an automatic upgrade.
</Callout>

## Lifecycle

The version support policy runs automatically and includes the following stages:

* Notification when a maintenance period starts
* Notification when a maintenance period ends
* Notifications about an upcoming automatic forced upgrade (30 days and 3 days before the date)
* Automatic forced upgrade
* Notification about conversion to self-managed
* Conversion to self-managed

**Lifespan timeline** (counting from the version release):

* Supported version: 0–12 months
* Maintenance period: 12–14 months
* End-of-life: 14+ months
* Forced upgrade: 16 months
* Conversion to self-managed: 18 months

### Automatic forced upgrade

If your cluster wasn't upgraded to a newer version before the deadline, a minor version upgrade will be performed automatically. To make this process as smooth and safe as possible, two checks are in place:

* **Upgrade possibility check** - the system verifies that the version jump is valid and that there are no deprecated APIs. If any issues are found, the upgrade won't proceed.
* **Safe upgrade strategy** - the upgrade runs in the safest way possible:
  * Pods are drained where possible, but can restart if eviction isn't available.
  * Skipnode annotations are respected.
  * The upgrade pauses if your intervention is needed.

<Callout type="warn">
  The maintenance window guarantees the 

  *start time*

  , not the 

  *completion time*

  .
</Callout>

The forced upgrade runs in the time slot you set in **Upgrade settings**. It continues until a safe stopping point, even if that goes beyond the allowed window. If it doesn't finish, it will resume in the next allowed time slot. If no slot is set, upgrade times for all clusters on your account will be spread across the day.

Some upgrades require several version jumps (for example: `1.30` → `1.31` → `1.32` → `1.33` → `1.34`):

* After each upgrade, the system checks whether the forced upgrade date for the new version has already passed.
* If it has, the next upgrade starts immediately.
* If not, the next upgrade will be scheduled for later.

### Conversion to self-managed

This happens when an automatic forced upgrade wasn't completed in time or can't be performed. This enforcement is mostly applied to legacy versions that can't be safely upgraded. **Conversion to self-managed does not cause any downtime** - your existing nodes and workloads are preserved.

Here's what changes for you:

* Your cluster nodes become regular cloud and dedicated servers.
* Billing switches from Managed Kubernetes to regular cloud and dedicated servers.
* You receive SSH keys for the control plane and worker nodes, plus an admin kubeconfig.
* Automatic node creation/removal, automatic upgrades, and automatic cloud controller manager/ingress controller management are all disabled. Existing ones will keep working, and Load Balancers will remain.

<Callout type="warn">
  Versions 

  `1.19`

   and 

  `1.24`

   are not compatible with the upgrade mechanism, so clusters on these versions are converted to self-managed by default, without a forced upgrade attempt.
</Callout>

## Limitations

* Automatic forced upgrades are not possible if your cluster has deprecated APIs or incompatible versions.
* **Conversion to self-managed is irreversible.** Once completed, the only way to have a managed cluster again is to order a new one.

## Changelog

Refer to [Kubernetes releases](https://kubernetes.io/releases/) to see changelog between versions.


# CLI (srvctl) (/docs/platforms/cli)



`srvctl` is the open-source command-line tool for Servers.com. It is built on the Public API and lets you create, inspect, and manage your infrastructure without leaving the terminal — including dedicated servers, cloud instances, load balancers, networking, and more.

The source code is available on [GitHub](https://github.com/serverscom/srvctl).

### Use cases

* **Automation and scripting**: integrate infrastructure management into your CI/CD pipelines, shell scripts, or custom workflows.
* **Power-user workflows**: work faster by staying in the terminal and composing commands with familiar UNIX tools.
* **Programmatic access**: combine `srvctl` output (JSON or YAML) with tools like `jq` or `yq` to build lightweight automation without a full SDK.

### Key concepts

| Term              | Description                                                                                                                        |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| **Resource**      | An object you manage via the CLI, such as a dedicated server or load balancer.                                                     |
| **Command**       | An operation performed on a resource, such as `add`, `get`, or `delete`.                                                           |
| **Option / flag** | Additional arguments that modify a command. A flag stands alone (e.g., `-f`); an option carries a value (e.g., `--output=json`).   |
| **Context**       | A named set of credentials and configuration for one account or API token. Multiple contexts allow you to switch between accounts. |
| **Configuration** | A YAML file that stores your contexts and global settings.                                                                         |

### Installation

#### macOS

```bash
brew tap serverscom/serverscom
brew install srvctl
```

#### Linux

1. Download the archive for your architecture from [GitHub releases](https://github.com/serverscom/srvctl/releases). For example, `srvctl_0.1.0_linux_amd64.zip` for Linux on AMD64.

2. Extract and make the binary executable:

```bash
unzip srvctl_*_linux_amd64.zip
chmod +x srvctl
```

3. Move `srvctl` to a directory on your `PATH` (e.g., `/usr/local/bin`) or add its directory to `~/.bashrc`:

```bash
export PATH=/path/to/srvctl/folder:$PATH
source ~/.bashrc
```

#### Windows

1. Download the archive for your architecture from [GitHub releases](https://github.com/serverscom/srvctl/releases).
2. Extract the archive.
3. Run the `srvctl.exe` executable.

### Getting started

1. Generate a Public API token in the [API Tokens](https://portal.servers.com/iam/api-tokens) section of the Customer Portal.

2. Log in to create your first context:

```bash
srvctl login my-account
```

You will be prompted for the API token. The new context is set as default automatically.

3. Verify the context was created:

```bash
srvctl context list
```

4. Explore available resources and commands using the built-in help:

```bash
srvctl --help
srvctl <resource> --help
srvctl <resource> <command> --help
```

### Command structure

All commands follow the same pattern:

```
srvctl <resource> <command> [<options>]
```

Standard commands available on most resources:

| Command       | Description                     | Example                                          |
| ------------- | ------------------------------- | ------------------------------------------------ |
| `list` / `ls` | List resources                  | `srvctl hosts list`                              |
| `add`         | Create a new resource           | `srvctl ssh-keys add --input ssh-key.json`       |
| `get`         | Get details of a resource by ID | `srvctl hosts ebm get <id>`                      |
| `update`      | Update a resource by ID         | `srvctl ssh-keys update <fingerprint> -n <name>` |
| `delete`      | Remove a resource by ID         | `srvctl ssh-keys delete <fingerprint>`           |

Sub-resource commands follow the pattern `list-<subresource>`, `get-<subresource>`, and so on. For example:

```bash
srvctl hosts ebm list-connections <id>
srvctl hosts ebm list-networks <id>
```

### Global flags

These flags are available on every command:

| Flag           | Alias | Description                                        |
| -------------- | ----- | -------------------------------------------------- |
| `--all`        | `-A`  | Fetch all pages of results                         |
| `--output`     | `-o`  | Output format: `text` (default), `json`, or `yaml` |
| `--no-header`  |       | Suppress column headers in text output             |
| `--field`      | `-f`  | Limit output to specific fields: `-f ID -f Status` |
| `--field-list` |       | List available fields for the current resource     |
| `--verbose`    | `-v`  | Show the full HTTP request and response            |
| `--config`     | `-c`  | Path to a custom configuration file                |

### Creating resources with JSON input

Resources such as dedicated servers, load balancers, and L2 segments are created using a JSON file that mirrors the Public API request body. The `add` command provides a template link when you run it without input.

```bash
srvctl hosts ebm add --input dedicated-server.json
```

Example `ssh-key.json`:

```json
{
  "name": "my-key",
  "public_key": "ssh-rsa AAAA..."
}
```

### Configuration file

The default configuration path is `$HOME/.config/srvctl/config.yaml`. You can override it with the `SRVCTL_CONFIG_PATH` environment variable or the `--config` flag.

Example configuration:

```yaml
globalConfig:
  http-timeout: 30
  output: text
defaultContext: default
contexts:
  - name: default
    endpoint: https://api.servers.com/v1
    token: <your-api-token>
    config:
      verbose: false
  - name: staging
    endpoint: https://api.servers.com/v1
    token: <staging-api-token>
```

Settings are resolved in order of increasing priority:

1. **Global config** — applied to all contexts unless overridden.
2. **Context config** — overrides global config for the active context.
3. **Command-line flags** — override everything for the current command.

To update configuration without editing the file:

```bash
srvctl --http-timeout 60 config global update
srvctl --output json config context update
```

### Context management

| Command                                  | Description                                           |
| ---------------------------------------- | ----------------------------------------------------- |
| `srvctl login <name>`                    | Create a new context and authenticate                 |
| `srvctl context list`                    | List all contexts                                     |
| `srvctl context update <name> --default` | Set a context as default                              |
| `srvctl context delete <name>`           | Delete a context (`--force` required for the default) |

### Available resources

| Resource             | CLI command                        | Description                                      |
| -------------------- | ---------------------------------- | ------------------------------------------------ |
| Account balance      | `srvctl account balance`           | View current account balance                     |
| Hosts (all types)    | `srvctl hosts list`                | List all servers across types                    |
| Dedicated servers    | `srvctl hosts ebm <command>`       | Manage dedicated (enterprise bare metal) servers |
| Scalable Bare Metal  | `srvctl hosts sbm <command>`       | Manage SBM servers                               |
| Invoices             | `srvctl invoices <command>`        | View and retrieve invoices                       |
| SSH keys             | `srvctl ssh-keys <command>`        | Manage SSH keys                                  |
| Locations            | `srvctl locations <command>`       | List and inspect locations                       |
| Server models        | `srvctl server-models <command>`   | Browse available server models                   |
| Racks                | `srvctl racks <command>`           | Manage private racks                             |
| SSL certificates     | `srvctl ssl <command>`             | Manage custom and Let's Encrypt certificates     |
| L2 segments          | `srvctl l2-segments <command>`     | Manage private L2 network segments               |
| Kubernetes clusters  | `srvctl k8s <command>`             | Manage Kubernetes clusters                       |
| Load balancers       | `srvctl lb <l4\|l7> <command>`     | Manage L4 and L7 load balancers                  |
| Network pools        | `srvctl network-pools <command>`   | Manage network pools and subnets                 |
| Remote Block Storage | `srvctl rbs <command>`             | Manage RBS volumes                               |
| Cloud instances      | `srvctl cloud-instances <command>` | Manage cloud computing instances                 |
| Cloud regions        | `srvctl cloud-regions <command>`   | Browse regions, images, flavors, snapshots       |
| Cloud volumes        | `srvctl cloud-volumes <command>`   | Manage cloud block storage volumes               |
| Cloud backups        | `srvctl cloud-backups <command>`   | Manage cloud volume backups                      |


# Customer Portal (/docs/platforms/customer-portal)













The Customer Portal is a web interface to manage your Servers.com resources and services. This article guides you through the main elements that you may navigate while using the portal. We are constantly improving and updating our customer portal. Because of this, whilst screenshots provided in this article are provided to aid understanding, they may differ slightly from our current portal interface.

**The left-side menu** allows you to navigate through all services, billing and account settings.

<img alt="portal's left side menu" src={__img0} title="The left-side menu" />

**The top-right menu** lets you switch between accounts and reach your account and user settings instantly.

<img alt="portal's top right menu" src={__img1} title="The top-right menu" />

The search bar allows you to search through all your Servers.com resources and instantly get access to them.

A **color theme** is a palette of your user interface. You can choose between two color themes for your user interface:

* Light mode
* Dark mode

There is also a system mode that sets a theme in accordance with your operating system settings. The feature can be managed by clicking the **Change color theme** icon in the top-right corner.

<img alt="change color theme" src={__img2} title="Change color theme" />

When you make an order your products are sent to a cart, where they are stored before purchase. You can reach your cart by clicking the cart icon on the top-right.

<img alt="portal's cart option" src={__img3} title="Cart option" />

The dashboard is the main Customer Portal page and contains basic information about:

* Balance: current balance and estimated balance for the beginning of the next billing period
* Invoices: a list of unpaid invoices
* Latest requests: a list of requests starting with the most recent activity

<img alt="customer portal dashboard" src={__img4} title="Customer Portal dashboard" />

The **I trust this computer** flag will appear when entering your two factor authentication (2FA) token during login. If you do not want to go through 2FA every time you log in to your account, select this option. However, if a session is logged out manually, it is necessary to go through 2FA again.

A **dangerous action** is an operation that may significantly impact on a service or lead to irreversible changes.


# Platforms (/docs/platforms)



**Servers.com Platforms** covers the management tools for your infrastructure — the Customer Portal for everyday operations, the Public API for automation and integrations, the Terraform provider for infrastructure-as-code, and Labels for organizing resources across your account.

<DocCards>
  <DocCard title="Customer Portal" description="Navigate the web UI, dashboard, cart, and account settings." href="/platforms/customer-portal/" />

  <DocCard title="Public API" description="Automate operations and integrate Servers.com via the RESTful API." href="/platforms/public-api/" />

  <DocCard title="Terraform Provider" description="Manage Servers.com infrastructure as code using Terraform." href="/platforms/terraform-provider/" />

  <DocCard title="Labels" description="Organize and filter your resources using custom key-value labels." href="/platforms/labels/" />
</DocCards>


# Labels (/docs/platforms/labels)



A **label** is a key-value pair assigned to a resource. Resources that support labels include dedicated servers, firewalls, load balancer instances, and Kubernetes clusters. Labels allow you to group resources and retrieve them based on specific criteria, and can be managed via the public API.

### Pattern

A label consists of a key and a value:

```
"<key>": "<value>"
```

A key can be specified in two ways:

1. `"<prefix>/<name>": "<value>"` — with an optional prefix that enables a two-level hierarchy
2. `"<name>": "<value>"` — without a prefix

The `<prefix>` segment is optional and helps organize labels into logical namespaces.

### Limitations

* A resource can have several labels, but each key must be unique within that resource
* Each resource can have up to 64 labels
* The `servers.com/` prefix is reserved and not allowed to be used

### Use cases

Labels allow resources to be placed together under logical categories. The following examples show how labels can work in practice.

### Separate infrastructure between testing and production environments

To distinguish between testing and production servers in a simple infrastructure:

```
"environment": "production"
"environment": "testing"
```

### Independent applications within one Servers.com account

For two independent applications (`app1` and `app2`) with servers distributed between frontend and backend teams:

```
"app1/backend": "production"
"app1/frontend": "production"
"app1/backend": "testing"
"app1/frontend": "testing"
"app2/backend": "production"
"app2/frontend": "production"
"app2/backend": "testing"
"app2/frontend": "testing"
```

### Purpose-based differentiation

For a complex infrastructure with different groups of servers working towards a shared purpose:

```
"purpose": "billing"
"purpose": "core"
"purpose": "database"
```

### Management

Labels can be assigned to a resource during creation or at any other point in its lifecycle. The following operations are available:

* Create a new label
* Update an existing label
* Delete an existing label
* Retrieve a resource by label

To learn how to manage labels via the public API, refer to the [public API documentation](https://developers.servers.com/api-documentation/v1/#section/Labels).


# Operating systems (/docs/platforms/operating-systems)



Servers.com allows you to select an operating system that will be automatically installed and configured on your server. You can get the most up-to-date list of available operating systems when ordering a cloud or dedicated server in the Customer Portal.

### Concepts

An **operating system** (OS) is basic software installed on a server during provisioning to manage hardware resources and allow other programs to run. When working with cloud servers, the operating system is referred to as an **image**.

An **OS family** is a group of operating systems sharing common principles and core components. There are two main OS families: Linux and Windows.

An **OS distribution** (distro) is a particular operating system within an OS family.

Operating systems can also be classified by how updates are delivered:

* **Rolling release** — updates are delivered continuously as soon as they are ready. The OS always has the latest software but may be less stable.
* **Standard release** — changes are collected into a single major update released on a schedule. This provides more stability but may delay access to the latest software.

### Use cases

### AlmaLinux

AlmaLinux is a free, community-driven operating system designed as a CentOS replacement. It provides enterprise stability and binary compatibility with Red Hat Enterprise Linux (RHEL), and offers 10 years of security support per major version.

Use cases: web servers, enterprise applications, hosting control panels, database servers.

### CentOS Stream

CentOS Stream is a rolling-release distribution positioned between Fedora and RHEL. Updates flow from Fedora to CentOS Stream and then land in RHEL, making CentOS Stream a preview of future RHEL versions.

Use cases: pre-production testing, development targeting RHEL ecosystems, continuous integration setups.

### Debian

Debian is a community-driven Linux distribution and the foundation of Ubuntu. It is known for a conservative approach to updates and is preferred in environments where stability, predictability, and uptime matter more than having the latest software versions.

Use cases: production servers, long-lived systems, research clusters, critical infrastructure.

### Rocky Linux

Rocky Linux was founded by the original creator of CentOS and shares a similar philosophy with AlmaLinux — stable, production-ready, and with long-term support. Some users prefer Rocky Linux for its CentOS heritage and community-first focus.

Use cases: enterprise servers, hosting, RHEL-compatible applications.

### Ubuntu

Ubuntu is a Debian-based operating system by Canonical that offers a more user-friendly experience and newer packages. Its large ecosystem and broad community support make it popular for cloud deployments and development environments.

Use cases: cloud servers, container hosts (Docker/Kubernetes), general-purpose Linux systems.

### Windows Server

Windows Server is Microsoft's server operating system designed to run enterprise applications, directory services, file services, and workloads built on the Microsoft ecosystem. Servers.com offers the Standard and Datacenter editions.

Use cases:

* **Microsoft stack integration** — ideal for extending infrastructure into the cloud with tight integration with Active Directory, Group Policies, Exchange Server, and .NET applications.
* **Remote desktop infrastructure** — Windows Server's graphical environment makes it straightforward to provide remote app access or full desktop sessions to employees.
* **SQL Server** — while SQL Server has supported Linux since 2017, some advanced features are only available or better supported on Windows. Many third-party management, monitoring, and compliance tools also assume a Windows Server platform.

### No operating system

Servers.com allows you to order a server without any operating system. In this case, you can reach the server via an out-of-band (OOB) connection and set it up according to your needs.

Use cases: custom projects.


# Public API (/docs/platforms/public-api)



Public API is another way to manage Servers.com resources built upon the RESTful architecture. It gives you an opportunity to automate manual operations and programmatically integrate Servers.com into your infrastructure.

You can learn more in the Public API documentation, in the [API tokens](https://portal.servers.com/iam/api-tokens) section of the Customer Portal.

Public API terms of use are available in the [legal section](https://www.servers.com/company/legal/public-api-terms-of-use) of the Servers.com website.

### Use case

During periods of peak user activity, you may need additional capacity to process increasing workloads. You can set up monitoring on your side to detect when your existing infrastructure is approaching its resource limits. Once this happens, the monitoring will trigger an order of Servers.com Scalable Bare Metal (SBM) servers to meet hardware requirements. When peak activity has dropped, you can set up a trigger to remove the SBM servers.


# Terraform provider (/docs/platforms/terraform-provider)



Terraform is an open-source infrastructure-as-code software built on the Servers.com Public API. This tool allows you to manage your hardware infrastructure as code and carry out practices like descriptive coding and versioning.

### Concepts

Below are some basic concepts that you will encounter when using Terraform.

1. **Terraform provider**: a module to manage the services of a certain vendor. Servers.com has its own provider as well.
2. **Resource**: an object on which an operation is performed. It can be a server, load balancer or any other standalone service.
3. **Data source**: an entity to fetch data outside of the current Terraform configuration. For example, data about network pools.

We recommend you start by getting acquainted with our [Terraform documentation](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs).

### Authentication

Servers.com Terraform providers use the Public API token as a means of authentication. You can get one in the [API Tokens page](https://portal.servers.com/iam/api-tokens) within the Customer Portal.

### Use case

You plan to roll out a new version of your application that requires another hardware setup. In this case, you can also apply versioning to your infrastructure and describe hardware configurations for both the current and new application versions.

### Getting started

To get started, follow the guides provided in [Terraform’s official documentation](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs).

The **Use Provider** button in the top-right corner explains how to use the Servers.com Terraform provider.


# Billing (/docs/rbs/billing)



The price of the Servers.com Remote Block Storage depends on two main parameters:

* type (a flavor that consists of the IOPS and bandwidth characteristics)
* volume size

The service is billed per GB of the volume size at a price rate defined by its type. The billing period is a calendar month. Changing volume size is recalculated proportionally.

### Cancellation terms

If the service is canceled before a billing period is over, it will be charged at the full month price.


# Concepts (/docs/rbs/concepts)



**Remote Block Storage** is a high-performance, scalable, and resilient storage solution designed for modern enterprise environments. It provides virtual block devices that are perfect for databases, virtual machines, and high-throughput applications.
Remote Block Storage delivers enterprise-grade performance with the flexibility of cloud-native architecture.

With built-in redundancy and self-healing capabilities, Remote Block Storage ensures data integrity and fault tolerance, making it ideal for mission-critical workloads. Its dynamic scalability allows businesses to expand their storage infrastructure effortlessly while optimizing performance and cost efficiency.

The Servers.com Remote Block Storage (RBS) is a scalable and multi-tenant solution running on Ceph and communicating with your hosts by the iSCSI protocol. This service is compatible with Servers.com Enterprise Bare Metal servers, Scalable Bare Metal servers, Cloud Servers, and Kubernetes nodes.

A **volume** is a block storage device at your disposal that you can mount to your hosts. Each volume consists of the following characteristics:

* Size = disk space at your disposal
* The maximum IOPS value (input/output operations per second) is the maximum number of read and write operations performed by the disk per second
* The maximum bandwidth is the total number of bytes that can be read from or written to the disk per second.

The service is **flavor-based** by uniting IOPS and bandwidth characteristics into types. Each volume is assigned with a private IP address. This address is called a **Volume IP address**.

For best performance, Remote Block Storage volumes should be used with 4KB block sizes, as the underlying storage is optimized for 4KB-aligned I/O operations.

### Use case

Remote Block Storage can be integrated with your Servers.com Kubernetes cluster covering needs in a persistent storage solution. Thus, you can keep unimportant information within a local storage on a Kubernetes node and let RBS to store your vital data.


# Getting started (/docs/rbs/getting-started)



Remote Block Storage (RBS) are external block-level storage volumes that can be mounted to Enterprise Bare Metal servers, Scalable Bare Metal servers, Cloud Servers, or Kubernetes nodes.
This section outlines how to create and initialize a new RBS volume.
To create a new RBS volume:

1. Log in to the Customer Portal and navigate to **Remote Block Storage**
2. Click **Order**
3. Select the storage location
4. Choose a type of flavor
5. Specify the desired volume size in gigabytes
   * IOPS (Input/Output Operations Per Second) and bandwidth will be calculated automatically based on the selected size
6. Enter a name for the volume
7. Click **Order** to complete the request

The system will begin provisioning the volume. Once completed, the volume will be available for use.

## Connection configuration

### Linux

To connect a volume to a Linux server, follow the steps below. Run all commands as `root` (or with `sudo`).

#### Step 1: install the Internet Small Computer System Interface (iSCSI) package (if not done already)

* Debian-based OS (Ubuntu, Debian)

```
apt install open-iscsi
```

The target configuration path is: `/etc/iscsi/nodes`

* RedHat-based OS (Rocky Linux, Alma Linux, CentOS)

```
yum install iscsi-initiator-utils
```

The target configuration path is: `/var/lib/iscsi/nodes`

The target configuration path stores connection details for each discovered iSCSI target and supports automatic reconnection after reboot. If issues occur during login or reconfiguration, you can manually inspect or remove entries in this directory.

#### Step 2: register the target volume

Take the target name and the volume IP address from the volume details page: **Customer Portal** → **Remote Block Storage** → Your volume. You will need two fields:

* **Target name** - the IQN (iSCSI Qualified Name) that uniquely identifies the volume, for example: `iqn.2024-10.com.servers:59809d6c-6ec7-4220-b334-9c93ed8f52b4`
* **IP address** - the iSCSI volume IP address

Create a node record for the target:

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o new
```

Replace `<Target name>` and `<Volume IP>` with the values from the **Target name** and **IP address** fields on the volume details page.

#### Step 3: configure authentication

Configure CHAP authentication parameters, by setting up a username and password:

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o update -n node.session.auth.username -v <Username>
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o update -n node.session.auth.password -v <Password>
```

Replace `<Username>` and `<Password>` parameters with credentials from **Remote Block** **Storage** → Your volume → **Credentials** → Click the **Show** button.
Enable auto-start for this connection (optional):

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o update -n node.startup -v automatic
```

#### Step 4: Configure queue depth

By default, the Linux iSCSI initiator exposes a low queue depth on the SCSI device, which can limit performance for volumes with high IOPS limits.

To increase the queue depth, update the node session parameters before you log in:

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o update -n node.session.cmds_max -v 256
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o update -n node.session.queue_depth -v 128
```

`node.session.cmds_max` must be a power of two and must be at least twice the target `node.session.queue_depth`.
For example, to set a queue depth of 128 on the SCSI device, set `cmds_max` to 256.

If the session is already active, log out and log back in for the changes to take effect.

#### Step 5: log in to the target volume

Log in to the target volume:

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 --login
```

After completing the login, a new block storage device will appear in the `/dev` directory, typically named in the `sdX` format (e.g., `sdc`). To identify `<Device name>`, use the `lsblk` command.

#### Step 6: prepare the storage device

Format the new block storage device, create a file system (`ext4` in our example) and mount it to a local directory such as `/mnt/iscsi`:

```
mkfs.ext4 -E lazy_itable_init=1 -E lazy_journal_init=1 /dev/<Device name>
mkdir /mnt/iscsi
mount /dev/<Device name> /mnt/iscsi
```

Replace `<Device name>` with the actual device name from the previous step.

#### Step 7: set up auto-mounting after reboot (optional)

* Get the UUID of the file system:

```
lsblk -f
```

* Set up automatic mounting:

```
echo "UUID=<UUID value> /mnt/iscsi ext4 _netdev 0 0" | tee --append /etc/fstab
```

`<UUID value>` is the UUID of a file system from the previous request

Remote Block Storage has been set up.

### Windows

To connect a volume to a Windows server, follow the steps below. Run all commands in an elevated PowerShell session.

#### Step 1: configure the iSCSI service

##### Using PowerShell

1. Set the **Microsoft iSCSI Initiator Service** to start automatically and start it:

```
Set-Service -Name MSiSCSI -StartupType Automatic
Start-Service -Name MSiSCSI
```

2. Add the target portal, binding it to your Global Private Network interface:

```
New-IscsiTargetPortal -TargetPortalAddress <Volume IP> -InitiatorPortalAddress <GPN interface IP>
```

`<Volume IP>` is the volume's IP address from the volume details page: **Customer Portal** → **Remote Block Storage** → Your volume → **IP address**.
`<GPN interface IP>` is a Global Private Network IP address assigned to an interface of your server, found on your server's detail page (**Private IP**).

3. Confirm the target was discovered and note its **NodeAddress** (the target IQN), which you need in Step 2:

```
Get-IscsiTarget
```

##### Using the GUI

1. Make sure the iSCSI service is set to run automatically:

* Open the **Microsoft Management Console** by typing `services.msc` in the Start menu
* Locate **Microsoft iSCSI Initiator Service**, right-click → **Properties**
* Set **Startup type** to **Automatic**

2. Open the **iSCSI Initiator** by typing `iscsicpl` in the Start menu
3. In the **iSCSI Initiator Properties** window, switch to the **Discovery** tab and click **Discover Portal**
4. In the **Discover Target Portal** dialog, set the following:

* **IP address or DNS name**: `<Volume IP>`
* **Port**: `3260`
  `<Volume IP>` is the volume's IP address from the volume details page: **Customer Portal** → **Remote Block Storage** → Your volume → **IP address**

5. Click **Advanced** and set the following:

* **Local adapter**: **Microsoft iSCSI Initiator**
* **Initiator IP**: `<GPN interface IP>`

`<GPN interface IP>` is a Global Private Network IP address assigned to an interface of your server. Find it on your server's detail page (**Private IP**).

6. Click **OK** to close **Advanced Settings**, then **OK** to add the portal. It now appears under **Target portals** on the **Discovery** tab.
7. Switch to the **Targets** tab. The volume appears under **Discovered targets** with the **Inactive** status.

#### Step 2: connect to the volume

Connect to the target with CHAP authentication, binding it to your Global Private Network interface and keeping the connection persistent across reboots.

##### Using PowerShell

```
Connect-IscsiTarget -NodeAddress <Target name> -TargetPortalAddress <Volume IP> -InitiatorPortalAddress <GPN interface IP> -AuthenticationType ONEWAYCHAP -ChapUsername <Username> -ChapSecret <Password> -IsPersistent $true
```

Replace `<Target name>` with the target IQN (the **NodeAddress** returned by `Get-IscsiTarget`, or the **Target name** field on the volume details page). Find `<Username>` and `<Password>` on the volume details page: **Remote Block Storage** → Your volume → **Credentials** → **Show**.

##### Using the GUI

1. On the **Targets** tab, select the discovered target and click **Connect**
2. In the **Connect To Target** dialog, keep **Add this connection to the list of Favorite Targets** selected so the connection is restored automatically after every reboot, then click **Advanced**
3. In the **Advanced Settings** dialog, set the following:

* **Local adapter**: **Microsoft iSCSI Initiator**
* **Initiator IP**: `<GPN interface IP>`
* **Target portal IP**: `<Volume IP> / 3260`
* Select the **Enable CHAP log on** checkbox
* **Name**: `<Username>`
* **Target secret**: `<Password>`

You can find `<Username>` and `<Password>` on the volume details page: **Remote Block Storage** → Your volume → **Credentials** → **Show**

4. Click **OK** to close **Advanced Settings**, then **OK** in the **Connect To Target** dialog. The target's status changes to **Connected** on the **Targets** tab.

#### Step 3: initialize the disk

##### Using PowerShell

```
$RBSDisk = Get-Disk | Where-Object PartitionStyle -eq 'RAW'
$RBSDisk | Set-Disk -IsOffline:$false
$RBSDisk | Initialize-Disk -PartitionStyle GPT -PassThru | New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -Confirm:$false
```

##### Using the GUI

1. Right-click Start → select **Disk Management**
2. Locate your iSCSI disk in the list

If the disk is marked **Offline,** that means Windows detects it but does not activate new external disks by default (this is a data protection feature)

3. Set the disk to online and initialize it:
   1. In **Disk Management**, locate the correct disk (e.g., Disk 2)
   2. Right-click on the left pane (not the "unallocated" area)
   3. In the context menu, select **Online**, then **Initialize Disk**

You can now create partitions, assign a label or drive letter, and format to NTFS.

### Kubernetes

To connect a volume to a Kubernetes cluster, follow the steps below.

#### Step 1: create a CHAP secret

Create a YAML file (e.g., `chap-secret.yaml`) and insert the following structure, adjusting it to your environment:

```
apiVersion: v1
kind: Secret
metadata:
  name: <CHAP secret name>
type: "kubernetes.io/iscsi-chap"
data:
  node.session.auth.username: <base64-username>
  node.session.auth.password: <base64-password>
```

Encode the credentials in base64 before pasting them into the file:

```
echo -n '<Username>' | base64
echo -n '<Password>' | base64
```

Replace:

* `<Username>` and `<Password>` with the values from the **Customer Portal** → **Remote Block Storage** → Your volume → **Credentials** → **Show**
* `<CHAP secret name>` with a name for the secret (e.g., `chap-secret`), which will be used later in the pod manifest

Apply the secret to the cluster:

```
kubectl apply -f chap-secret.yaml
```

If successful, you will see:

```
secret/chap-secret created
```

The CHAP secret is now ready to be referenced in your pod manifest.

#### Step 2: define a pod that mounts the block storage

Create a pod manifest file (e.g., `pod-manifest.yaml`) and use the following configuration as a base, adjusting it as needed:

```
apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
  - name: <Container name>
    image: <Image name>
    imagePullPolicy: IfNotPresent
    command: ["sleep", "3600"]
    volumeMounts:
    - mountPath: "/mnt/<Folder>"
      name: <Volume name>
  volumes:
  - name: <Volume name>
    iscsi:
      targetPortal: <Volume IP>
      iqn: <Target name>
      lun: 0
      fsType: <File system>
      readOnly: false
      chapAuthDiscovery: false
      chapAuthSession: true
      secretRef:
        name: <CHAP secret name>
```

Replace the placeholders with actual values:

* `<Pod name>` - name of the pod (e.g., `iscsi-demo-pod`)
* `<Container name>` - name of the container inside the pod
* `<Image name>` - container image name (e.g., `nginx`)
* `<Folder>` - subdirectory under `/mnt` to mount inside the container (e.g., `storage`)
* `<Volume name>` - volume name inside the pod
* `<Volume IP>` - IP address of the iSCSI target
* `<Target name>` - IQN of the target (e.g., `iqn.2024-10.com.servers:abc123`)
* `<File system>` - filesystem type (typically `ext4`)
* `<CHAP secret name>` - name of the CHAP secret object from the previous step

You can find `<Volume IP>` and `<Target name>` in the Customer Portal on the block storage details page.

Apply the configuration:

```
kubectl apply -f pod-manifest.yaml
```

If successful, you will see:

```
pod/iscsi-demo-pod created
```

## Storage verification

### Linux

1. Navigate to the mount point:

```
cd /mnt/iscsi
```

2. Create a test file:

```
nano /mnt/iscsi/test.txt
```

To save and close:

* Press **Ctrl + O** → then **Enter** (to save)
* Press **Ctrl + X** (to exit Nano)

3. Verify the created file and its content

```
cat /mnt/iscsi/test.txt
```

### Windows

##### Using PowerShell

1. Confirm the volume is available and note its drive letter:

```
Get-Volume
```

2. Write a test file to the volume and read it back (replace `<Drive letter>` with the letter assigned to the volume, for example `D`):

```
Set-Content -Path <Drive letter>:\test.txt -Value "Remote Block Storage test"
Get-Content -Path <Drive letter>:\test.txt
```

`Get-Content` returns `Remote Block Storage test`, confirming the volume is writable and readable.

##### Using the GUI

1. Open **File Explorer** and confirm the volume appears under **This PC**.
2. Open the volume, right-click an empty area → **New** → **Text Document**, and name the file `test.txt`.
3. Open `test.txt`, type some text, and save it (**Ctrl + S**).
4. Close and reopen the file to confirm the content was saved to the volume.

### Kubernetes

1. Confirm the pod is running:

```
kubectl get pods
```

2. Check container status:

```
kubectl get pod iscsi-demo-pod -o wide
```

Statuses:

* `Running` - container is successfully launched and the volume is mounted
* `ContainerCreating` - the pod is still initializing
* `CrashLoopBackOff` - check the container's command, logs, or volume errors. You can get more details using the `kubectl describe pod <Pod name>` command

3. Exec into the pod and check the mount:

```
kubectl exec -it iscsi-demo-pod -- sh
```

4. Once inside the pod:

```
ls /mnt/storage
```

If everything was set up correctly, you should see the contents of the mounted iSCSI volume.

## Disconnecting storage

### Linux

To safely disconnect and avoid data loss:

1. Identify mountpoints:

```
lsblk
```

Example output:

```
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sdc                        8:32   0    10G  0 disk  /mnt/storage
                                                        /mnth
```

2. Unmount all mountpoints:

```
sudo umount /mnt/storage
sudo umount /mnth
```

If the device is busy, check which processes are using it:

```
lsof /mnt/storage
```

End those processes or wait for any write operations to complete, then try unmounting again.

3. Disconnect from the iSCSI target:

* Check the current iSCSI session:

```
iscsiadm -m session
```

* Log out from the target:

```
sudo iscsiadm -m node -T <Target IQN> -p <Volume IP> --logout
```

* Remove the target record (optional):

```
iscsiadm -m node --targetname <Target name> -p <Volume IP>:3260 -o delete
```

4. Run `lsblk` again to ensure the block storage device is no longer listed

### Windows

To disconnect a volume from a Windows Dedicated Server, follow the steps below.

#### Step 1: take the volume offline via Disk Management

1. Open **Disk Management** (search for `diskmgmt.msc` in the Start menu)
2. Locate the disk associated with the iSCSI volume
3. Right-click on the volume or partition → select **Change Drive Letter and Paths...**
4. If a drive letter is assigned, remove it
5. In the left-hand panel (e.g., Disk 2), right-click the disk → choose **Offline**

#### Step 2: disconnect from the iSCSI target via iSCSI Initiator

1. Open **iSCSI Initiator** (search for `iscsicpl` in the Start menu)
2. In the **Targets** tab, locate the target with **Status: Connected**
3. Select it and click **Disconnect**
4. Confirm the action when prompted

#### Step 3: remove the target from configuration (optional)

1. Navigate to the **Favorite Targets** tab in iSCSI Initiator
2. Select the disconnected target and click **Remove**

This prevents Windows from automatically reconnecting to the target on startup.

### Kubernetes

#### Step 1: identify the node where the volume is mounted

Before deleting the pod, determine the node it runs on:

```
kubectl get pod <Pod name> -o wide
```

This will show something like:

```
NAME             READY   STATUS    RESTARTS   AGE   IP           NODE
iscsi-demo-pod   1/1     Running   0          1h    172.31.x.x   10.20.30.40
```

#### Step 2: log in to the worker node that mounted the volume via SSH

```
ssh <user>@<node IP>
```

#### Step 3: Log out from the iSCSI target

1. After connecting to the node, list active sessions:

```
sudo iscsiadm -m session
```

2. Disconnect the storage:

```
sudo iscsiadm -m node -T <Target IQN> -p <Volume IP> --logout
```

Replace `<Target IQN>` and `<Volume IP>` with actual values from the list of active sessions

3. Run the session list command again to make sure the storage was successfully disconnected

#### Step 4: delete the pod

This command must be executed from your workstation or any machine with kubectl access, not on the Kubernetes node.
Once logout is complete:

```
kubectl delete pod iscsi-demo-pod
```

#### Step 5: remove the CHAP secret (optional)

```
kubectl delete secret chap-secret
```


# Remote Block Storage (/docs/rbs)



**Remote Block Storage** gives your Enterprise Bare Metal servers, Scalable Bare Metal servers, Cloud Servers, and Kubernetes nodes iSCSI-attached block volumes built on Ceph - high-performance, self-healing storage you can provision and expand without touching hardware, with built-in redundancy and predictable IOPS.

<DocCards>
  <DocCard title="Concepts" description="Understand RBS architecture, volumes, flavors, and performance characteristics." href="/rbs/concepts/" />

  <DocCard title="Billing" description="See how Remote Block Storage pricing and billing work." href="/rbs/billing/" />
</DocCards>

<DocCards>
  <DocCard title="Getting Started" description="Provision and attach your first RBS volume to a server." href="/rbs/getting-started/" />
</DocCards>


# Limitations (/docs/rbs/limitations)



These are standard limitations and quotas for the service:

* A volume can be mounted only to one server at a time.
* Maximum volume size - 2 TB (up to 10 TB upon request)
* Maximum volumes per account - 99
* Total volumes size per account - 10 TB


# Getting started (/docs/sbm/getting-started)



To order a Scalable Bare Metal (SBM) server, complete the following steps:

1. Go to the [Customer Portal](https://portal.servers.com/login)
2. In the left-hand menu, navigate to **Scalable Bare Metal**
3. Click **Add server** and select the location
4. In the **Flavor** section, choose an available configuration from the list
5. Choose the operating system. Please note, Windows-based OS is unavailable for the Scalable Bare Metal service
6. Choose the authentication method, SSH key, quantity, and configuration name
7. To place an order, click **Order**
8. In the **My cart** section, review the order details and click the **Buy now** button

The selected configuration will be available after the provisioning procedure.


# Scalable Bare Metal (/docs/sbm)



**Scalable Bare Metal** gives you dedicated physical servers on an hourly, pay-as-you-go model - no virtualization, no shared resources, and full API provisioning so you can scale burst workloads, ML training, or dev/test environments on demand and release them when done.

<DocCards>
  <DocCard title="Overview" description="Understand the SBM service, available configurations, and billing model." href="/sbm/overview/" />

  <DocCard title="Getting Started" description="Provision and connect to your first Scalable Bare Metal server." href="/sbm/getting-started/" />
</DocCards>


# Overview (/docs/sbm/overview)



Scalable Bare Metal (SBM) is a separate service from dedicated servers, offering highly reliable servers with fixed configurations, hourly billing, and a unique operational model. This service combines the power of dedicated servers with the scalability of cloud solutions, allowing businesses to access powerful computing resources on demand without long-term commitments.

### Concepts

* **Hourly billing model**: pay only for actual usage, allowing for the cost-optimized management of unpredictable workloads, budget planning, and avoiding over-provisioning of resources.
* **Consistent performance**: complete control over hardware and applications with no intermediaries. Each server is exclusively yours, ensuring predictable performance and eliminating the issue of "noisy neighbors".
* **Efficient infrastructure management**: use our API to automate and optimize deployment, scaling, and management of your bare metal servers, seamlessly integrating with existing DevOps tools and processes.

### Use cases

* Businesses can quickly scale their server capacity to handle sudden traffic spikes without long-term commitments.
* Developers can deploy servers as needed for testing purposes.
* Researchers and data scientists can access high-performance servers for intensive computational tasks, such as training machine learning models or large language models, without incurring unnecessary long-term costs.

### Available features

* Operating system installation (excluding Windows)
* VNC console support
* Ability to add a server to an L2 Segment
* [Public API management](https://developers.servers.com/api-documentation/v1/#tag/Scalable-Baremetal-Server)

### Limitations

* The default quota allows for up to 5 servers of a specific SBM configuration per account
* The default quota allows for up to 10 different Scalable Bare Metal configurations in total per account
* SBM can't be used in Firewall, Managed Kubernetes and Load Balancer

### Billing

The Scalable Bare Metal service is offered on a post-paid, hourly billing model. Your account balance must cover the previous billing period and include enough funds to operate each server for an additional 12 hours.

There is no traffic commitment: you pay per-GB. All billing services related to Scalable Bare Metal are billed hourly, including the minutes when the service starts and ends.


# Tutorials (/docs/tutorials)



Step-by-step guides for common tasks on Servers.com dedicated servers and infrastructure. Whether you're setting up remote access, securing your server, managing storage, or recovering from failures, you'll find practical walkthroughs here drawn from across the knowledge base.

### Disk diagnostics

* [How to get S.M.A.R.T. data on disks with a RAID controller](/tutorials/disk-diagnostics/how-to-get-smart-disks-with-raid-controller/)
* [How to get S.M.A.R.T. data on disks without a RAID controller](/tutorials/disk-diagnostics/how-to-get-smart-disks-without-raid-controller/)

### File transfer

* [How to set up a vsftpd FTP server on CentOS 6](/tutorials/file-transfer/how-to-setup-vsftpd-ftp-server-on-centos-6/)
* [How to set up an FTP server on Ubuntu 16.04](/tutorials/file-transfer/how-to-setup-ftp-server-on-ubuntu-16-04/)
* [How to copy files between Linux servers using rsync](/tutorials/file-transfer/how-to-copy-files-between-linux-servers-using-rsync/)

### iDRAC boot management

* [How to boot a dedicated server from a custom OS image via iDRAC](/tutorials/idrac-boot-management/how-to-boot-dedicated-server-custom-os-image-idrac/)
* [How to boot a server from a custom ISO via iDRAC](/tutorials/idrac-boot-management/how-to-boot-server-custom-iso-idrac/)
* [How to restore a dedicated server to rescue mode](/tutorials/idrac-boot-management/how-to-restore-dedicated-server-rescue-mode/)
* [What to do if the OS won't boot](/tutorials/idrac-boot-management/what-to-do-if-os-wont-boot/)

### iDRAC setup

* [How to access OOB management](/tutorials/idrac-setup/how-to-access-oob-management/)
* [How to configure the iDRAC HTML5 plugin](/tutorials/idrac-setup/how-to-configure-idrac-html5-plugin/)
* [How to update iDRAC](/tutorials/idrac-setup/how-to-update-idrac/)
* [A guide to iDRAC's virtual media function](/tutorials/idrac-setup/a-guide-to-idrac-virtual-media-function/)
* [How to perform diagnostics with iDRAC Lifecycle Controller](/tutorials/idrac-setup/how-to-perform-diagnostics-idrac-lifecycle-controller/)
* [Locating service tags](/tutorials/idrac-setup/locating-service-tags/)

### iDRAC VPN access

* [L2TP/IPsec on Linux Fedora 24](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-24/)
* [L2TP/IPsec on Linux Fedora 30](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-30/)
* [L2TP/IPsec on Linux Fedora 41](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-41/)
* [L2TP/IPsec on Linux Ubuntu 16.04](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-16-04/)
* [L2TP/IPsec on Linux Ubuntu 18.04](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-18-04/)
* [L2TP/IPsec on Linux Ubuntu 20.04](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-20-04/)
* [L2TP/IPsec on Linux Ubuntu 22.04](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-22-04/)
* [L2TP/IPsec on Linux Ubuntu 24.04](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-24-04/)
* [L2TP/IPsec on macOS](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-mac-os-x/)
* [L2TP/IPsec on Windows](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-ms-windows/)

### Monitoring

* [Using Monit for process monitoring on Ubuntu and Debian](/tutorials/monitoring/using-monit-process-monitoring-on-ubuntu-debian/)
* [How to install Zabbix on CentOS 6/8 and Ubuntu 12.04](/tutorials/monitoring/how-to-install-zabbix-on-centos-6-8-and-ubuntu-12-04/)
* [How to install Munin on Ubuntu and CentOS](/tutorials/monitoring/how-to-install-munin-on-ubuntu-and-centos/)

### Networking and IP management

* [How to order an additional IP network](/tutorials/networking-and-ip-management/how-to-order-additional-ip-network/)
* [How to point a domain to a dedicated server IP](/tutorials/networking-and-ip-management/how-to-point-domain-to-dedicated-server-ip/)
* [How to rename network interfaces on Linux](/tutorials/networking-and-ip-management/how-to-rename-interfaces-linux/)
* [How to restore network interfaces configuration](/tutorials/networking-and-ip-management/how-to-restore-network-interfaces-config/)
* [How to set up a floating IP using Keepalived](/tutorials/networking-and-ip-management/how-to-setup-floating-ip-using-keepalived/)
* [How to disaggregate network interfaces on a Proxmox server](/tutorials/networking-and-ip-management/how-to-disaggregate-network-interfaces-on-a-proxmox-server/)
* [How to provide network diagnostic results](/tutorials/networking-and-ip-management/how-to-provide-network-diagnostic-results/)

### Password and authentication

* [Root password reset on Ubuntu 24.04](/tutorials/password-and-authentication/root-password-reset-ubuntu-24-04/)
* [Reset root password on Ubuntu 16.04 (dedicated)](/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-dedicated/)
* [Reset root password on Ubuntu 16.04 (cloud)](/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-cloud/)
* [Reset root password on CentOS 6/7](/tutorials/password-and-authentication/reset-root-password-centos-6-7/)
* [How to reset root password on Ubuntu 16.04 / Debian 7–8 with Proxmox](/tutorials/password-and-authentication/how-to-reset-root-password-ubuntu-16-04-debian-7-8-proxmox/)
* [How to reset root password on Ubuntu 18.04 / Debian 9 with Proxmox](/tutorials/password-and-authentication/how-to-reset-root-password-ubuntu-18-04-debian-9-proxmox/)

### Software installation

* [How to install LAMP on CentOS 6](/tutorials/software-installation/how-to-install-lamp-on-centos-6/)
* [How to install the nano text editor on Linux](/tutorials/software-installation/how-to-install-nano-text-editor-in-linux/)

### SSH access

* [Connecting to a remote server via SSH](/tutorials/ssh-access/connecting-to-a-remote-server-via-ssh/)
* [How to create a new SSH key pair](/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair/)
* [How to add a new SSH key to a cloud server](/tutorials/ssh-access/how-to-add-new-ssh-key-to-a-cloud-server/)
* [How to replace password-based SSH authentication with key-based](/tutorials/ssh-access/how-to-replace-password-based-ssh-authentication-with-key-based/)
* [How to limit SSH access by IP addresses using a firewall](/tutorials/ssh-access/how-to-limit-ssh-access-by-ip-addresses-using-firewall/)
* [How to protect SSH using Fail2ban on Ubuntu 16.04](/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-ubuntu-16-04/)
* [How to protect SSH using Fail2ban on CentOS 6](/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-centos-6/)

### Storage and disk

* [How to work with LVM](/tutorials/storage-and-disk/how-to-work-with-lvm/)
* [How to install Ubuntu with software RAID 1](/tutorials/storage-and-disk/how-to-install-ubuntu-with-software-raid-1/)

### Virtualization

* [Configure networking in ESXi 5.5 / 6.0 / 6.6](/tutorials/virtualization/configure-network-esxi-5-5-6-0-6-6/)
* [Configure networking in Hyper-V](/tutorials/virtualization/configure-network-hyper-v/)
* [Configure networking in Proxmox VE 6.4 / 7.4](/tutorials/virtualization/configure-network-proxmox-ve-6-4-7-4/)
* [Virtual machines and support responsibilities](/tutorials/virtualization/virtual-machines-and-support-responsibilities/)

### Windows administration

* [Connect to a Windows server](/tutorials/windows-administration/connect-to-windows-server/)
* [How to reset the admin password on Windows](/tutorials/windows-administration/how-to-reset-admin-password-windows/)
* [Prevent admin account brute-force lockout](/tutorials/windows-administration/prevent-admin-account-brute-force-lockout/)
* [How to configure networking on Windows Server 2012](/tutorials/windows-administration/how-to-configure-network-on-windows-server-2012/)
* [How to provide network diagnostic results to the technical support team](/tutorials/networking-and-ip-management/how-to-provide-network-diagnostic-results)


# Getting started (/docs/vpn2gpn/getting-started)



This page explains how to create a VPN to GPN gateway and retrieve connection credentials for your users.

## Creating a VPN gateway

1. Log in to the Customer Portal and navigate to **Networks** → **VPN Access**
2. Under **VPN to Global Private Network**, click **Create** and choose the region where the gateway will be created
3. Enter username for at least one user
4. Click **Save**

Wait for the status to change from **Pending** to **Active**.

## Getting VPN credentials for a user

1. Click the created gateway region name
2. On the **VPN to Global Private Network details** page, click **Show** next to the username you want credentials for

The following login details will be displayed:

* VPN server – VPN gateway's IP address
* Login – User's login
* Password – User's password
* Shared secret – Shared secret key

Additionally, you will find setup manuals for built-in VPN clients for the most popular OS.


# VPN to GPN (/docs/vpn2gpn)



**VPN to GPN** gives you encrypted remote access to the Servers.com Global Private Network from anywhere in the world - no custom gateway setup required, just connect using your OS built-in VPN client with per-instance credentials.

<DocCards>
  <DocCard title="Overview" description="Understand VPN to GPN concepts, limitations, and billing." href="/vpn2gpn/overview/" />

  <DocCard title="Getting Started" description="Set up your first VPN to GPN instance and connect." href="/vpn2gpn/getting-started/" />

  <DocCard title="Tunnel Options" description="Choose and configure the right tunnel type for your connection." href="/vpn2gpn/tunnel-options-for-vpn-to-gpn-connection/" />

  <DocCard title="Set Up Ubuntu VPN Client" description="Configure the native Ubuntu VPN client to connect to GPN." href="/vpn2gpn/setting-up-ubuntu-built-in-vpn-client/" />

  <DocCard title="Set Up Windows VPN Client" description="Configure the built-in Windows VPN client to connect to GPN." href="/vpn2gpn/setting-up-windows-built-in-vpn-client/" />
</DocCards>


# Overview (/docs/vpn2gpn/overview)



## Concepts

The VPN to GPN (VPN2GPN) service provides secure access to the Global Private Network (GPN) of Servers.com from anywhere in the world via an encrypted VPN connection.

The primary purpose is to provide system administrators and DevOps engineers with access to GPN without setting up a custom VPN gateway.

The service is based on a cloud server with a pre-installed operating system, acting as a VPN2GPN instance. Within this instance, VPN accounts (users) are created for establishing VPN connections and accessing GPN.

## Limitations

* Up to 13 users (VPN accounts) per gateway
* One user can have only one active connection
* Only one active connection is allowed per ISP when connecting from behind the same NAT
* Maximum bandwidth of up to 100Mbps to each VPN connection

## Billing

The service is provided on a postpaid basis. Charges are applied at the end of the each month. The service is billed as follows:

* A fixed monthly fee per VPN2GPN instance
* Extra charge for exceeding traffic limit (2048GB included in the monthly tariff)

### Cancellation terms

The service can be canceled at any time. Any outstanding payments must be paid up to the deletion date.


# Setting up macOS built-in VPN client (/docs/vpn2gpn/setting-up-macos-built-in-vpn-client)











This guide explains how to configure the macOS built-in L2TP over IPSec VPN client to connect to your VPN gateway.

## Creating the VPN connection

1. Go to **System Preferences → Network**, then click the **+** (Create a new service) button in the bottom-left corner.
   <img alt="Network preferences with Create a new service button" src={__img0} />
2. In the **Interface** list choose **VPN**. In the **VPN Type** list select **L2TP over IPSec**. Enter a connection name and click **Create**.
   <img alt="New VPN service dialog with L2TP over IPSec selected" src={__img1} />
3. Enter the IP address of your VPN gateway into the **Server Address** field. The IP address is part of your user credentials.
   <img alt="VPN connection settings with Server Address field" src={__img2} />
4. Click **Authentication Settings** and enter the **Password** and **Shared Secret** — both are provided in your user credentials. Click **OK**.
   <img alt="Authentication Settings with Password and Shared Secret fields" src={__img3} />
   You can now connect to the VPN from **System Preferences → Network** by selecting the connection and clicking **Connect**.

## Checking routing

By default, macOS routes the `10/8` network via the VPN connection. Use the following commands to verify routing entries for the VPN connection:

```bash
ifconfig ppp0
netstat -rn | grep ppp0
```

## Setting a default route for PPP connections

You can set the default netmask for PPP connections by creating the file `/etc/ppp/ip-up` with the following content:

```bash
#!/bin/sh
/sbin/route add 10.0.0.0/8 -interface $1
```

Then make the file executable:

```bash
sudo chmod 0755 /etc/ppp/ip-up
```

> **Note:** If you are connecting from a network that already uses the `10.x.x.x` range (for example `10.0.0.0/24`), you cannot set a default netmask for PPP connections. Add a specific GPN network route instead:
>
> ```bash
> #!/bin/sh
> /sbin/route add 10.12.34.0/21 -interface $1
> ```

Use this method to connect to all your available roaming networks.


# Setting up Ubuntu built-in VPN client (/docs/vpn2gpn/setting-up-ubuntu-built-in-vpn-client)

















This guide explains how to configure the Ubuntu built-in NetworkManager L2TP VPN client to connect to your VPN gateway.

## Installing required packages

Run the following commands to update your package list and install the L2TP plugin for NetworkManager:

```bash
sudo apt update
sudo apt install -y network-manager-l2tp network-manager-l2tp-gnome
```

## Setting up a new VPN connection

1. Click the network connection icon in the top-right corner of the desktop and click **Settings**.
   <img alt="Network icon menu with Settings button" src={__img0} />
2. In Settings, select the **Network** tab on the left. Click the **+** button next to the **VPN** label to add a new VPN connection.
   <img alt="Network settings with VPN section and + button" src={__img1} />
3. Choose **Layer 2 Tunneling Protocol (L2TP)** as the tunneling protocol.
   <img alt="VPN type selection dialog with L2TP option" src={__img2} />
4. Fill in the connection details using your user credentials:

   * **Gateway:** your VPN gateway IP address
   * **User name:** your Login
   * **Password:** your Password

   Click the **user** symbol in the password field and select **Store the password only for this user**.
   <img alt="L2TP VPN connection form with gateway and credentials" src={__img3} />
5. Click **IPsec Settings…** to open the IPsec configuration panel.
   <img alt="IPsec Settings dialog" src={__img4} />
   * Check **Enable IPsec tunnel to L2TP host**.
   * Enter your **Shared Secret** in the **Pre-shared key** field.
   * Click **Advanced** and set:
     * **Phase1 Algorithms:** `ike=aes128-sha1-modp2048`
     * **Phase2 Algorithms:** `esp=aes128-sha1`
   * Click **OK**.
6. Open the **IPv4** tab and scroll to **Routes**. Add a route as shown below, then click **Add**.
   <img alt="IPv4 routes configuration with 10.0.0.0/8 route" src={__img5} />
   Save the connection by clicking **Add**.
7. Toggle the VPN connection on in **Settings → Network → VPN** to confirm it connects successfully.
   <img alt="VPN toggle enabled in Network settings" src={__img6} />


# Setting up Windows built-in VPN client (/docs/vpn2gpn/setting-up-windows-built-in-vpn-client)











This guide explains how to configure the Windows built-in L2TP/IPsec VPN client to connect to your VPN gateway.

## Creating the VPN connection

1. Open VPN settings by pressing **Win + R**, typing `ms-settings:network-vpn`, and pressing **Enter**.
   <img alt="Run dialog with ms-settings:network-vpn" src={__img0} />
2. Click **Add a VPN connection** and fill in the fields:
   * **VPN provider:** Windows (built-in)
   * **Connection name:** GPN
   * **VPN type:** L2TP/IPsec with pre-shared key
   * **Server name or address:** your VPN server address (from user credentials)
   * **Pre-shared key:** your Shared Secret (from user credentials)
   * **User name:** your Login (from user credentials)
   * **Password:** your Password (from user credentials)
     Click **Save**.
     <img alt="Add a VPN connection form filled in" src={__img1} />

## Configuring additional parameters via PowerShell

3. Open **PowerShell**: click **Start**, type **PowerShell**, and click **Windows PowerShell**.
4. Run the following command to check the connection properties:

```powershell
Get-VpnConnection -Name "GPN" -erroraction 'silentlycontinue'; Get-VpnConnection -AllUserConnection -Name "GPN" -erroraction 'silentlycontinue'
```

<img alt="PowerShell showing VPN connection properties" src={__img2} />
5\. Check the **AllUserConnection** property in the output. If it reads `True`, the VPN is in the global (machine) phone book — run:

```powershell
Set-VpnConnection -Name "GPN" -EncryptionLevel "Optional" -AuthenticationMethod CHAP, MSCHAPv2 -SplitTunneling $True -AllUserConnection -PassThru
```

If `AllUserConnection` reads `False`, run:

```powershell
Set-VpnConnection -Name "GPN" -EncryptionLevel "Optional" -AuthenticationMethod CHAP, MSCHAPv2 -SplitTunneling $True -PassThru
```

<img alt="PowerShell output confirming VPN parameters were set" src={__img3} />

6. Add the route for the VPN connection:

```powershell
Add-VpnConnectionRoute -ConnectionName "GPN" -DestinationPrefix "10.0.0.0/8"
```

## Connecting to the VPN

You can connect in any of the following ways:

* **Settings:** Press **Win + R**, type `ms-settings:network-vpn`, press **Enter**, select **GPN**, and click **Connect**.
* **System tray:** Click the network icon, choose **GPN**, and click **Connect**.
* **PowerShell:** Run `rasdial GPN`.

## Troubleshooting

If you see the error:

> `The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer`
> Open **Command Prompt as Administrator** and run:

```powershell
Set-VpnConnectionIPsecConfiguration -ConnectionName "GPN" -AuthenticationTransformConstants SHA196 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup None -DHGroup Group14 -PassThru -Force
```

> **Note:** Replace `"GPN"` with your actual VPN connection name if you used a different one.


# Tunnel options for VPN to GPN connection (/docs/vpn2gpn/tunnel-options-for-vpn-to-gpn-connection)



A VPN to GPN connection is built upon a tunnel that features a set of specific parameters. Some VPN clients may by default have incompatible options with the Servers.com connection.

Please get acquainted with the below table that contains a list of parameters with their values supported by Servers.com. While setting up your VPN client, make sure that your configuration meets the available Servers.com tunnel options.

| Tunnel option                             | Supported values                                           | Description                                                                                                                                                                                                                                                                                                                                                                             |
| ----------------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IKE versions                              | ikev1                                                      | A version of the Internet Key Exchange (IKE) protocol. The same version must be met on both ends of a VPN tunnel.                                                                                                                                                                                                                                                                       |
| Phase 1 Diffie-Hellman (DH) group numbers | Group 2, 5, 14, 15, 16, 17, 18, 19, 20, 21, 25, 26, 31, 32 | A Diffie-Hellman (DH) group defines the strength of a key taking part in the process of a key exchange. The higher the group, the stronger the security, but with that comes a longer processing time.                                                                                                                                                                                  |
| Phase 1 encryption algorithms             | AES128, AES256, AES128-GCM-16, AES256-GCM-16               | The process for when both members of a VPN tunnel exchange different parameters to come to an agreement is called a VPN negotiation. It consists of two phases:                                                                                                                                                                                                                         |
| Phase 2 encryption algorithms             | AES128, AES256, AES128-GCM-16, AES256-GCM-16               | Phase 1: to establish a secure encrypted channel so that both members can negotiate\n\nPhase 2: both members come to an agreement called a Security Association that includes negotiated parameters on what traffic goes through the VPN and how to encrypt it                                                                                                                          |
| Phase 1 integrity algorithms              | SHA1, SHA2-256, SHA2-384, SHA2-512                         | Each phase is featured with encryption and integrity algorithms:                                                                                                                                                                                                                                                                                                                        |
| Phase 2 integrity algorithms              | SHA1, SHA2-256, SHA2-384, SHA2-512                         | Encryption algorithms are needed to protect data. All available algorithms are based on the Advanced Encryption Standard (AES). It's a symmetric algorithm that uses the same key for encryption and decryption\n\nIntegrity algorithms make sure that data within the packages aren't changed. This operation is based on calculating a hash value using a Secure Hash Algorithm (SHA) |


# Getting started (/docs/vpn2oob/getting-started)



To start using VPN to OOB, you need a VPN client — built-in OS VPN applications will work as well.

1. Create credentials on the [Servers.com Customer Portal](https://portal.servers.com/networks/vpn): **Networks** → **VPN access** → **VPN to DRAC**, then click **Create**.
2. Give the credentials a name and select a VPN location. Once the credentials are ready, you can find them in the [list](https://portal.servers.com/networks/vpn).
3. Click the **Credentials** button to view them.
4. In the modal window, you will see links to instructions for different operating systems.
5. Follow the instruction for your operating system.


# VPN to OOB (/docs/vpn2oob)



**VPN to OOB** gives you secure VPN access to your server's OOB management interface - so you can power-cycle, reinstall, and diagnose servers remotely even when the OS is completely unresponsive. Access is free and available from any major operating system.

<DocCards>
  <DocCard title="Overview" description="Understand OOB access methods, use cases, and per-location credentials." href="/vpn2oob/overview/" />

  <DocCard title="Getting Started" description="Create VPN credentials and connect to your server's iDRAC." href="/vpn2oob/getting-started/" />
</DocCards>


# Overview (/docs/vpn2oob/overview)





This article covers the key concepts behind the VPN to OOB service, including out-of-band management, available access methods, setup steps, and use cases.

### Concepts

The VPN to OOB service allows you to establish a secure VPN connection to the server's out-of-band (OOB) management.

#### Out-of-band management

Dedicated servers are equipped with the out-of-band (OOB) management platform that sits on the server motherboard and allows you to update and manage servers even if they are turned off. In case of Dell, such a platform is called iDRAC.
OOB management provides these opportunities:

* Remote access via the web interface or command line
* Power management
* Hardware sensors monitoring
* Operating system reinstallation

The OOB network is connected from an OOB switch to an OOB port of a server.

<img alt="OOB network scheme" src={__img0} />

#### Out-of-band access

By default, the OOB network is hidden behind VPN to enhance security. However, some cases require urgent access when there is no option to connect via VPN. That's why Servers.com has two ways to reach OOB:

* **Public access** — access over Internet without a VPN connection
* **VPN to OOB service** — access via a VPN client

### Public OOB access activation

Public access allows you to connect to the server's OOB via an OOB IP address using a login and password. To reach OOB of a server, follow these steps:

1. Navigate to the **Enterprise Bare Metal** → **Manage** section of the Customer Portal. Click the **Details** button next to the server's name. On the server's details page, scroll down to the **OOB** section.
2. Click the **Enable public access for 24 hours** button. After this, the public OOB access will be open for the next 24 hours.
3. Enter the **IP** address from the OOB section in your browser and log in using the **Credentials** button. A browser will warn you about your connection being not secure because of a self-signed HTTPS certificate — this is normal, continue despite this message.
4. After successful login, you will see the OOB dashboard of a server vendor from where you can perform the necessary operations.
5. When public access is no longer needed, you can turn it off by clicking **Disable access** in the **OOB** section.

### VPN to OOB setup

The Servers.com Customer Portal provides you with VPN credentials to access servers' OOB. These credentials consist of:

* Name (Default user is a name given automatically)
* Login
* Password
* Shared secret

Credentials are associated with a specific location but they can be used to reach other locations too.

### Limitations

Up to 5 credentials records per location.

### Billing

The service is free.

### Use cases

#### Troubleshooting

This service is useful for troubleshooting cases. When a Dell server becomes unavailable, you can connect to its DRAC using a secure VPN connection and fix the issue.

#### Security

When an employee has left a company, you can reset their credentials from the Customer Portal and be sure that only your current team members can reach the OOB of your servers.


# How to get SMART for disks in a dedicated server with a RAID controller (/docs/tutorials/disk-diagnostics/how-to-get-smart-disks-with-raid-controller)



When a server uses a hardware RAID controller, disk devices are not directly exposed to the OS — you must pass the controller type to `smartctl` to retrieve SMART data.

### Prerequisites

Install `smartmontools` if not already installed:

* **Debian/Ubuntu:** `sudo apt-get install smartmontools`
* **Red Hat/CentOS:** `sudo yum install smartmontools`
* **Fedora:** `sudo dnf install smartmontools`

### Step 1: List available disks

```bash
smartctl --scan
```

This lists all disks available for SMART querying.

### Step 2: Retrieve SMART data

Use the `smartctl` command with the appropriate device type:

```bash
smartctl -d sat+<device_type> -a <device_path>
```

Replace:

* `<device_type>` with the appropriate type (e.g., `megaraid,0`). If the disk type is SATA, prepend `sat+` (e.g., `sat+megaraid,0`)
* `<device_path>` with the actual path to the device (e.g., `/dev/bus/9`)

**Note:** There is a known bug in `smartmontools` — regardless of which device you specify in `/dev/sdX`, the utility only considers the disk slot number in megaraid 0. More details are available at the [smartmontools bug tracker](https://www.smartmontools.org/ticket/46).

### Using MegaCli

If you do not have access to iDRAC but have OS access, you can use the **MegaCli** utility. It is designed for working with LSI hardware RAID controllers from the OS and is not suitable for software RAID or individual disks.

Common MegaCli commands:

```bash
# List all physical disks
MegaCli -PDList -aALL

# Check disk state
MegaCli -PDInfo -PhysDrv [E:S] -aALL

# Check SMART data for a specific disk
MegaCli -PDGetMissing -aALL
```

Replace `[E:S]` with the enclosure ID and slot number from the PDList output.

For full SMART attribute interpretation, refer to the [How to get SMART for disks in a dedicated server without a RAID controller](/tutorials/disk-diagnostics/how-to-get-smart-disks-without-raid-controller) guide.


# How to get SMART for disks in a dedicated server without a RAID controller (/docs/tutorials/disk-diagnostics/how-to-get-smart-disks-without-raid-controller)





SMART (Self-Monitoring, Analysis, and Reporting Technology) is a technology that provides users with various data about the current state of a hard disk drive or solid-state drive (SSD). Analyzing SMART data helps assess the health of server drives and determines whether they need replacing or can continue operating reliably.

To work with SMART, you need the `smartmontools` package installed, and the drive must support this technology.

### Step 1: Install smartmontools

The installation command may vary depending on your Linux distribution:

* **Debian/Ubuntu:**
  ```bash
  sudo apt-get update
  sudo apt-get install smartmontools
  ```
* **Red Hat/CentOS:**
  ```bash
  sudo yum install smartmontools
  ```
* **Fedora:**
  ```bash
  sudo dnf install smartmontools
  ```

### Step 2: Identify the disk

Use the `lsblk` or `fdisk -l` command to list all available disks and their device names:

```bash
lsblk
```

### Step 3: Check SMART status

Use the `smartctl` command to check the SMART status of the disk (replace `/dev/sdX` with your device name):

```bash
sudo smartctl -i /dev/sdX
```

This displays a comprehensive SMART report. The last two lines indicate whether SMART is supported and enabled.

If SMART is disabled, enable it:

```bash
sudo smartctl -s on /dev/sdX
```

To check overall drive status:

```bash
sudo smartctl -H /dev/sdX
```

If the output shows anything other than `PASSED`, the drive may have already failed or is expected to fail within 24 hours.

To get comprehensive SMART information:

```bash
sudo smartctl -A /dev/sdX
```

<img alt="Drive SMART information output" src={__img0} />

### Understanding SMART output

Key fields in the output:

* **ATTRIBUTE\_NAME** – the name of the attribute being assessed (e.g., disk temperature)
* **VALUE** – the current attribute value; a low value indicates degradation or potential failure
* **THRESH** – the threshold set by the manufacturer; if Value falls below this, a failure warning appears
* **TYPE** – attributes can be critical (`Pre-fail`) or non-critical (`Old_age`)

### Important parameters for HDDs

* **Reallocated\_Sector\_Ct** – number of reallocated sectors; if RAW\_VALUE exceeds 30 and is increasing, consider replacing the disk
* **Reallocated\_Event\_Count** – total attempts to reallocate faulty sectors
* **Current\_Pending\_Sector** – sectors flagged for potential reallocation
* **Offline\_Uncorrectable** – errors during read/write that couldn't be corrected; increasing values suggest surface defects
* **Power\_On\_Hours** – total hours the disk has been powered on
* **Hardware\_ECC\_Recovered** – hardware errors corrected by drive software; replace disk if VALUE approaches THRESH
* **UDMA\_CRC\_Error\_Count** – errors during data transmission via cable; increasing count suggests checking the disk

### Important parameters for SSDs

SSD SMART attributes vary by manufacturer. Key attributes:

* **SSD\_Life\_Left / Wear\_Leveling\_Count / Percent\_Life\_Remaining** – remaining drive life as a percentage; replace when approaching zero
* **Retired\_Block\_Count** – blocks no longer used for writing; high values indicate drive end of life
* **Raw\_Read\_Error\_Rate** – frequency of read errors; high RAW\_VALUE may indicate drive problems
* **Power\_On\_Hours** – total operating hours
* **Temperature\_Celsius** – drive temperature
* **Lifetime\_Writes\_GiB / Total\_LBAs\_Written** – total data written; compare to manufacturer's TBW (Total Bytes Written)

### Important parameters for NVMe drives

NVMe drives report health via a different interface:

```bash
sudo smartctl -a /dev/nvme0
```

Key parameters:

* **Critical Warning** – critical errors in drive operation
* **Available Spare** – remaining reserve area for replacing failed memory cells
* **Percentage Used** – wear level (100% means the drive's lifecycle is complete)
* **Media and Data Integrity Errors** – data integrity errors; if constantly increasing, replace the drive
* **Unsafe Shutdowns** – number of unsafe power shutdowns

### Calculating drive resource usage

To determine how much of the drive's life has been used:

```bash
# Get Total_LBAs_Written from SMART
sudo smartctl -A /dev/sdX | grep Total_LBAs_Written
```

Then calculate:

```
Total data written = Total_LBAs_Written × 512 bytes
Percentage used   = (Total data written) × 100 / Manufacturer's TBW
```


# Disk diagnostics (/docs/tutorials/disk-diagnostics)



This section covers guides for monitoring and assessing the health of disks in your dedicated servers using SMART (Self-Monitoring, Analysis, and Reporting Technology). Regular disk health monitoring is essential for identifying drives that are approaching failure before data loss occurs.

We provide separate guides for servers with and without a hardware RAID controller, as the method of accessing SMART data differs depending on whether disks are directly exposed to the operating system or managed by a controller.


# How to copy files between Linux servers using rsync (/docs/tutorials/file-transfer/how-to-copy-files-between-linux-servers-using-rsync)



rsync is a file synchronization utility that helps you copy or transfer files locally or to a remote server. It transfers only the differences between source and destination, making repeated syncs fast and bandwidth-efficient.

### Installation

rsync is pre-installed on most Linux distributions. If not:

```bash
# Debian/Ubuntu
sudo apt-get install rsync

# CentOS/RHEL
sudo yum install rsync
```

### Basic syntax

```bash
rsync [options] source destination
```

### Local copy

```bash
rsync -av /source/directory/ /destination/directory/
```

The trailing slash on the source means "copy the contents of this directory". Without it, the directory itself is copied.

### Copy to a remote server

```bash
rsync -av /local/path/ username@remote-server:/remote/path/
```

### Copy from a remote server

```bash
rsync -av username@remote-server:/remote/path/ /local/path/
```

### Commonly used options

| Option              | Description                                                        |
| ------------------- | ------------------------------------------------------------------ |
| `-a`                | Archive mode: preserves permissions, timestamps, symlinks, etc.    |
| `-v`                | Verbose output                                                     |
| `-z`                | Compress data during transfer                                      |
| `-P`                | Show progress and keep partial files                               |
| `--delete`          | Delete files at the destination that no longer exist at the source |
| `-n` or `--dry-run` | Simulate the transfer without making changes                       |
| `-e ssh`            | Use SSH as the transport (default for remote transfers)            |

### Sync with delete (mirror)

To make the destination an exact mirror of the source (removing files deleted from source):

```bash
rsync -av --delete /source/ username@remote-server:/destination/
```

### Using a specific SSH key

```bash
rsync -av -e "ssh -i ~/.ssh/id_ed25519" /local/path/ username@remote-server:/remote/path/
```

### Using a non-default SSH port

```bash
rsync -av -e "ssh -p 2222" /local/path/ username@remote-server:/remote/path/
```

### Dry run first

Always test with `--dry-run` before a destructive sync:

```bash
rsync -av --delete --dry-run /source/ username@remote-server:/destination/
```

### Scheduling with cron

To run a nightly backup at 2:00 AM:

```
0 2 * * * rsync -az --delete /var/www/ backup-server:/backups/www/
```


# How to set up an FTP server on Ubuntu 16.04 (/docs/tutorials/file-transfer/how-to-setup-ftp-server-on-ubuntu-16-04)



An FTP server is the best solution if you want to upload files to a server or give employees access to set up a website. This guide covers installing and configuring vsftpd on Ubuntu 16.04.

### Installation

```bash
sudo apt-get update
sudo apt-get install vsftpd
```

### Configuration

Back up the default config and open it for editing:

```bash
sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.bak
sudo nano /etc/vsftpd.conf
```

Apply the following settings:

```ini
# Disable anonymous login
anonymous_enable=NO

# Allow local users
local_enable=YES

# Allow uploads
write_enable=YES

# Restrict users to their home directories
chroot_local_user=YES
allow_writeable_chroot=YES

# Passive mode settings
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100

# Show hidden files (optional)
force_dot_files=YES
```

### Creating an FTP user

```bash
sudo adduser ftpuser
sudo passwd ftpuser
```

To prevent the user from logging in via SSH:

```bash
sudo usermod -s /usr/sbin/nologin ftpuser
echo "/usr/sbin/nologin" | sudo tee -a /etc/shells
```

### UFW firewall rules

If UFW is enabled, open the required ports:

```bash
sudo ufw allow 20/tcp
sudo ufw allow 21/tcp
sudo ufw allow 40000:40100/tcp
sudo ufw reload
```

### Starting and enabling vsftpd

```bash
sudo systemctl start vsftpd
sudo systemctl enable vsftpd
```

### Connecting to the FTP server

Use any FTP client (FileZilla, lftp, command-line ftp) to connect:

* **Host**: your server IP
* **Port**: 21
* **Username/Password**: the FTP user credentials

You should land in the user's home directory with upload permissions.

### Troubleshooting

* **500 OOPS: vsftpd: refusing to run with writable root inside chroot**: add `allow_writeable_chroot=YES` to the config.
* **Connection refused on passive ports**: ensure UFW/iptables rules allow the passive port range.


# How to set up vsftpd FTP server on CentOS 6 (/docs/tutorials/file-transfer/how-to-setup-vsftpd-ftp-server-on-centos-6)



This article guides you through the process of setting up vsftpd to allow a user to upload files to their home directory using FTP on CentOS 6.

### Installation

```bash
sudo yum install vsftpd
```

### Configuration

Open the main configuration file:

```bash
sudo nano /etc/vsftpd/vsftpd.conf
```

Make the following changes to enable local user logins and restrict them to their home directories:

```ini
# Disable anonymous access
anonymous_enable=NO

# Allow local system users to log in
local_enable=YES

# Allow file uploads
write_enable=YES

# Restrict users to their home directories
chroot_local_user=YES

# Required when chroot is enabled to avoid the "500 OOPS" error
allow_writeable_chroot=YES

# Use passive mode (recommended for firewalls/NAT)
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
```

### Creating an FTP user

Create a dedicated user for FTP access:

```bash
sudo useradd -m ftpuser
sudo passwd ftpuser
```

If you want to restrict the user from SSH login while allowing FTP:

```bash
sudo usermod -s /sbin/nologin ftpuser
```

Add `/sbin/nologin` to `/etc/shells` so vsftpd accepts it:

```bash
echo "/sbin/nologin" | sudo tee -a /etc/shells
```

### Firewall rules

Open the FTP control port and passive data ports:

```bash
sudo iptables -A INPUT -p tcp --dport 21 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 40000:40100 -j ACCEPT
sudo service iptables save
```

### Starting vsftpd

```bash
sudo service vsftpd start
sudo chkconfig vsftpd on
```

### Testing the connection

Connect from a client machine:

```bash
ftp your-server-ip
```

Log in with the FTP user credentials. You should land in the user's home directory and be able to upload files.


# File transfer (/docs/tutorials/file-transfer)



Moving files between servers and giving users upload access are everyday operational tasks. This section covers FTP server setup with vsftpd on both CentOS and Ubuntu, and efficient file synchronisation between Linux servers using rsync.

### Explore file transfer instructions

<Cards>
  <Card title="vsftpd on CentOS 6" description="Set up an FTP server with user home-directory access on CentOS 6." href="/tutorials/file-transfer/how-to-setup-vsftpd-ftp-server-on-centos-6" />

  <Card title="FTP Server on Ubuntu 16.04" description="Install and configure vsftpd for secure FTP access on Ubuntu." href="/tutorials/file-transfer/how-to-setup-ftp-server-on-ubuntu-16-04" />

  <Card title="Copy Files with rsync" description="Sync files between Linux servers efficiently using rsync." href="/tutorials/file-transfer/how-to-copy-files-between-linux-servers-using-rsync" />
</Cards>


# How to boot a dedicated server into a custom OS image using iDRAC (/docs/tutorials/idrac-boot-management/how-to-boot-dedicated-server-custom-os-image-idrac)













Your Dell server's out-of-band management platform is called iDRAC, and it allows you to mount virtual remote media to the server so you can boot from that media and install an operating system.

For your safety, iDRAC is hidden behind the VPN. For your convenience, you can temporarily enable public access to your server's iDRAC so that no VPN use is required.

You will find VPN credentials and setup instructions in the **Profile** → **Account** section of the Customer Portal.

Each server's iDRAC credentials can be found on a server's details page in the Customer Portal, where you can also enable public access. Public iDRAC access is allowed on a temporary basis. Once enabled, it will last for the next 24 hours, but you can turn it off ahead of schedule.

Enter the IP address of iDRAC in the address bar of your browser. The browser will warn you about your connection being not secure because of a self-signed HTTPS certificate. Add an exception and continue. Enter previously received iDRAC credentials on the iDRAC authentication page.

<img alt="Integrated Dell Remote Access Controller 7" src={__img0} />

Go to **Overview** → **Server** → **Attached Media**. In the **Attach Mode** drop-down list, click **Attach** and then click **Apply**.

<img alt="Attached media section" src={__img1} />

Go to **Overview** → **Server** → **Properties** → **Summary**. Here click **Launch** in the **Virtual Console Preview** section. You will be prompted to open or save the file `viewer.jnlp`. If you cannot run the file, make sure that you have installed Java Runtime Environment.

<img alt="Virtual Console Preview section" src={__img2} />

When you open `viewer.jnlp` in the Java environment, a connection to the virtual console of the server will be established. In the console, select **Virtual Media Main Menu** → **Connect Virtual Media**.

<img alt="When you open a file viewer.jnlp in Java environment" src={__img3} />

After connecting the Virtual Media, you can mount the `.ISO` image of your operating system. To do this, select **Virtual media** → **Map CD/DVD** in the console main menu. In the new window, specify the path to the image, and then click **Map Device**.

<img alt="Virtual media - Map CD / DVD" src={__img4} />

After that, the mounting is complete. To boot the server from the image, reboot the server and select **Virtual CD/DVD/ISO** as the boot source in BIOS.


# How to boot a server into a custom ISO image using iDRAC (/docs/tutorials/idrac-boot-management/how-to-boot-server-custom-iso-idrac)











Your Dell server's out-of-band management (OOB) platform is called [iDRAC](https://www.dell.com/support/kbdoc/en-us/000179517/dell-poweredge-how-to-configure-the-idrac-system-management-options-on-servers). It's a piece of dedicated hardware on the server's motherboard, allowing system administrators to access the server's console remotely and attach virtual media.

iDRAC provides remote console and virtual media capabilities even when your server's OS fails to boot, or there is no OS installed at all. Please refer to "[How to access the out-of-band management interface of a Dell server called iDRAC](/tutorials/idrac-setup/how-to-access-oob-management)" for instructions on how to access iDRAC of your server.

The Virtual Media feature of iDRAC allows system administrators to boot their servers into custom ISO images located on an SMB share or an administrator's workstation.

### Enabling the Virtual Media feature in iDRAC

You may need to enable the Virtual Media feature in the **Configuration** section of the iDRAC web interface. To do so, navigate to **Configuration** → **Virtual Media** and set the **Enabled** property value to `Enabled`:

<img alt="You may need to enable the Virtual Media feature in the Configuration section of iDRAC web interface" src={__img0} />

### Using a local ISO image as Virtual Media

You can use an ISO image located on your workstation as virtual media on the server. To do that, you need to launch **Virtual Console** within iDRAC and click **Connect Virtual Media**:

<img alt="you need to launch Virtual Console within iDRAC and click Connect Virtual Media" src={__img1} />

You will be asked to select a file:

<img alt="You will be asked to select a file" src={__img2} />

Press **F11** during startup to select the boot device or **F2** to set boot order through BIOS.

For additional instructions, please refer to the Dell documentation for your iDRAC version:

#### iDRAC 9

* [Using the Virtual Media function on iDRAC6, iDRAC7, iDRAC8 and iDRAC9](https://www.dell.com/support/kbdoc/en-us/000124001/using-the-virtual-media-function-on-idrac-6-7-8-and-9)
* [iDRAC 9 User's Guide – Launching virtual media using virtual console](https://www.dell.com/support/manuals/en-us/idrac9-lifecycle-controller-v3.3-series/idrac9_3.36.36.36_ug/launching-virtual-media-using-virtual-console?guid=guid-4ad23c7d-b1ed-43c8-b601-630c0174c174\&lang=en-us)

#### iDRAC 7/8

* [iDRAC 8/7 User's Guide – Launching virtual media using virtual console](https://www.dell.com/support/manuals/en-us/idrac7-8-lifecycle-controller-v2.50.50.50/idrac_2.50.50.50_ug_pub/launching-virtual-media-using-virtual-console?guid=guid-2f69a16f-bfc7-4d06-88b0-5312e7d2a42a\&lang=en-us)

### Using an ISO file on a remote file share as a Virtual Media

You can use an ISO image located on a remote file share as virtual media on the server. Depending on the version, iDRAC on your server supports CIFS (SMB) shares or CIFS (SMB) and HTTP/HTTPS.

Use an IPv4 host address in the **Image File Path** field as iDRAC can't resolve DNS hostnames.

Please note that the OOB network connecting your bare-metal servers is separated from the private network and the Internet. As such, your server's iDRAC can't access any remote file shares by default. You should turn on the **Enable public access for 24 hours** feature to allow your server's iDRAC to access external networks.

You can set up the remote file share in the **Virtual Media** configuration section:

<img alt="You can set up the remote file share in the Virtual Media configuration section" src={__img3} />

After connecting the image, press **F11** during startup to select the boot device or **F2** to set boot order through BIOS.


# How to restore a dedicated server using Rescue mode (/docs/tutorials/idrac-boot-management/how-to-restore-dedicated-server-rescue-mode)





In cases when OS is affected by critical system errors or the server is unable to boot properly, the Customer Portal feature called Rescue mode may come in handy.

This feature is suitable for recovery of most Linux-based operating systems.

### How to use Rescue mode

Imagine that something went wrong with the OS configuration — for example, the GRUB loader configuration file is corrupted, and the server shows a black screen and is unable to boot:

<img alt="How to restore a dedicated server using Rescue mode" src={__img0} />

This issue might be solved in a number of ways, one of which is using Rescue mode.

Press the **Reboot to rescue** button in the Customer Portal and wait for an email containing temporary login credentials (this usually takes up to 10 minutes).

Use credentials to access the server via SSH:

```
$ ssh 123.45.67.89 -l root
```

The list of available useful commands is displayed upon login.

Now try to recover the GRUB configuration file.

Get the list of available disks and partitions using the `lsblk` command:

```
[root@dmgmtsrvinit.pxe ~]# lsblk
```

Identify the root partition and the `/boot` partition, then mount them:

```
mkdir /mnt/root
mount /dev/mapper/C1500302784I0-rootfs /mnt/root
mount /dev/md127 /mnt/root/boot
```

Mount several other partitions in order to make the `grub2-mkconfig` command work properly:

```
mount -o bind /dev /mnt/root/dev
mount -o bind /sys /mnt/root/sys
mount -t proc none /mnt/root/proc
```

Change the root directory using the `chroot` command:

```
chroot /mnt/root
```

Run the `grub2-mkconfig` command, which will generate a new GRUB configuration file:

```
[root@dmgmtsrvinit.pxe /]# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
done
```

Exit the chroot and shut down the server in a proper way:

```
[root@dmgmtsrvinit.pxe /]# exit
[root@dmgmtsrvinit.pxe ~]# shutdown -h now
```

### Exiting Rescue mode

As soon as recovery work has been finished, press the **Exit rescue mode** button in the Customer Portal. The server will exit Rescue mode and boot normally into the OS installed on its disks.


# iDRAC boot management (/docs/tutorials/idrac-boot-management)



This section covers guides for managing operating system installation, boot configuration, and server recovery using iDRAC's remote management capabilities. Whether you need to boot a server into a custom ISO image, install a fresh operating system remotely, or recover a server that can no longer boot, you'll find step-by-step instructions here.

These guides make use of iDRAC's Virtual Media feature, the Customer Portal's Rescue mode, and other remote recovery tools available on Servers.com dedicated servers.


# What to do if the operating system on a server won't boot (/docs/tutorials/idrac-boot-management/what-to-do-if-os-wont-boot)



If the operating system on your server won't boot, you have the following tools at your disposal:

* **iDRAC Virtual Console** — access the server's console remotely via iDRAC to see what is happening during boot and interact with the boot process. See [How to access the out-of-band management of a Dell server](/tutorials/idrac-setup/how-to-access-oob-management) for details.
* **Boot into a custom ISO image via iDRAC** — use iDRAC's Virtual Media feature to boot the server into a custom ISO image (e.g., a live Linux environment or a rescue disk) and perform recovery from there. See [How to boot a server into a custom ISO image using iDRAC](/tutorials/idrac-boot-management/how-to-boot-server-custom-iso-idrac) for details.
* **Rescue mode** — use the Customer Portal's built-in Rescue mode feature to boot the server into a minimal recovery environment, allowing you to access the server's disks via SSH and perform recovery operations. See [How to restore a dedicated server using Rescue mode](/tutorials/idrac-boot-management/how-to-restore-dedicated-server-rescue-mode) for details.
* **Password reset** — if the OS won't boot because of an authentication issue or a locked account, consider resetting the root/administrator password. See the password reset guides in the Server Recovery & Password Reset section.
* **Contact support** — if none of the above resolve the issue, contact Servers.com support for assistance.


# A guide to iDRAC's virtual media function (/docs/tutorials/idrac-setup/a-guide-to-idrac-virtual-media-function)

















The iDRAC virtual media function facilitates remote access to software image files, otherwise known as ISO (identical storage image of optical media) images. This allows operating systems to be installed and servers updated without needing to physically visit a server room. In this guide we'll provide a background into what iDRAC is, how the virtual media function works, and its various use cases.

## iDRAC

iDRAC stands for Integrated Dell Remote Access Controller. iDRAC is a piece of dedicated hardware that sits on a Dell server's motherboard and forms the [out-of-band (OOB) management platform](/tutorials/idrac-setup/how-to-access-oob-management) for that server. iDRAC hardware gives system administrators remote access to the server console and the ability to attach virtual media.

Functions that can be conducted remotely using iDRAC include:

* Troubleshooting
* Monitoring temperature controls
* Monitoring power consumption
* Installing an operating system
* Providing video, keyboard, and mouse over network (IPKVM)
* Hard rebooting a server
* Powering a server on and off

These remote access controls are important because it means servers can be accessed without having to physically travel to, and step foot in, the server facility. This is especially important when the servers you're accessing are headless (without a monitor, keyboard, or mouse). iDRAC provides these remote capabilities even in instances when there is no operating system installed on the server, the operating system fails to boot, or access to the operating system is blocked as a result of an error in the network configuration.

In the case of a system crash, having iDRAC configured means you can view the console and reboot the server there and then. Your hosting provider can also provide a separate network link and separate switches for iDRAC management so that you can access iDRAC even if your public and/or private network is down.

<img alt="A guide to iDRAC's virtual media function" src={__img0} />

### iDRAC virtual

iDRAC's virtual media feature allows system administrators remote access to media devices like virtual optical drives and USB flash drives located on the management station or ISO images on a network share — just as if they were devices on the managed server itself.

With this useful feature, system administrators can boot their servers into custom ISO images on a Server Message Block (SMB) share or administrator's workstation. It gives administrators the ability to mount ISO images (essentially making the ISO available on the file system by making your computer think that the ISO image is a real disc) so you can use the ISO image just as if it were a physical CD or DVD. This can be used for installing operating systems or updating server drivers and firmware.

Using the virtual media feature you can:

* Remotely access media over the network
* Install applications
* Update drivers
* Install an operating system on the managed system

It's worth noting here that, in order to access the virtual media function, you will need an enterprise license (aka iDRAC7, iDRAC8, or iDRAC9) or an enterprise module (iDRAC6). The SMB share should be accessible directly from the iDRAC.

<img alt="A guide to iDRAC's virtual media function" src={__img1} />

### How to enable iDRAC's virtual media function

In most cases, the virtual media feature can be enabled from within the iDRAC web interface, under the **Configuration** section.

**Configuration** → **Virtual Media** → **Enabled**

### How to start using the iDRAC virtual media function

This process may differ slightly depending on the version of iDRAC in operation. Follow the instructions below to use the virtual media function on iDRAC9, iDRAC7/8, and iDRAC6.

#### iDRAC9

To use the virtual media function on iDRAC9:

* Obtain the IP address and login details for your server's iDRAC
* If not already, configure your iDRAC so that it is fully enabled
* Log in to iDRAC using the IP on your browser
* Select **Launch Virtual Console** on the iDRAC web interface
* Select **Connect Virtual Media** to activate the function
* Select **Virtual Media** and click **Browse** on the device you want to pass through
* Select **Boot** and choose **Virtual CD/DVD/ISO**
* Confirm the boot action by selecting **Yes**
* The system will reboot and the installation interface will be displayed

<img alt="A guide to iDRAC's virtual media function" src={__img2} />

#### iDRAC7/8

To use the virtual media function on iDRAC7/8, follow the system prompts and disconnect virtual media after installation. Then:

* Open the **Virtual Console** from the iDRAC web interface
* Click on **Virtual Media**
* Choose **Connect Virtual Media**
* Select **Virtual Media**
* Select the device you want to pass through
* Click **Browse** to choose local system or image file drive you want to pass through
* To pass through an image, select and open the file
* Select **Map Device** to complete the source selection
* To boot from a selected device, select **Next Boot** and choose Virtual CD/DVD/ISO

<img alt="A guide to iDRAC's virtual media function" src={__img3} />

#### iDRAC6

To use the virtual media function on iDRAC6:

* Open the Virtual Console from the iDRAC web interface
* Select **Virtual Media** then **Launch Virtual Media**
* In the management window, select **Add Image** to open the selection window
* Select the ISO image you want to use and select **Open**
* Check the box under *Mapped* to associate the selected file as a virtual device and pass it through the server. The selected device will now appear in the operating system.

### What you can do using iDRAC's virtual media function

Beyond generally monitoring server health, iDRAC's virtual media feature has multiple use cases. The following are three examples of how virtual media can be used to (a) install an operating system on your server from the ISO, (b) boot a server into a custom ISO image, and (c) mount and unmount driver packs.

#### Install an operating system on your server directly from the ISO

Using iDRAC's virtual media feature, you can install an operating system on your server directly from an ISO. Before a new operating system is installed, the server firmware must be updated and a source media with the installation files will need to be made available to the server via a mounted ISO image through the iDRAC virtual media feature.

There are then two ways to install the operating system. The preferred method involves using Lifecycle Controller since it comes with a dedicated OS deployment feature which simplifies the installation by preloading drivers before the installation process. However, if you're using a 9G or 10G Dell server then this won't be possible since the Lifecycle Controller was not released for these iterations. Instead it's possible to use the Systems Management Tools and documentation DVD ISO file to deploy a supported operating system.

#### Boot a server into a custom ISO image

The iDRAC virtual media feature can also be used to boot a server into a custom ISO image located on an SMB share or administrator's workstation. With the virtual media function enabled in iDRAC, you can use an ISO image from your workstation as virtual media on the server. Depending on the version, iDRAC on your server will support Common Internet File System (CIFS) shares or CIFS and HTTP/HTTPS.

There's also another way to run an ISO against a server: to boot it over the network via a PXE server. However this doesn't make use of the virtual media function.

<img alt="A guide to iDRAC's virtual media function" src={__img4} />

#### Mount and unmount driver packs

Sometimes when installing or deploying an operating system on a Dell PowerEdge server, you'll need additional hardware drivers for that operating system to be successfully installed. These drivers can be extracted into a dynamic USB partition labeled OEMDRV. The operating system installer consumes these drivers from the partition during the installation process so that the operating system has the necessary drivers to complete the installation. System administrators can mount or unmount drivers using the virtual media feature within the iDRAC user interface.

For example, here's how to mount drivers in iDRAC9:

* Log into iDRAC
* Go to **Configuration**
* Select **Virtual Media**
* Select the **Mount Drivers** button
* Select the operating system from the drop-down box
* Select **Job Queue** and wait until the job is completed
* Boot your operating system media using Virtual Media
* Install the operating system

<img alt="A guide to iDRAC's virtual media function" src={__img5} />

And here's how to unmount drivers in iDRAC9:

* Log into iDRAC
* Go to **Configuration**
* Select **Virtual media**
* Select **Unmount Drivers** button
* The drivers will be unmounted after the operating system is installed

<img alt="A guide to iDRAC's virtual media function" src={__img6} />

#### Platform bootable ISO for firmware updates

One of the methods available to update a PowerEdge server is to update all system components simultaneously using a custom built platform bootable ISO. A platform specific bootable ISO is designed to perform firmware server component updates on Dell EMC PowerEdge servers in a pre-OS environment.

The ISO carries the firmware update packages needed to update the server. This can be achieved via a few different methods including network location, transferring an ISO on a bootable USB drive, CD-ROM, or through iDRAC virtual media. Via a configured iDRAC, the process can be carried out online within about an hour.

### The round-up

The iDRAC out-of-band management platform is an extremely useful piece of hardware. This piece of kit, which sits on your server's motherboard, facilitates remote access to your server consoles. Within iDRAC, the virtual media feature has multiple use cases, including installing operating systems from the ISO, booting servers into custom ISO images, and mounting and unmounting driver packs. For more product and service information, including detailed guides for our [dedicated servers](https://www.servers.com/products/enterprise-bare-metal), check out our knowledge base.


# How to access the out-of-band management of a Dell server (/docs/tutorials/idrac-setup/how-to-access-oob-management)











Your Dell server's out-of-band management (OOB) platform is called [iDRAC](https://www.dell.com/support/kbdoc/en-us/000179517/dell-poweredge-how-to-configure-the-idrac-system-management-options-on-servers). It is a piece of hardware that sits on the server motherboard and allows system administrators to update and manage their Dell systems, even when the server is turned off.

iDRAC provides both a web interface and command-line interface that allows administrators to perform remote management tasks. Key features include server power management, hardware sensor monitoring, remote console capabilities, and virtual media access. iDRAC also allows for the installation of an operating system to be performed remotely.

For your safety, the out-of-band management network of your servers is hidden behind a VPN. For your convenience, you can temporarily enable access to a specific server's iDRAC interface over the Internet with no VPN connection required.

<img alt="How to access the out-of-band management of a Dell server" src={__img0} />

### Getting VPN credentials to access the OOB network

To access the OOB network, you will need to set up a VPN connection to the VPN gateway. You will find VPN credentials and setup instructions in the "VPN to DRAC" subsection of the "[Profile > VPN access](https://portal.servers.com/#/profile/vpn)" section of the Customer Portal.

After connecting to the OOB network, you can access the iDRAC interface of a specific server by its IP address.

### Getting an IP address of the iDRAC interface for a specific server

Navigate to the "[Dedicated Servers > Manage](https://portal.servers.com/#/servers/my)" section of the Customer Portal. Click the "Details" button next to the server's name. On the server's details page, scroll down to the "OOB" section. There you will find an IP address of your server's iDRAC, belonging to a private IP range.

### Getting credentials for the iDRAC interface of a specific server

Navigate to the "[Dedicated Servers > Manage](https://portal.servers.com/#/servers/my)" section of the Customer Portal. Click the "Details" button next to the server's name. On the server's details page, scroll down to the "OOB" section.

Click "Credentials" next to the server's iDRAC IP address.

### Accessing iDRAC of a specific server without using the VPN

For your convenience, you can temporarily enable access to your server's iDRAC via the Internet and avoid using the VPN. To do that, click "Enable public access for 24 hours" in the "OOB" section of the server's details page.

<img alt="click Enable public access for 24 hours in the OOB section of the server's details page" src={__img1} />

After enabling public access, you will be presented with the server's iDRAC credentials. Public iDRAC access is allowed on a temporary basis. Once enabled, it will last for the next 24 hours, but you can turn it off ahead of schedule.

### Authenticating to iDRAC

Enter the IP address of the iDRAC interface of your server in the address bar of your browser. The browser will warn you about your connection being not secure because of a self-signed HTTPS certificate. Add an exception and continue. Enter previously received iDRAC credentials on the iDRAC authentication page.

<img alt="Enter previously received iDRAC credentials on the iDRAC authentication page" src={__img2} />

After log in, you will be able to control your server settings, view the service tag, use virtual console and mount virtual media from local or remote (SMB) images.

<img alt="use virtual console and mount virtual media from local or remote (SMB) images" src={__img3} />

Refer to Dell's [Remote Enterprise Systems Management website](https://www.dell.com/support/manuals/en-us/idrac9-lifecycle-controller-v4.x-series/idrac9_4.00.00.00_ug_new/overview-of-idrac?guid=guid-a03c2558-4f39-40c8-88b8-38835d0e9003\&lang=en-us) for the iDRAC documentation and instructions.


# How to configure iDRAC to use the HTML5 plug-in for virtual console (/docs/tutorials/idrac-setup/how-to-configure-idrac-html5-plugin)



Your Dell server's out-of-band management (OOB) platform is called [iDRAC](https://www.dell.com/support/kbdoc/en-us/000179517/dell-poweredge-how-to-configure-the-idrac-system-management-options-on-servers). It is a piece of hardware that sits on the server motherboard and allows system administrators to update and manage their Dell systems, even when the server is turned off. Key features include server power management, remote console capabilities, and virtual media access.

### iDRAC versions and virtual console plug-in types

iDRAC allows you to switch between Java, ActiveX and HTML5-based plugins for virtual console capabilities and virtual media access. The HTML5 plug-in is the default plug-in in iDRAC 9. iDRAC versions 7 and 8 initially had support for Java and ActiveX. HTML5 support was added in the firmware [version 2.30.30.30](https://www.dell.com/support/manuals/en-us/poweredge-r730xd/idrac8_2.30.30.30_ug/new-in-this-release?guid=guid-2db3a472-a436-445d-9d3c-fe5d4650fc8a\&lang=en-us).

The majority of our DELL PowerEdge servers are of the 14th, 13th, and 12th generations, meaning iDRAC versions vary from iDRAC 9 to iDRAC 7.

| Server Model Number | Server Generation | iDRAC Version | HTML5 Plug-in Support | Launching Virtual Console                                                                                                                                                                               |
| ------------------- | ----------------- | ------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Rx4x                | 14th              | iDRAC 9       | Out of the box        | [User Guide](https://www.dell.com/support/manuals/en-al/dell-xc6420/idrac9_4.00.00.00_ug_new/launching-virtual-console?guid=guid-5133c6e4-6b90-4db6-9273-0aaaef5ec625\&lang=en-us)                      |
| Rx3x                | 13th              | iDRAC 8       | Since FW 2.30.30.30   | [User Guide](https://www.dell.com/support/manuals/en-us/poweredge-r730xd/idrac8_2.30.30.30_ug/launching-virtual-console-using-web-interface?guid=guid-964c38e2-ed24-4918-8732-3f3319cb584c\&lang=en-us) |
| Rx2x                | 12th              | iDRAC 7       | Since FW 2.30.30.30   | [User Guide](https://www.dell.com/support/manuals/en-us/poweredge-r730xd/idrac8_2.30.30.30_ug/launching-virtual-console-using-web-interface?guid=guid-964c38e2-ed24-4918-8732-3f3319cb584c\&lang=en-us) |

Please refer to "[How to identify the iDRAC version embedded in a Dell EMC PowerEdge server](https://www.dell.com/support/kbdoc/en-us/000177885/how-to-identify-the-idrac-version-of-your-dell-poweredge-server)" for the article helping to identify the iDRAC version. Please refer to "[How to update iDRAC](/tutorials/idrac-setup/how-to-update-idrac)" for the article helping to update iDRAC firmware.

### Setting the HTML5 plug-in for virtual console

Please refer to "[Configuring virtual console using web interface](https://www.dell.com/support/manuals/en-us/poweredge-r730xd/idrac8_2.30.30.30_ug/configuring-virtual-console-using-web-interface?guid=guid-f5f1daed-d78d-408c-ae6a-910044556cb0\&lang=en-us)" for the article helping to configure virtual console on iDRAC 7 & 8. Select plug-in type to "HTML5" in the **Plug-in** field.


# How to perform diagnostics on servers with iDRAC LifeCycle Controller (/docs/tutorials/idrac-setup/how-to-perform-diagnostics-idrac-lifecycle-controller)



















Before running the test, you need to clear the iDRAC logs. To do this, open the iDRAC web interface, go to the sub-item Logs and click the "Clear Log" button in the System Event Log area. This is necessary so that during the hardware test, the Hardware Diagnostics utility would not notify you of errors in logs.

<img alt="How to perform diagnostics on servers with iDRAC LifeCycle Controller" src={__img0} />

In order to check physical hardware on the Dell server, you must connect to the iDRAC server. The test will be performed using Hardware Diagnostics in LifeCycle Controller menu. To start LifeCycle Controller, you need to select the Next Boot tab, then LifeCycle Controller, restart the server using macros "Ctrl + Alt + Delete".

<img alt="How to perform diagnostics on servers with iDRAC LifeCycle Controller" src={__img1} />

You can also boot into LifeCycle Controller by pressing the F10 key when BIOS POST screen is shown.

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img2} />

After booting into LifeCycle menu, you need to select Hardware Diagnostics and initiate Run Hardware Diagnostics.

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img3} />

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img4} />

After clicking the "Yes" button, the hardware components check will initiate.

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img5} />

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img6} />

After the scan is completed, an extended memory test will be prompted. If you want to perform an extended memory test, select "Yes".

<img alt="Diagnostics on servers with iDRAC LifeCycle Controller" src={__img7} />


# How to update iDRAC (/docs/tutorials/idrac-setup/how-to-update-idrac)















Before the update, you must check the current firmware version. To do this, connect to iDRAC, go to **Overview** → **Server** → **Properties** → **Summary**. In the **Firmware Version** field, you can see the current firmware version. The field **Service Tag** is the serial number of the server, which you will need to proceed.

<img alt="How to update iDRAC" src={__img0} />

You can find the up-to-date firmware version at [support.dell.com](https://support.dell.com). In the **Enter a Service Tag or other product ID** field, type [Service Tag](/tutorials/idrac-setup/locating-service-tags) and click **Submit**:

<img alt="How to update iDRAC" src={__img1} />

On the next page, you will see the information about the server. In the left box you need to select the section **Drivers & downloads**, find the item **iDRAC with Lifecycle Controller** where you can find the up-to-date iDRAC firmware. After clicking **Download**, the download will begin.

<img alt="How to update iDRAC" src={__img2} />

After the download is complete, you need to go to **iDRAC Settings** → **Update and Rollback**. In this section, you must select the firmware file and click **Upload**.

<img alt="How to update iDRAC" src={__img3} />

After uploading the firmware to iDRAC, the **Update Details** window will appear. Tick the downloaded firmware and click **Install**.

<img alt="How to update iDRAC" src={__img4} />

Status updates appear at **Overview** → **Server** → **Job Queue**. After the successful update of the firmware, iDRAC will automatically restart. After reconnecting to iDRAC, you can see that it has been successfully updated.

<img alt="How to update iDRAC" src={__img5} />


# iDRAC setup (/docs/tutorials/idrac-setup)



This section covers essential guides for setting up and managing the iDRAC (Integrated Dell Remote Access Controller) on your Dell dedicated servers. iDRAC is a piece of dedicated hardware embedded in the server motherboard that enables remote server management, hardware monitoring, virtual console access, and virtual media functionality — even when the server operating system is offline.

Here you will find guides on accessing the OOB management interface, configuring the virtual console, updating iDRAC firmware, working with virtual media, running hardware diagnostics via the LifeCycle Controller, and locating your server's service tag.


# Locating service tags of a server and using it to look up information (/docs/tutorials/idrac-setup/locating-service-tags)







Service Tag is a unique identifier of a Dell server. You can use the service tag to view server specs and look up documentation, drivers & downloads for a specific product on Dell's [Support website](https://www.dell.com/support/home/en-us).

<img alt="Service Tag is a unique identifier of a Dell server" src={__img0} />

### Locating the service tag of a server

The service tag of a server is displayed in the web interface of its iDRAC, which is Dell's out-of-band management platform. See [How to access the out-of-band management interface of a Dell server called iDRAC](/tutorials/idrac-setup/how-to-access-oob-management) for details.

<img alt="How to access the out-of-band management interface of a Dell server called iDRAC" src={__img1} />


# iDRAC VPN access (/docs/tutorials/idrac-vpn-access)



This section contains step-by-step guides for connecting to your Dell server's iDRAC interface using a secure L2TP over IPsec VPN connection. By default, iDRAC access is protected behind a VPN to prevent unauthorized access to out-of-band management.

We provide setup guides covering all major operating systems and distributions, including macOS, Windows, and multiple versions of Ubuntu and Fedora Linux. Each guide walks you through finding your VPN credentials in the Customer Portal, installing the required packages, configuring the VPN connection, and adding the necessary routes to reach the iDRAC network.


# How to setup L2TP over IPsec for iDRAC on Linux Fedora 24 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-24)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via a VPN. This guide explains how to access iDRAC using a VPN.

Alternatively, if necessary, you can enable temporary public access to the iDRAC interface, allowing access without a VPN. This can be activated in the [Customer Portal](https://portal.servers.com/login) on the **server details page** under the **OOB** section by selecting **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC** section
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo dnf update
   ```
2. Install the required packages:
   ```
   sudo dnf install NetworkManager-l2tp NetworkManager-l2tp-gnome libreswan xl2tpd
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Configure VPN connection

1. Open **Settings** → **Network** and click the "+" symbol under the list of network connections
2. Choose **VPN** → **Layer 2 Tunneling Protocol (L2TP)**
3. In the VPN connection settings, go to the **Identity** tab and enter the following details:
   * Name (e.g. VPN Test)
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com):
     * Gateway: VPN server
     * Username: login
     * Password: password
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
4. In the same window, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Pre-shared key** (use the shared secret from the [Customer Portal](https://portal.servers.com))
   * Leave the rest of the fields blank
5. Go to the **IPv4** tab and scroll down to the **Routes** section:
   * Add the following routes by clicking the "+" button: `198.18.0.0` and `100.64.0.0`
   * Click **Add** to save the connection
6. Turn on your VPN connection

Once the VPN connection is established, you can access your iDRAC using the IP address specified on the server's details page in the Customer Portal.

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the [Customer Portal](https://portal.servers.com/login):

1. Navigate to **Dedicated Servers** → **Manage** → Your server → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# Connecting to iDRAC VPN by using L2TP over IPsec on Fedora Linux 30 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-30)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via a VPN. This guide explains how to access iDRAC using a VPN.

Alternatively, if necessary, you can enable temporary public access to the iDRAC interface, allowing access without a VPN. This can be activated in the [Customer Portal](https://portal.servers.com/login) through the server details page under the **OOB** section by selecting **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours, but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials for setting up a VPN connection to the OOB network and instructions are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC** section
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo dnf update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo dnf install NetworkManager-l2tp NetworkManager-l2tp-gnome -y
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu
2. In the **Settings** window, navigate to the **Network** tab and click the **+** button next to the VPN label to add a new VPN connection
3. Choose **Layer 2 Tunneling Protocol (L2TP)**
4. In the VPN connection settings, go to the **Identity** tab and enter:
   * Name (e.g. VPN1)
   * Login credentials obtained from the Customer Portal:
     * Gateway: VPN server
     * Username: login
     * Password: password
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
5. In the same tab, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **shared secret** obtained from the Customer Portal in the **Pre-shared key** input field
   * Optionally click **Legacy Proposals** to auto-fill fields or manually specify encryption methods. Example configuration:
     * Set **Phase1 Algorithms** to `aes128-sha1-modp2048`
     * Set **Phase2 Algorithms** to `aes128-sha1`
   * Tick **Disable PFS**, then click **OK**
6. Navigate to the **IPv4** tab and scroll down to **Routes**:
   * Add the following routes:
     * `198.18.0.0`
     * `100.64.0.0`
   * Click **Apply** to save the settings
7. Ensure your newly created VPN connection is turned on

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the [Customer Portal](https://portal.servers.com/login):

1. Navigate to **Dedicated Servers** → **Manage** → Your server → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Linux Fedora 41 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-fedora-41)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via VPN.

If necessary, you can also allow access without VPN by enabling temporary public access to the iDRAC interface. This can be activated in the Customer Portal on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the Customer Portal. To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo dnf update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo dnf install NetworkManager-l2tp NetworkManager-l2tp-gnome -y
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu
2. In the **Settings** window, navigate to the **Network** tab and click the **+** button next to the **VPN** label to add a new VPN connection
3. Choose **Layer 2 Tunneling Protocol (L2TP)**
4. In the VPN connection settings, go to the **Identity** tab and enter the following details:
   * Name (e.g. VPN1)
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * Gateway: VPN server
     * User name: login
     * Password: password
   * Click the **User symbol** in the password input field and select **Store the password only for this user**
5. In the same tab, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Shared secret** obtained from the [Customer Portal](https://portal.servers.com/) in the **Pre-shared key** input field
   * Optionally click **Advanced** and manually specify encryption methods. A full list of [supported tunnel options](/vpn2gpn/tunnel-options-for-vpn-to-gpn-connection) is available.
   * Tick **Disable PFS**, then click **OK**
   * Click **Apply** to save the settings
6. Navigate to the **IPv4** tab and scroll down to **Routes**:
   * Disable automatic route detection by toggling the **Automatic** switch
   * Add the following routes: `198.18.0.0` and `100.64.0.0`
   * Click **Apply** to save the settings
7. In the **Shortcuts** menu, turn on your newly created VPN connection and verify in **Settings** that the VPN connection is active

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the **Customer Portal**:

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 16.04 and 16.10 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-16-04)





The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via a VPN.

If necessary, you can allow access without a VPN by enabling temporary public access to the iDRAC interface. This can be activated in the [Customer Portal](https://portal.servers.com/login) on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the out-of-band (OOB) network are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installation

1. Update the list of available packages:
   ```
   sudo apt update
   ```
2. Install the required packages:
   ```
   sudo apt install intltool libtool git network-manager-dev libnm-util-dev libnm-glib-dev libnm-glib-vpn-dev libnm-gtk-dev libnm-dev libnma-dev ppp-dev strongswan libdbus-glib-1-dev libsecret-1-dev libgtk-3-dev libglib2.0-dev xl2tpd
   ```
3. Reinstall Network Manager:
   ```
   git clone https://github.com/nm-l2tp/network-manager-l2tp.git
   cd network-manager-l2tp
   autoreconf -fi
   intltoolize
   ./configure --disable-static --prefix=/usr --sysconfdir=/etc --libdir=/usr/lib/x86_64-linux-gnu --libexecdir=/usr/lib/NetworkManager --localstatedir=/var --with-pppd-plugin-dir=/usr/lib/pppd/2.4.7
   make
   sudo make install
   ```
4. Remove AppArmor IPsec settings:
   ```
   sudo apparmor_parser -R /etc/apparmor.d/usr.lib.ipsec.charon
   sudo apparmor_parser -R /etc/apparmor.d/usr.lib.ipsec.stroke
   ```
5. Replace `xl2tpd` with `libcap`:
   ```
   sudo apt remove xl2tpd
   sudo apt install libpcap0.8-dev

   wget https://github.com/xelerance/xl2tpd/archive/v1.3.6/xl2tpd-1.3.6.tar.gz
   tar xvzf xl2tpd-1.3.6.tar.gz
   cd xl2tpd-1.3.6
   make
   sudo make install
   ```
6. Reboot your system:
   ```
   sudo reboot
   ```

Now your Network Manager can create L2TP connections.

### Setting up a new VPN connection

1. In the Network Manager, select **Edit Connections**, then add a new VPN connection of type **L2TP**
2. Enter the connection details using credentials obtained from the Customer Portal
3. Click **Routes** and add the following routes to enable access to the iDRAC network:
   * `198.18.0.0/15`
   * `100.64.0.0/15`

<img alt="Routes configured to enable access to the iDRAC network" src={__img0} />

Now you can establish a VPN connection and access iDRAC.


# How to setup L2TP over IPsec for iDRAC on Linux Ubuntu 16.10 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-16-10)



Please refer to [How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 16.04 and 16.10](/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-16-04) for instructions on setting up L2TP over IPsec for iDRAC on Ubuntu 16.10. The steps are identical for both Ubuntu 16.04 and Ubuntu 16.10.


# How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 18.04 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-18-04)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via VPN.

If necessary, you can also allow access without VPN by enabling temporary public access to the iDRAC interface. This can be activated in the Customer Portal on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo apt update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo apt install -y network-manager-l2tp network-manager-l2tp-gnome
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu
2. In the settings window, navigate to the **Network** tab and click the **+** button next to the VPN label to add a new VPN connection
3. Choose **Layer 2 Tunneling Protocol (L2TP)**
4. In the **VPN connection settings**, go to the **Identity** tab and enter the following details:
   * Name (e.g., VPN1)
   * Login credentials obtained from the Customer Portal:
     * Gateway: VPN server
     * Username: login
     * Password: password
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
5. In the same window, click the **IPsec Settings** button:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Shared secret** obtained from the Customer Portal in the **Pre-shared key** input box
   * Leave the **Phase1 Algorithms** and **Phase2 Algorithms** fields blank or manually enter the specific encryption methods. Example configuration:
     * Set Phase1 Algorithms to `aes128-sha1-modp2048`
     * Set Phase2 Algorithms to `aes128-sha1`
   * Click **OK** to save the settings
6. Navigate to the **IPv4** tab and scroll down to the **Routes** section:
   * Disable automatic route detection by toggling the **Automatic** switch
   * Add the following routes:
     * `198.18.0.0/15`
     * `100.64.0.0/15`
   * Click **Apply** to save the settings
7. Ensure your newly created VPN connection is turned on

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the [Customer Portal](https://portal.servers.com/login):

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 20.04 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-20-04)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via VPN.

If necessary, you can also allow access without a VPN by enabling temporary public access to the iDRAC interface. This can be activated in the **Customer Portal** on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, the public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the **Customer Portal**. To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo apt update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo apt install -y network-manager-l2tp network-manager-l2tp-gnome
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu and navigate to **Network**
2. Click the **+** button next to the **VPN** label to add a new VPN connection and select **Layer 2 Tunneling Protocol (L2TP)**
3. In the VPN connection settings, go to the **Identity** tab and enter the following details:
   * Name (e.g. VPN2iDRAC)
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * Gateway: VPN server
     * User name: login
     * Password: password
4. In the same tab, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Shared key** obtained from the [Customer Portal](https://portal.servers.com/login) in the **Pre-shared key** input box
   * Click **OK**
5. Go to the **IPv4** tab and scroll down to the **Routes** section:
   * Disable automatic route detection by toggling the **Automatic** switch
   * Add the following routes: `198.18.0.0/15` and `100.64.0.0/15`
   * Click **Add**
6. Turn on your newly created VPN connection

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the **Customer Portal**:

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 22.04 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-22-04)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via VPN.

If necessary, you can also allow access without VPN by enabling temporary public access to the iDRAC interface. This can be activated in the **Customer Portal** on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the **Customer Portal**. To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo apt update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo apt install -y network-manager-l2tp network-manager-l2tp-gnome
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu and navigate to **Network**
2. Click the **+** button next to the **VPN** label to add a new VPN connection and select **Layer 2 Tunneling Protocol (L2TP)**
3. In the VPN connection settings, go to the **Identity** tab and enter the following details:
   * Name (e.g. VPN2iDRAC)
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * Gateway: VPN server
     * User name: login
     * Password: password
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
4. In the same tab, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Shared key** obtained from the **Customer Portal** in the **Pre-shared key** input box
   * Click **OK**
   * Optionally, click **Advanced** and specify encryption methods. Example configuration:
     * Set **Phase1 Algorithms** to `aes128-sha1-modp2048`
     * Set **Phase2 Algorithms** to `aes128-sha1`
5. Go to the **IPv4** tab and scroll down to the **Routes** section:
   * Disable automatic route detection by toggling the **Automatic** switch
   * Add the following routes: `198.18.0.0/15` and `100.64.0.0/15`
   * Click **Add**
6. Turn on your newly created VPN connection

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the **Customer Portal**:

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Linux Ubuntu 24.04 (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-linux-ubuntu-24-04)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via a VPN.

If necessary, you can also allow access without a VPN by enabling temporary public access to the iDRAC interface. This can be activated in the **Customer Portal** on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the **Customer Portal**. To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Installing required packages

1. Update the package information to retrieve the latest versions and dependencies:
   ```
   sudo apt update
   ```
2. Install the L2TP plugin for NetworkManager:
   ```
   sudo apt install -y network-manager-l2tp network-manager-l2tp-gnome
   ```
3. Restart your system:
   ```
   sudo reboot
   ```

### Setting up a new VPN connection

1. Click the **Settings** button in the shortcuts menu and navigate to **Network**
2. Click the **+** button next to the **VPN** label to add a new VPN connection and select **Layer 2 Tunneling Protocol (L2TP)**
3. In the VPN connection settings, go to the **Identity** tab and enter the following details:
   * Connection name (e.g. VPN2iDRAC)
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * Gateway: VPN server
     * User name: login
     * Password: password
   * Click the **user symbol** in the password input field and select **Store the password only for this user**
4. In the same tab, click **IPsec Settings**:
   * Tick **Enable IPsec tunnel to L2TP host**
   * Enter the **Shared key** obtained from the **Customer Portal** in the **Pre-shared key** input box
   * Optionally click **Advanced** and manually specify the encryption methods. A full list of [supported tunnel options](/vpn2gpn/tunnel-options-for-vpn-to-gpn-connection) is available.
   * Click **Apply** to save the settings
5. Go to the **IPv4** tab and scroll down to the **Routes** section:
   * Disable automatic route detection by toggling the **Automatic** switch
   * Add the following routes: `198.18.0.0/15` and `100.64.0.0/15`
   * Click **Apply** to save the settings
6. Turn on your newly created VPN connection

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the **Customer Portal**:

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on Mac OS X (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-mac-os-x)







The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface is provided via a VPN.

If necessary, you can also allow access without a VPN by enabling temporary public access to the iDRAC interface. This can be activated in the [Customer Portal](https://portal.servers.com/login) on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the out-of-band (OOB) network are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Configure VPN connection

1. Go to **System Settings** → **Network**
2. Click **Add VPN Configuration** → **L2TP over IPSec**

<img alt="Adding a VPN configuration in macOS Network settings" src={__img0} />

3. In the opened window, enter the following details:
   * Connection name (e.g. `iDRAC VPN`)
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * VPN server: server address
     * Login: account name
     * Password: password
     * Shared Secret: shared secret

4. Click **Create**

5. Enable the **toggle switch** to connect to the newly created VPN:

<img alt="Enabling the toggle switch to connect to the newly created VPN" src={__img1} />

6. Once the VPN connection is established, add the necessary routes by executing the following command in the Terminal:

   ```
   sudo route -n add 198.18.0.0/15 -interface ppp0  
   sudo route -n add 100.64.0.0/15 -interface ppp0
   ```

   Note: this command must be executed each time you connect to the VPN.

7. To simplify this process, you can create a **bash alias**. To add a bash alias:
   * Add the following line at the end of the `~/.bash_profile` file:
     ```
     alias drac='sudo route -n add 198.18.0.0/15 -interface ppp0 ; sudo route -n add 100.64.0.0/15 -interface ppp0'
     ```
   * Apply the changes:
     ```
     source ~/.bash_profile
     ```

Now, you can simply run the `drac` command to add the required route.

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the [Customer Portal](https://portal.servers.com/login):

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to set up L2TP over IPsec for iDRAC on MS Windows (/docs/tutorials/idrac-vpn-access/l2tp-ipsec-idrac-ms-windows)



The integrated out-of-band management platform on Dell servers is called [iDRAC](https://en.wikipedia.org/wiki/Dell_DRAC). By default, access to the iDRAC interface of your servers is provided via a VPN.

If necessary, you can also allow access without a VPN by enabling temporary public access to the iDRAC interface. This can be activated in the [Customer Portal](https://portal.servers.com/login) on the server details page under the **OOB** section. Simply select **Enable public access for 24 hours**. Once activated, public access remains enabled for the next 24 hours but can be manually disabled at any time.

For security reasons, VPN access remains the preferred method and should be used whenever possible.

### Finding VPN credentials

Credentials and instructions for setting up a VPN connection to the OOB network are available in the [Customer Portal](https://portal.servers.com/login). To access them:

1. Navigate to **Networks** → **VPN access** → **VPN to DRAC**
2. Select the location and click **Credentials**
3. In the opened window, you will find the credentials

### Setting up a new VPN connection

1. Go to **Start** → **Settings**

2. Choose **Network & Internet**

3. Navigate to the **VPN** tab and click **Add a VPN connection**

4. In the opened window, enter the following details:
   * VPN provider: choose **Windows (built-in)**
   * VPN type: choose **L2TP/IPsec** with pre-shared key
   * Connection name: e.g., VPN iDRAC
   * Login credentials obtained from the [Customer Portal](https://portal.servers.com/):
     * Server name or address: VPN server
     * Pre-shared key: shared secret
     * Username: login
     * Password: password

5. Click **Save**

### Enable additional security protocols

1. In the VPN tab, click **Change adapter options** in the **Related settings** section
2. Find the adapter with the same name as your VPN connection and click **Change settings of this connection**
3. In the connection properties window:
   * On the **Security** tab:
     * Enable **Allow these protocols**
     * Ensure that only **Challenge Handshake Authentication Protocol (CHAP)** and **Microsoft CHAP Version 2 (MS-CHAP v2)** are enabled
   * On the **Networking** tab:
     * Select **IPv4 protocol** and open its properties using the **Properties** button
     * Click **Advanced**, then untick the **Use default gateway on remote network** checkbox
   * Click **OK** to save settings and close all open windows

### Connect to VPN and add routes to iDRAC network

1. Go to **Start** → **Settings** → **Network & Internet** → **VPN**
2. Find your VPN connection and click **Connect**
3. Once the VPN connection is established, add the routes to the iDRAC's network:
   * Go to **Start**, type `cmd` and open **Command Prompt** as Administrator
   * Execute the following command to get the VPN network adapter ID:
     ```
     route print
     ```
   * Scroll to the **Interfaces List** block and find your VPN adapter and its ID
   * Execute the following commands to add routes:
     ```
     route add 198.18.0.0 mask 255.254.0.0 0.0.0.0 if your_adapter_ID
     route add 100.64.0.0 mask 255.254.0.0 0.0.0.0 if your_adapter_ID
     ```
     Replace `your_adapter_ID` with the actual ID you obtained in the previous step.

Now you should be able to connect to iDRAC on your server.

### Finding iDRAC credentials

The IP address and credentials for an individual server's iDRAC interface can be found in the [Customer Portal](https://portal.servers.com/login):

1. Navigate to **Dedicated Servers** → **Manage** → **Your server** → **Details**
2. Scroll to the **OOB** section and click **Credentials**


# How to install Munin on Ubuntu and CentOS (/docs/tutorials/monitoring/how-to-install-munin-on-ubuntu-and-centos)



Munin is a free monitoring system that allows you to collect data from multiple servers and display it in graphs. This article covers installation and basic configuration on both Ubuntu and CentOS.

### Architecture

Munin uses a master/node model:

* **munin** (master): collects data and generates graphs/HTML reports.
* **munin-node**: runs on each monitored server and exposes metrics.

### Installing on Ubuntu/Debian

#### Install the master and node

```bash
sudo apt-get update
sudo apt-get install munin munin-node
```

#### Configure the node

Edit `/etc/munin/munin-node.conf` and make sure the master is allowed to connect:

```
allow ^127\.0\.0\.1$
allow ^::1$
# Add your master IP if it's a remote server:
# allow ^203\.0\.113\.10$
```

#### Configure the master

Edit `/etc/munin/munin.conf` and add the hosts to monitor:

```
[localhost]
    address 127.0.0.1
    use_node_name yes

[remote-server]
    address 203.0.113.20
    use_node_name yes
```

#### Start services

```bash
sudo service munin-node start
sudo update-rc.d munin-node enable
```

Munin master runs via cron (every 5 minutes by default). Graphs are generated in `/var/cache/munin/www/`.

### Installing on CentOS

#### Add the EPEL repository

```bash
sudo yum install epel-release
```

#### Install packages

```bash
sudo yum install munin munin-node
```

#### Configure the node

Edit `/etc/munin/munin-node.conf`:

```
allow ^127\.0\.0\.1$
```

#### Configure the master

Edit `/etc/munin/munin.conf`:

```
[localhost]
    address 127.0.0.1
    use_node_name yes
```

#### Start and enable services

```bash
sudo service munin-node start
sudo chkconfig munin-node on
```

### Accessing the web interface

Set up a web server (Apache or Nginx) to serve `/var/cache/munin/www/`. For Apache on Ubuntu:

```bash
sudo apt-get install apache2
```

Munin includes an Apache config at `/etc/munin/apache24.conf` — symlink it:

```bash
sudo ln -s /etc/munin/apache24.conf /etc/apache2/conf-enabled/munin.conf
sudo service apache2 restart
```

Then browse to `http://your-server-ip/munin`.


# How to install Zabbix on CentOS 6.8 and Ubuntu 12.04 (/docs/tutorials/monitoring/how-to-install-zabbix-on-centos-6-8-and-ubuntu-12-04)



Zabbix is an enterprise-grade open-source monitoring solution for networks, servers, and applications. This guide covers installing the Zabbix server and agent on CentOS 6.8 and Ubuntu 12.04.

### Installing Zabbix on CentOS 6.8

#### Step 1: Add the Zabbix repository

```bash
rpm -ivh http://repo.zabbix.com/zabbix/2.4/rhel/6/x86_64/zabbix-release-2.4-1.el6.noarch.rpm
```

#### Step 2: Install Zabbix server, frontend, and agent

```bash
yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent
```

#### Step 3: Create the database

```bash
mysql -u root -p
```

In the MySQL shell:

```sql
CREATE DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;
GRANT ALL PRIVILEGES ON zabbix.* TO zabbix@localhost IDENTIFIED BY 'your_password';
FLUSH PRIVILEGES;
EXIT;
```

#### Step 4: Import the initial schema

```bash
zcat /usr/share/doc/zabbix-server-mysql-*/create.sql.gz | mysql -u zabbix -p zabbix
```

#### Step 5: Configure the Zabbix server

Edit `/etc/zabbix/zabbix_server.conf`:

```
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=your_password
```

#### Step 6: Start services

```bash
service zabbix-server start
service zabbix-agent start
service httpd start
chkconfig zabbix-server on
chkconfig zabbix-agent on
```

### Installing Zabbix on Ubuntu 12.04

#### Step 1: Add the Zabbix repository

```bash
wget http://repo.zabbix.com/zabbix/2.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_2.4-1+precise_all.deb
dpkg -i zabbix-release_2.4-1+precise_all.deb
apt-get update
```

#### Step 2: Install packages

```bash
apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-agent
```

#### Step 3: Create the database

```bash
mysql -u root -p
```

```sql
CREATE DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;
GRANT ALL PRIVILEGES ON zabbix.* TO zabbix@localhost IDENTIFIED BY 'your_password';
FLUSH PRIVILEGES;
EXIT;
```

#### Step 4: Import schema

```bash
zcat /usr/share/doc/zabbix-server-mysql/create.sql.gz | mysql -u zabbix -p zabbix
```

#### Step 5: Configure and start

Edit `/etc/zabbix/zabbix_server.conf` with your DB credentials, then:

```bash
service zabbix-server start
service zabbix-agent start
```

### Accessing the web frontend

Navigate to `http://your-server-ip/zabbix` and complete the setup wizard. Default credentials: `Admin` / `zabbix`.


# Monitoring (/docs/tutorials/monitoring)



Knowing what is happening on your servers in real time is essential for maintaining stability and performance. This section covers three widely-used open-source monitoring tools — Monit for lightweight process supervision, Zabbix for enterprise-grade infrastructure monitoring, and Munin for long-term metrics graphing.

### Explore monitoring instructions

<Cards>
  <Card title="Monit on Ubuntu/Debian" description="Set up lightweight process monitoring and auto-restart with Monit." href="/tutorials/monitoring/using-monit-process-monitoring-on-ubuntu-debian" />

  <Card title="Zabbix on CentOS and Ubuntu" description="Install and configure Zabbix server for full infrastructure monitoring." href="/tutorials/monitoring/how-to-install-zabbix-on-centos-6-8-and-ubuntu-12-04" />

  <Card title="Munin on Ubuntu and CentOS" description="Collect and graph server metrics across multiple nodes with Munin." href="/tutorials/monitoring/how-to-install-munin-on-ubuntu-and-centos" />
</Cards>


# Using Monit process monitoring on Ubuntu/Debian (/docs/tutorials/monitoring/using-monit-process-monitoring-on-ubuntu-debian)



Monit is an open-source monitoring tool for Linux operating systems. This article guides you through a basic Monit setup on Ubuntu/Debian.

### Installation

```bash
sudo apt-get update
sudo apt-get install monit
```

### Configuration

The main configuration file is located at `/etc/monit/monitrc`. Open it for editing:

```bash
sudo nano /etc/monit/monitrc
```

#### Enable the web interface

Uncomment and adjust the following lines to enable the HTTP status interface:

```
set httpd port 2812 and
    use address localhost
    allow localhost
    allow admin:monit
```

Change `admin:monit` to a username and password of your choice.

#### Monitor a process

Add a service check block. For example, to monitor nginx:

```
check process nginx with pidfile /var/run/nginx.pid
  start program = "/etc/init.d/nginx start"
  stop program  = "/etc/init.d/nginx stop"
  if failed host 127.0.0.1 port 80 protocol http then restart
  if 5 restarts within 5 cycles then timeout
```

#### Monitor system resources

```
check system localhost
  if loadavg (1min) > 4 then alert
  if memory usage > 75% then alert
  if cpu usage (user) > 70% then alert
```

### Starting Monit

```bash
sudo service monit start
sudo update-rc.d monit enable
```

### Useful commands

```bash
# Check Monit status
sudo monit status

# Test configuration syntax
sudo monit -t

# Reload configuration
sudo monit reload

# Stop a monitored service
sudo monit stop nginx

# Start a monitored service
sudo monit start nginx
```

### Accessing the web interface

Open a browser and navigate to:

```
http://your-server-ip:2812
```

Log in with the credentials configured in `monitrc`.


# How to disaggregate network interfaces on a Proxmox server (/docs/tutorials/networking-and-ip-management/how-to-disaggregate-network-interfaces-on-a-proxmox-server)



This article covers the steps for link disaggregation on a Proxmox server. The process consists of actions performed both on the Proxmox server side and on the network switch side.

Link disaggregation (splitting a bonded/LACP interface back into individual interfaces) may be needed when you want to assign separate network interfaces to different VMs or services rather than having them share a bond.

## Prerequisites

* Access to the Proxmox web interface and the host shell.
* Access to the network switch configuration.
* A maintenance window — network will be briefly interrupted.

## Step 1: Note current network configuration

Log in to the Proxmox shell and inspect the current interface config:

```bash
cat /etc/network/interfaces
ip link show
```

Note which physical interfaces are part of the current bond (e.g., `bond0` using `eno1` and `eno2`).

## Step 2: Reconfigure the switch port

On the switch, change the port configuration from LACP/802.3ad (trunk) to individual access ports. The exact steps depend on your switch vendor — consult the switch documentation.

## Step 3: Update `/etc/network/interfaces` on Proxmox

Remove or comment out the bond configuration and define each interface separately. Example — original bond config:

```
auto bond0
iface bond0 inet manual
    bond-slaves eno1 eno2
    bond-mode 802.3ad

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
```

Disaggregated config:

```
auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

auto vmbr1
iface vmbr1 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0
```

## Step 4: Apply the new configuration

From the Proxmox web UI, go to **Node → Network** and click **Apply Configuration**. Alternatively, from the shell (expect a brief reconnection):

```bash
sudo ifreload -a
```

## Step 5: Verify

Confirm both interfaces are up and the bond is gone:

```bash
ip link show
brctl show
```

Assign `vmbr1` to any VMs or services that should use the second physical interface.


# How to order an additional IP network for a Dedicated Server (/docs/tutorials/networking-and-ip-management/how-to-order-additional-ip-network)



Additional IP addresses or networks are often used to host multiple services or to implement custom routing and firewall configurations. This article explains how to order them for your dedicated server.

## Order additional IP addresses for a dedicated server

To order additional IP addresses:

1. Log in to the Customer Portal, navigate to **Dedicated Servers** → **Manage**, and select your server

2. Scroll to the **Networks** section and click **Add Network**

3. In the **Network type** dropdown, select **Public IP**

4. Choose the **/32** network size

   A `/32` network represents a single IP address, not a range. It is used to assign an individual IP alias to an existing network interface without allocating a subnet, gateway, or broadcast address.

5. In the **Quantity** field, select the number of IP addresses to add

6. Click **Add**

The additional IP addresses will be provisioned within approximately five minutes.

## Order additional networks

On Windows servers, only alias IP addresses can be allocated. Ordering a full public subnet is not supported.

To add a new network:

1. Log in to the Customer Portal, navigate to **Dedicated Servers** → **Manage**, and select your server
2. Scroll to the **Networks** section and click **Add Network**
3. In the **Network type** dropdown, choose one of the following:
   * Public IP
   * Private IP
   * Public IPv6 (can be assigned to a server only once; not available in locations with reduced redundancy)
4. Select the desired subnet size (for example, /26, /27, /28, etc.)
5. Click **Add**

The new network will be provisioned within approximately five minutes.

## Network sizes and reserved service addresses

The available network sizes depend on the type of location and the network architecture at that location. CIDR notation is used to designate blocks of IP addresses and subnet masks.

For example, a /29 prefix means the subnet contains eight IP addresses: 5 can be assigned to user devices and infrastructure devices, 1 is reserved for the network address, 1 for the gateway, and 1 for the broadcast address.

You can order IPv4 subnets of the following sizes:

| Network size | Total number of IPs | Usable IPs (standard location) | Usable IPs (reduced redundancy location) |
| ------------ | ------------------- | ------------------------------ | ---------------------------------------- |
| /32          | 1                   | 1                              | 1                                        |
| /30          | 4                   | unavailable                    | 1                                        |
| /29          | 8                   | 3                              | 5                                        |
| /28          | 16                  | 11                             | 13                                       |
| /27          | 32                  | 27                             | 29                                       |
| /26          | 64                  | 59                             | 61                                       |


# How to point your domain name to a dedicated server's IP address (/docs/tutorials/networking-and-ip-management/how-to-point-domain-to-dedicated-server-ip)



To point your domain name to your dedicated server's public IP address, you need to create an address record for the domain — an A record. An A record is part of the DNS system and maps a domain name to an IP address.

An A record is stored as a DNS entry on the domain's name servers. To add an A record for your domain, you can use your domain registrar's name servers or switch to the name servers provided by [Servers.com](https://www.servers.com).

## Creating an A record using name servers of a domain name registrar

Before you can add an A record for your domain, find the public IP address of your server in the **Dedicated Servers** → **Manage** section of the Customer Portal.

Use the obtained IP address to add an A record for your domain by following the instructions provided by your domain's registrar. Here are the links to instructions by several popular domain name registrars:

* GoDaddy: [Add an A record](https://www.godaddy.com/help/add-an-a-record-19238)
* Name.com: [Adding an A record](https://www.name.com/support/articles/115004893508-adding-an-a-record)
* Namecheap: [How can I set up an A (address) record for my domain?](https://www.namecheap.com/support/knowledgebase/article.aspx/319/2237/how-can-i-set-up-an-a-address-record-for-my-domain/)

Please note that the domain needs to be configured to work with the default registrar's name servers.

## Creating an A record using name servers of Servers.com

You can change your domain's name servers to those provided by Servers.com, and then use the **DNS** section of the Customer Portal to add an A record for your domain.

### Changing your domain's name servers

Before you can manage your domain's DNS entries using the Customer Portal, you need to set the following name servers for the domain:

* `ns01.srvrsdns.com`
* `ns01.srvrsdns.net`
* `ns01.srvrsdns.org`
* `ns01.srvrsdns.co.uk`

To change name servers of your domain, follow the instructions provided by your domain's registrar. You may need to wait up to 72 hours for your domain's new name servers to propagate.

You can use the following commands to verify that the new name servers have propagated.

In Linux:

```
host -t NS [yourdomain]
```

In Microsoft Windows:

```
nslookup -query=NS [yourdomain]
```

### Adding your domain in the DNS section of the Customer Portal

In the **DNS** section of the Customer Portal, click **Add new domain**. Enter your domain name in the displayed form and click **Save**.

### Creating A and CNAME records for your domain

Find your recently added domain in the **DNS** section of the Customer Portal and click **View details**, then click **Add A record**. Leave the **Domain** field blank, enter your server's public IP address in the **IP** field and click **Add record**.

You can also add a CNAME record to make a WWW subdomain alias for your domain.

Use the following command in Linux to view your domain's A record:

```
host -t A [yourdomain]
```

Use the following command to verify that your server is running and can be accessed using the domain name:

```
ping [yourdomain]
```


# How to provide the technical support team with network diagnostic results (/docs/tutorials/networking-and-ip-management/how-to-provide-network-diagnostic-results)











When facing a network connectivity issue with your server, the support team may ask you to run several network diagnostic tools and provide their output. In most cases, you will be asked to run `ping`, `traceroute`, and `ifconfig` — though the names may vary depending on the operating system. These utilities run in the command-line interface.

There are two places to run these diagnostic tools: on your server, and on the device from which you have a problem connecting to the server. The latter is usually your home or office machine, or another server.

## Accessing the command-line interface

### On Mac

Press **Command ⌘** + **Spacebar**, type "Terminal" and press **Enter** to open Terminal.

Use **Command ⌘** + **A** to select the entire text in a Terminal window, **Command ⌘** + **C** to copy the selection to the clipboard.

### On Windows

Press **Windows logo key** + **R**, type `cmd.exe` and press **Enter** to open Command Prompt.

Press **Alt** + **Spacebar**, then choose **Edit** → **Select All** to select the entire text. Press **Enter** to copy the selection to the clipboard.

### On Linux

If you are using a Linux server, you are likely already using the command-line interface via SSH or VNC console. Select All, Copy, Paste, and other shortcuts depend on the operating system and the SSH client app you are using on your local machine.

## Checking general Internet connectivity

Run the following command on both your local machine and your server. It measures the round-trip time for network messages sent from one host to another, similar to opening a website to check that you are online.

For Windows:

```
ping -n 10 test.us01.servers.com
```

For Mac and Linux:

```
ping -c 10 test.us01.servers.com
```

Sample output:

<img alt="Network ping test with no packet loss" src={__img0} />

0% packet loss means good Internet connectivity. Copy and save the entire output into a text file to share with the support team.

## Checking the reachability of your server

For a cloud server, find your server in **Cloud Servers** → **Create and Manage** in the [Customer Portal](https://portal.servers.com/). For a dedicated server, look in **Dedicated Servers** → **Create and Manage**. Copy the public IP address of your server — you will need it for the following commands.

### Running a ping test

Run the following command on your local machine to check the connection between your location and the server.

For Windows:

```
ping -n 10 [IP address of your server]
```

For Mac and Linux:

```
ping -c 10 [IP address of your server]
```

Sample output:

<img alt="Network ping test showing zero packet loss and timing details" src={__img1} />

### Running a traceroute

Run the following command on your local machine to trace the network path from your local machine to the server.

For Windows:

```
tracert [IP address of your server]
```

For Mac and Linux:

```
traceroute -I [IP address of your server]
```

Sample output:

<img alt="Traceroute output showing network path to server" src={__img2} />

Copy and save the entire output into a text file to share with the support team.

## Viewing IP configuration

Run the following command on your server to view the current IP configuration.

For Linux:

```
ifconfig -a
```

For Windows:

```
ipconfig -all
```

Sample output:

<img alt="Terminal output showing network interface configuration with IP addresses" src={__img3} />

## Running all commands at once

Replace `[IP address of your server]` in the following commands with the actual IP address of your server. Copy and paste the commands into a Command Prompt, Terminal, or SSH window. The output redirect operator (`>>`) saves results to a text file that you can send to the support team.

Run these commands on both your local machine and your server.

### On Windows

```
echo %date%-%time% >> "%USERPROFILE%Desktop\networking.txt"
ping -n 10 test.us01.servers.com >> "%USERPROFILE%Desktop\networking.txt"
ping -n 10 [IP address of a server] >> "%USERPROFILE%Desktop\networking.txt"
tracert [IP address of a server] >> "%USERPROFILE%Desktop\networking.txt"
ipconfig -all >> "%USERPROFILE%Desktop\networking.txt"
start notepad "%USERPROFILE%Desktop\networking.txt"
```

### On Mac

```bash
echo `date` >> ~/Desktop/networking.txt
ping -c 10 test.us01.servers.com >> ~/Desktop/networking.txt
ping -c 10 [IP address of a server] >> ~/Desktop/networking.txt
traceroute -I [IP address of a server] >> ~/Desktop/networking.txt
ifconfig -a >> ~/Desktop/networking.txt
open ~/Desktop/networking.txt
```

### On Linux

```bash
echo `date` >> ~/networking.txt
ping -c 10 test.us01.servers.com >> ~/networking.txt
ping -c 10 [IP address of a server] >> ~/networking.txt
traceroute -I [IP address of a server] >> ~/networking.txt
ifconfig -a >> ~/networking.txt
cat ~/networking.txt
```


# How to rename interfaces in Linux (/docs/tutorials/networking-and-ip-management/how-to-rename-interfaces-linux)



MAC addresses must be specified in lowercase. For some OS configurations, the configuration files use interface names like `int0` / `int1` or `ext0` / `ext1`. The interface names must be consistent across all configuration files.

## Step 1: Create or modify the udev rules file

Create the `/etc/udev/rules.d/70-persistent-net.rules` file if it does not exist:

```bash
sudo nano /etc/udev/rules.d/70-persistent-net.rules
```

Add rules using the MAC addresses of your network interfaces:

```
SUBSYSTEM=="net",ACTION=="add",DRIVERS=="?*",ATTR{address}=="a0:36:9f:7f:40:88",ATTR{type}=="1",NAME="int1"
SUBSYSTEM=="net",ACTION=="add",DRIVERS=="?*",ATTR{address}=="a0:36:9f:57:84:94",ATTR{type}=="1",NAME="int2"
SUBSYSTEM=="net",ACTION=="add",DRIVERS=="?*",ATTR{address}=="a0:36:9f:7f:40:8a",ATTR{type}=="1",NAME="ext1"
SUBSYSTEM=="net",ACTION=="add",DRIVERS=="?*",ATTR{address}=="a0:36:9f:57:84:96",ATTR{type}=="1",NAME="ext2"
```

Replace the MAC addresses with the actual addresses of your network interfaces and set the desired names.

## Step 2: Disable predictable interface names in GRUB

In the file `/etc/default/grub`, add the parameters `net.ifnames=0` and `biosdevname=0` to the `GRUB_CMDLINE_LINUX` line:

```
GRUB_CMDLINE_LINUX="... net.ifnames=0 biosdevname=0"
```

**Note:** For Ubuntu 14, 16, and Debian 9, specify only `net.ifnames=0` (omit `biosdevname=0`):

```
GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
```

## Step 3: Recreate the GRUB configuration

For CentOS 7:

```bash
grub2-mkconfig -o /boot/grub2/grub.cfg
```

For Ubuntu / Debian:

```bash
sudo update-grub
```

## Step 4: Reboot

```bash
sudo reboot
```

**Note:** For CentOS 6 and Ubuntu 14.04, it is not necessary to update GRUB. It is sufficient to specify the interface names in `/etc/udev/rules.d/70-persistent-net.rules` and reboot.

After renaming, update your network configuration files to use the new interface names before rebooting, or the server may lose network connectivity.


# How to restore the configuration of network interfaces on a dedicated server (/docs/tutorials/networking-and-ip-management/how-to-restore-network-interfaces-config)



Restoring the configuration of network interfaces on a dedicated server is a critical task that ensures the server's connectivity and functionality. Whether due to accidental changes, system upgrades, or hardware replacements, network settings might need to be restored to a known, working state.

This guide is not suitable for Windows-based systems.

## Downloading the default network configuration image of a server

1. In the left-hand menu, navigate to **Dedicated Servers** → **Manage**
2. Choose the server and click **Details**
3. Scroll down to the **Networks** section and download the configuration image by clicking the **helpful ISO file**

## Mounting the image

Use the instructions [How to boot a bare-metal server into a custom ISO image remotely using iDRAC](/tutorials/idrac-boot-management/how-to-boot-server-custom-iso-idrac) to enable Virtual Media in iDRAC and mount the downloaded configuration image.

## Restoring network settings

### Linux

1. Mount the image to the file system in the `/mnt` directory:

   ```bash
   mount /dev/cdrom /mnt
   ```

2. Navigate to the `/mnt` directory:

   ```bash
   cd /mnt
   ```

3. Network configuration scripts for all Linux-based operating systems are available inside the image.

4. Run the script for the required OS. For example, for CentOS 7:

   ```bash
   bash linux.sh
   ```

5. After running the script, restart the network service:

   ```bash
   systemctl restart network
   ```

The network configuration of the server will be restored to its initial settings.

### VMware ESXi

1. Load a kernel module:

   ```bash
   vmkload_mod iso9660
   ```

2. Define the name of the virtual CD-ROM:

   ```bash
   esxcfg-mpath -l | grep CD-ROM
   ```

3. Mount the virtual CD-ROM (replace with your CD-ROM name):

   ```bash
   vsish -e set /vmkModules/iso9660/mount mpx.vmhba32:C0:T0:L0
   ```

4. Run the script:

   ```bash
   sh /vmfs/volumes/CDROM/vmware.sh
   ```

The network configuration of the server will be restored to its initial settings.


# How to set up floating IP using keepalived (/docs/tutorials/networking-and-ip-management/how-to-setup-floating-ip-using-keepalived)



This article covers the basic setup of a floating IP using the keepalived software on CentOS 7. keepalived uses the VRRP (Virtual Router Redundancy Protocol) and IP multicasting for server communication, enabling automatic failover between servers.

## Prerequisites

* Two CentOS 7 servers on the same network segment.
* A floating (virtual) IP address that will move between the servers.
* Example addresses used in this guide:
  * **Master**: `192.168.1.10`
  * **Backup**: `192.168.1.20`
  * **Floating IP**: `192.168.1.100`

## Installation

Install keepalived on **both** servers:

```bash
sudo yum install keepalived
```

## Configure the Master server

Edit `/etc/keepalived/keepalived.conf` on the **master**:

```
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass secretpassword
    }

    virtual_ipaddress {
        192.168.1.100/24
    }
}
```

* **state MASTER**: this server is the primary.
* **priority 100**: higher priority wins the election.
* **virtual\_router\_id**: must be the same on both servers.
* **auth\_pass**: shared secret — must match on both servers.

## Configure the Backup server

Edit `/etc/keepalived/keepalived.conf` on the **backup**:

```
vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass secretpassword
    }

    virtual_ipaddress {
        192.168.1.100/24
    }
}
```

* **state BACKUP**: this server is the standby.
* **priority 90**: lower than the master.

## Enable IP forwarding

On both servers:

```bash
echo "net.ipv4.ip_nonlocal_bind = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
```

## Start and enable keepalived

Run on both servers:

```bash
sudo systemctl start keepalived
sudo systemctl enable keepalived
```

## Verifying failover

Check that the floating IP is active on the master:

```bash
ip addr show eth0
```

You should see `192.168.1.100` assigned. Stop keepalived on the master to simulate a failure:

```bash
sudo systemctl stop keepalived
```

The floating IP should move to the backup server within a few seconds. Verify on the backup:

```bash
ip addr show eth0
```


# Networking and IP management (/docs/tutorials/networking-and-ip-management)



This section covers guides for managing the network configuration of your dedicated servers. Topics include pointing domain names to server IP addresses, ordering additional IP networks, restoring network interface configurations, and renaming network interfaces in Linux.

Proper network configuration is essential for server accessibility and performance. The guides here will help you set up DNS records, manage IP allocations, and troubleshoot connectivity issues related to network interface configuration.


# How to reset the root password on Ubuntu 16.04 / Debian 7-8 / Proxmox on a dedicated server (/docs/tutorials/password-and-authentication/how-to-reset-root-password-ubuntu-16-04-debian-7-8-proxmox)











If you have lost the root password for the server and cannot log in with superuser privileges, this article will help you resolve the issue without requiring the old password.

### Reboot the server using the VNC console

1. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **VNC console** in the **Details** section
3. In the VNC console window, click the **Send CtrlAltDel** button

<img alt="VNC console window with Send CtrlAltDel button" src={__img0} />

Before the OS starts and after the BIOS menu, a boot menu and timer will appear. To stop the timer, press any key (such as any arrow key or **Ctrl**).

<img alt="Boot menu and timer appearing before OS startup" src={__img1} />

### Boot the OS in single-user mode

To boot the OS in single-user mode, you need to change the kernel boot parameters in the GRUB bootloader menu:

1. Use the **↓** and **↑** keys to navigate the menu and select the boot line (usually named "Ubuntu" or "Debian")
2. Press the **E** key to access the boot mode editing options

<img alt="Boot entry selected in GRUB to boot the OS in single-user mode" src={__img2} />

3. Find the line that starts with `linux /boot`
4. Change the parameter `ro` to `rw` and add the parameter `init=/bin/bash` at the end of the line

<img alt="Editing the GRUB parameter and booting the system" src={__img3} />

5. Boot the system in single-user mode by pressing **CTRL+X** or **F10**

The server will reboot and the console will open.

### Set a new root password

1. In the console, execute the command:

   ```bash
   passwd root
   ```

2. Enter the new root user password twice — the root user password is changed

3. Save the changes to disk and reboot the server:

   ```bash
   sync reboot -f
   ```

The new root user password will be set.


# How to reset the root password on Ubuntu 18.04+ / Debian 9+ / Proxmox on a dedicated server (/docs/tutorials/password-and-authentication/how-to-reset-root-password-ubuntu-18-04-debian-9-proxmox)









If you have lost the root password for the server and cannot log in with superuser privileges, this article will help you resolve the issue without requiring the old password.

### Reboot the server using the VNC console

1. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**
2. Select the server and click **VNC console** in the **Details** section
3. In the VNC console window, click the **Send CtrlAltDel** button

<img alt="VNC console window with Send CtrlAltDel button highlighted" src={__img0} />

Before the OS starts and after the BIOS menu, a boot menu and timer will appear. To stop the timer, press any key (such as any arrow key or **Ctrl**).

<img alt="Stopping the boot timer by pressing any key" src={__img1} />

### Boot the OS in single-user mode

To boot the OS in single-user mode, you need to change the kernel boot parameters in the GRUB bootloader menu:

1. Use the **↓** and **↑** keys to navigate the menu and select the boot line (usually named "Ubuntu" or "Debian")
2. Press the **E** key to access the boot mode editing options
3. Find the line that starts with `linux     /vmlinuz`
4. Change the parameter `ro` to `rw` and add the parameter `init=/bin/bash` at the end of the line

<img alt="Booting the system in single-user mode via GRUB parameter edit" src={__img2} />

5. Boot the system in single-user mode by pressing **CTRL+X** or **F10**

The server will reboot and the console will open.

### Set a new root password

1. In the console, execute the command:

   ```bash
   passwd root
   ```

2. Enter the new root user password twice — the root user password is changed

3. Save the changes to disk and reboot the server:

   ```bash
   sync reboot -f
   ```

The new root user password will be set.


# Password and authentication (/docs/tutorials/password-and-authentication)



Losing root access to a server is a common emergency scenario. This section guides you through recovering root access on Ubuntu and CentOS by booting into single-user mode via the GRUB bootloader using the server's VNC console — no prior password required.

### Explore recovery instructions

<Cards>
  <Card title="Ubuntu 24.04 Root Password Reset" description="Reset the root password on Ubuntu 24.04 via GRUB and VNC console." href="/tutorials/password-and-authentication/root-password-reset-ubuntu-24-04" />

  <Card title="Ubuntu 16.04 – Dedicated Server" description="Recover root access on a dedicated Ubuntu 16.04 server." href="/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-dedicated" />

  <Card title="Ubuntu 16.04 – Cloud Server" description="Reset root password on an Ubuntu 16.04 cloud server instance." href="/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-cloud" />

  <Card title="CentOS 6 and CentOS 7" description="Reset root password on CentOS 6 and 7, dedicated and cloud." href="/tutorials/password-and-authentication/reset-root-password-centos-6-7" />
</Cards>


# How to reset the root password on CentOS 6 and CentOS 7 (/docs/tutorials/password-and-authentication/reset-root-password-centos-6-7)

































If you have lost the root password of your server, this article will help you reset it.

### Overview

1. Access the VNC Console
2. Restart the server and edit kernel boot parameters to boot into single-user mode
3. Set a new root password without the old password required

### Step 1: Access VNC Console

For a cloud server, find your server in **Cloud Servers** → **Create and Manage** in the [Customer Portal](https://portal.servers.com). For a dedicated server, look in **Dedicated Servers** → **Create and Manage**. Open the VNC Console using the button of the same name.

<img alt="Customer Portal server page with VNC Console button" src={__img0} />

<img alt="VNC Console window" src={__img1} />

### Step 2: Edit kernel boot parameters

#### CentOS 6 – Dedicated server

Restart the server by pressing **Ctrl+Alt+Del** in the VNC Console window. After the BIOS menu, a timer appears — press **ESC** to stop it and access the GRUB boot menu.

<img alt="GRUB boot menu on CentOS 6" src={__img2} />

Use **↓** and **↑** keys to select your boot line and press **e** to edit. Select the line starting with `kernel /vmlinuz-` and press **e** again.

<img alt="GRUB entry selection on CentOS 6" src={__img3} />

<img alt="Editing kernel parameters in GRUB" src={__img4} />

Add the `single` parameter at the end of the line.

<img alt="Single parameter added to kernel line" src={__img5} />

Press **Enter** to save, then press **b** to start the system in single-user mode.

#### CentOS 6 – Cloud server

Restart the server using **Send CtrlAltDel** in VNC Console. Press **Tab** to stop the timer and edit the boot menu.

<img alt="GRUB cloud server boot menu CentOS 6" src={__img6} />

Remove the highlighted parameters and add `1` (with a leading space) at the end of the string.

<img alt="Removing parameters from boot line" src={__img7} />

<img alt="Modified boot parameters on cloud server" src={__img8} />

Press **Enter** to boot into single-user mode.

#### CentOS 7 – Dedicated server

Restart via **Ctrl+Alt+Del** in VNC. When the GRUB menu appears, select your boot entry and press **e** to edit.

<img alt="GRUB menu on CentOS 7" src={__img9} />

Find the line starting with `linux`, `linux16`, or `linuxefi` (depending on architecture). Change `ro` to `rw`, remove `rhgb` and `quiet`, and add `rd.break enforcing=0` at the end.

<img alt="CentOS 7 kernel parameters before modification" src={__img10} />

<img alt="CentOS 7 kernel parameters after modification" src={__img11} />

Press **Ctrl+X** to start the system in single-user mode.

#### CentOS 7 – Cloud server

Restart via **Send CtrlAltDel** in VNC. Select your boot entry and press **e** to edit.

<img alt="Cloud server GRUB menu CentOS 7" src={__img12} />

Change `ro` to `rw`, remove highlighted parameters, and add `rd.break enforcing=0` at the end.

<img alt="Before removing parameters on CentOS 7 cloud" src={__img13} />

<img alt="After modifying parameters on CentOS 7 cloud" src={__img14} />

Press **Ctrl+X**. The system will start in single-user mode.

### Step 3: Set a new root password

#### CentOS 6

```bash
passwd root
reboot
```

#### CentOS 7

```bash
chroot /sysroot
passwd root
touch /.autorelabel
exit
reboot
```


# How to reset root password on Ubuntu 16.04 cloud server (/docs/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-cloud)















If you have lost the root password of your server, you can restart the server in single-user mode and set a new password. To do this, you must access the server console via the [Customer Portal](https://portal.servers.com/).

### Step 1: Open the VNC Console

Open the server's page in the **Cloud Servers** → **Create & Manage** section of the Customer Portal. Make sure the server is active. Open the VNC Console using the button of the same name.

<img alt="Virtual machine information panel with VNC console option" src={__img0} />

Restart the server using the **Send CtrlAltDel** button in the VNC Console window.

### Step 2: Access the GRUB menu

After the BIOS screen, before the OS starts, a `Booting from Hard Disk...` line appears. Press **ESC** at that moment to open the GRUB menu.

<img alt="SeaBIOS boot screen with iPXE network boot" src={__img1} />

<img alt="GRUB bootloader with Ubuntu selected for booting" src={__img2} />

### Step 3: Edit boot parameters

Press **e** to edit the boot menu. Changes will persist until the next boot.

Scroll down to the line that starts with `linux /boot`. Remove any highlighted parameters and change the `ro` parameter to `rw`. Add `init=/bin/bash` after a space.

<img alt="GRUB bootloader screen with kernel boot parameters highlighted" src={__img3} />

<img alt="GNU GRUB bootloader configuration interface" src={__img4} />

### Step 4: Boot and reset password

Press **Ctrl+X** to boot into single-user mode. You may need to press Enter for the command prompt to appear after boot.

<img alt="Terminal display of system boot process" src={__img5} />

Set a new root password:

```bash
passwd root
```

Restart the server:

```bash
reboot
```


# How to reset the root password on Ubuntu 16.04 dedicated server (/docs/tutorials/password-and-authentication/reset-root-password-ubuntu-16-04-dedicated)













If you have lost the root password of your server and cannot access it as root, this article will help you resolve this issue. You must access the server console via the [Customer Portal](https://portal.servers.com/).

### Password reset algorithm

1. Restart the server
2. Before the OS starts, change boot parameters in the GRUB boot menu
3. Load the OS in single-user mode
4. Set a new root password without the old one being required

### Step-by-step guide

If the server is on, restart it by pressing **Ctrl+Alt+Del** in the VNC console. After the BIOS menu, before the OS starts, a timer appears — press any key (preferably **ESC**) to stop it and access the GRUB boot menu.

<img alt="Filesystem checks and password update in console" src={__img0} />

Use the **↓** and **↑** keys to navigate through the menu, select your boot line (often `* Ubuntu`), and press **e** to access the boot editing options.

<img alt="GRUB bootloader editor with Ubuntu boot parameters" src={__img1} />

Find the line that starts with `linux /boot`. At the end of that line, change the `ro` parameter to `rw` and add `init=/bin/bash` after a space.

<img alt="GRUB bootloader configuration screen" src={__img2} />

Press **Ctrl+X** or **F10** to start the system. You will get a root console — run:

```bash
passwd root
```

Enter the new root password twice.

<img alt="Terminal with Linux boot process and filesystem check" src={__img3} />

<img alt="Console showing filesystem checks and password update" src={__img4} />

The root password is now changed. Save changes and restart:

```bash
sync
reboot -f
```


# How to reset the root password on Ubuntu 24.04 (/docs/tutorials/password-and-authentication/root-password-reset-ubuntu-24-04)















If you have lost the root user password and cannot log in, this guide will help you reset it.

To reset the password, you will need console access to the server. Go to the **Customer Portal** → **Server page** → **VNC Console**. This provides direct access to the server's console, even if SSH is unavailable.

### Overview

To reset the password you will:

1. Reboot the server
2. Edit the kernel boot parameters using the GRUB bootloader
3. Boot into single-user mode
4. Set a new root password without entering the previous one
5. Reboot the server

The `reboot` and `shutdown -r` commands, as well as the **Ctrl+Alt+Del** button, will not work at this stage, as they rely on the `init` daemon, which will be replaced with `/bin/bash`. Use the `reboot -f` command or manually start `init` using `exec /sbin/init`.

### Resetting a password on a dedicated server

#### Step 1: Reboot the server

Open the [Customer Portal](https://portal.servers.com/login), navigate to the server page, and launch the **VNC Console**. In the VNC Console toolbar, click **Send CtrlAltDel** to reboot the server.

<img alt="Launching the VNC console and clicking Send CtrlAltDel" src={__img0} />

After the BIOS screen, the GRUB boot menu will appear.

<img alt="GRUB boot menu after BIOS screen" src={__img1} />

#### Step 2: Edit boot parameters

Use the **↑** and **↓** arrow keys to select the boot entry for your operating system (usually `*Ubuntu`). Press **e** to edit the selected entry.

<img alt="Editing boot parameters in GRUB" src={__img2} />

#### Step 3: Boot into single-user mode

Locate the line starting with `linux /vmlinuz`. Replace the `ro` parameter with `rw` and add `init=/bin/bash` at the end of the line.

<img alt="Boot parameters edited to boot into single-user mode" src={__img3} />

Press **Ctrl+X** or **F10** to boot with the modified parameters. Use the on-screen buttons in the VNC Console to send key combinations.

<img alt="Booting with the modified parameters" src={__img4} />

The system will boot directly into a console without requiring login credentials.

<img alt="System booted directly into a console" src={__img5} />

#### Step 4: Reset the root password

Once the system boots into a shell prompt, run:

```bash
passwd root
```

Enter a new root password twice when prompted.

#### Step 5: Save changes and reboot

```bash
sync
reboot -f
```

Once the system reboots, you can log in as root using the new password.


# How to install LAMP on CentOS 6 (/docs/tutorials/software-installation/how-to-install-lamp-on-centos-6)



LAMP is an acronym for **Linux**, **Apache**, **MySQL**, and **PHP**. Together these components form a complete web-server stack. Each component is responsible for a specific part of web hosting.

## Step 1: Install Apache

```bash
sudo yum install httpd
sudo service httpd start
sudo chkconfig httpd on
```

Verify Apache is running by opening `http://your-server-ip` in a browser — you should see the default Apache test page.

## Step 2: Install MySQL

```bash
sudo yum install mysql-server
sudo service mysqld start
sudo chkconfig mysqld on
```

Run the security script to set a root password and remove insecure defaults:

```bash
sudo mysql_secure_installation
```

Follow the prompts:

* Set a root password.
* Remove anonymous users: **Yes**.
* Disallow remote root login: **Yes**.
* Remove the test database: **Yes**.
* Reload privilege tables: **Yes**.

## Step 3: Install PHP

```bash
sudo yum install php php-mysql
```

Restart Apache to load the PHP module:

```bash
sudo service httpd restart
```

### Test PHP

Create a test file:

```bash
echo "<?php phpinfo(); ?>" | sudo tee /var/www/html/info.php
```

Open `http://your-server-ip/info.php` in a browser. You should see the PHP information page. Remove this file after testing:

```bash
sudo rm /var/www/html/info.php
```

## Step 4: Configure the firewall

Allow HTTP (and optionally HTTPS) traffic:

```bash
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo service iptables save
```

## Useful additional PHP modules

```bash
sudo yum install php-gd php-mbstring php-xml php-xmlrpc
sudo service httpd restart
```

## Summary

| Component | Service name | Default port |
| --------- | ------------ | ------------ |
| Apache    | httpd        | 80, 443      |
| MySQL     | mysqld       | 3306         |
| PHP       | (module)     | —            |

Your LAMP stack is now ready for deploying web applications.


# How to install nano text editor in Linux (/docs/tutorials/software-installation/how-to-install-nano-text-editor-in-linux)



Nano is a simple, user-friendly command-line text editor for Linux. It is ideal for quick edits to configuration files and is much easier to use than vi/vim for beginners. This article covers installation and basic usage.

## Installation

### Debian / Ubuntu

```bash
sudo apt-get update
sudo apt-get install nano
```

### CentOS / RHEL

```bash
sudo yum install nano
```

### Fedora

```bash
sudo dnf install nano
```

### Verify installation

```bash
nano --version
```

## Opening a file

```bash
nano /path/to/file
```

To open a file and jump to a specific line number:

```bash
nano +42 /path/to/file
```

## Basic keyboard shortcuts

nano uses keyboard shortcuts displayed at the bottom of the screen. `^` means **Ctrl** and `M-` means **Alt**.

| Shortcut | Action               |
| -------- | -------------------- |
| `Ctrl+O` | Save (Write Out)     |
| `Ctrl+X` | Exit                 |
| `Ctrl+K` | Cut the current line |
| `Ctrl+U` | Paste (Uncut)        |
| `Ctrl+W` | Search               |
| `Ctrl+\` | Search and replace   |
| `Ctrl+G` | Display help         |
| `Ctrl+C` | Show cursor position |
| `Ctrl+_` | Go to line number    |
| `Alt+U`  | Undo                 |
| `Alt+E`  | Redo                 |

## Saving a file

Press **Ctrl+O**, confirm the filename, then press **Enter**.

## Exiting nano

Press **Ctrl+X**. If there are unsaved changes, nano will ask whether to save them.

## Configuration file

nano's behaviour can be customised in `~/.nanorc` (per-user) or `/etc/nanorc` (system-wide). Useful settings:

```
set tabsize 4
set autoindent
set linenumbers
set mouse
```

Enable syntax highlighting by including the default highlight files:

```
include "/usr/share/nano/*.nanorc"
```


# Software installation (/docs/tutorials/software-installation)



Getting the right software installed quickly is the first step in making a server useful. This section covers setting up a full LAMP web stack on CentOS and installing the nano text editor — a lightweight and beginner-friendly tool for editing configuration files on any Linux system.

### Explore installation instructions

<Cards>
  <Card title="Install LAMP on CentOS 6" description="Set up Apache, MySQL, and PHP as a full web-server stack." href="/tutorials/software-installation/how-to-install-lamp-on-centos-6" />

  <Card title="Install nano Text Editor" description="Install and use the nano command-line text editor on Linux." href="/tutorials/software-installation/how-to-install-nano-text-editor-in-linux" />
</Cards>


# Connecting to a remote server via SSH (/docs/tutorials/ssh-access/connecting-to-a-remote-server-via-ssh)



Use the `ssh` utility on your local machine to connect to a remote server via SSH. This applies to Linux, macOS, and Windows 10. Use Terminal under macOS and Linux to call the ssh utility. On Microsoft Windows 10, use PowerShell.

## Basic syntax

```bash
ssh username@server_ip_or_hostname
```

For example:

```bash
ssh root@192.0.2.1
```

## Connecting with an SSH key

If you use an SSH key pair for authentication, specify the path to the private key with the `-i` flag:

```bash
ssh -i /path/to/private_key username@server_ip_or_hostname
```

## Connecting on a non-standard port

By default, SSH listens on port 22. If your server uses a different port, specify it with the `-p` flag:

```bash
ssh -p 2222 username@server_ip_or_hostname
```

## First-time connection

When connecting to a server for the first time, you will be prompted to confirm the server's fingerprint:

```
The authenticity of host '192.0.2.1 (192.0.2.1)' can't be established.
ECDSA key fingerprint is SHA256:...
Are you sure you want to continue connecting (yes/no)?
```

Type `yes` to proceed. The server's key will be saved in `~/.ssh/known_hosts`.

## Troubleshooting

* **Permission denied**: Check that your username and password (or private key) are correct.
* **Connection refused**: Verify the server IP, port, and that the SSH daemon is running.
* **Connection timed out**: Check firewall rules and network connectivity.


# How to add an SSH key to a cloud server (/docs/tutorials/ssh-access/how-to-add-new-ssh-key-to-a-cloud-server)



To use an SSH key pair to connect to a server, the public part of the pair must be placed on the server. Refer to the [How to Create a New SSH Key Pair](/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair) article for instructions on how to generate key pairs under Windows, Mac, and Linux.

## Adding the key manually via SSH

If you already have access to the server, append the public key to the `~/.ssh/authorized_keys` file:

```bash
echo "your-public-key-content" >> ~/.ssh/authorized_keys
```

Or use the `ssh-copy-id` utility (Linux/macOS):

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub username@server_ip
```

## Setting correct permissions

SSH requires strict permissions on the `.ssh` directory and `authorized_keys` file:

```bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
```

## Adding a key via the Customer Portal

1. Log in to the [Customer Portal](https://portal.servers.com).
2. Navigate to your cloud server's page.
3. Find the **SSH Keys** section.
4. Paste your public key and save.

The key will be injected into the server on the next rebuild or can be added live depending on the portal version.

## Verifying access

Test the connection using the private key:

```bash
ssh -i ~/.ssh/id_ed25519 username@server_ip
```

If successful, you will be logged in without being prompted for a password.


# How to create an SSH key pair (/docs/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair)



To create an SSH key pair, run the `ssh-keygen` utility on your local machine. The `ssh-keygen` utility is available on all major operating systems. In macOS or Linux, run `ssh-keygen` in the Terminal app. On Windows, run `ssh-keygen` in the Command Prompt app.

## Generating a key pair

Run the following command:

```bash
ssh-keygen -t ed25519 -C "your_email@example.com"
```

For legacy systems that do not support Ed25519, use RSA:

```bash
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```

## Key generation prompts

When prompted, choose a location to save the key (press Enter to accept the default):

```
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
```

Optionally enter a passphrase to protect the private key:

```
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```

## Result

Two files are created:

* **Private key**: `~/.ssh/id_ed25519` — keep this file secret and never share it.
* **Public key**: `~/.ssh/id_ed25519.pub` — place this on servers you want to access.

## Viewing the public key

```bash
cat ~/.ssh/id_ed25519.pub
```

Copy the output — you will need it when adding the key to a remote server.


# How to limit SSH access by IP addresses using firewall (/docs/tutorials/ssh-access/how-to-limit-ssh-access-by-ip-addresses-using-firewall)



To make SSH on your server accessible only from specific IP networks, set up host-based firewall rules using `iptables`, `nftables`, `ufw`, or `firewalld`.

## Using UFW (Ubuntu/Debian)

Allow SSH only from a specific IP or subnet:

```bash
sudo ufw allow from 203.0.113.0/24 to any port 22
sudo ufw deny 22
sudo ufw enable
```

Check the rules:

```bash
sudo ufw status
```

## Using firewalld (CentOS/RHEL 7+)

Add a rich rule to allow SSH from a specific address:

```bash
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.5/32" port protocol="tcp" port="22" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
```

## Using iptables

Allow SSH from a trusted IP and drop all other SSH connections:

```bash
# Allow from trusted IP
sudo iptables -A INPUT -p tcp --dport 22 -s 203.0.113.5 -j ACCEPT

# Drop all other SSH
sudo iptables -A INPUT -p tcp --dport 22 -j DROP
```

Save the rules so they persist after reboot:

```bash
# Debian/Ubuntu
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save
```

## Using nftables

```bash
sudo nft add rule inet filter input tcp dport 22 ip saddr 203.0.113.5 accept
sudo nft add rule inet filter input tcp dport 22 drop
```

## Important notes

* Always test in a new terminal session before closing your current one.
* If you lose access, use the VNC Console in the Customer Portal to recover.
* Replace `203.0.113.5` or `203.0.113.0/24` with your actual trusted IP(s).


# How to protect SSH using fail2ban on CentOS 6 (/docs/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-centos-6)



If your SSH server is vulnerable to password-cracking attacks, this guide shows how to protect SSH from malicious login attempts using the `fail2ban` package on CentOS 6.

## Installation

Enable the EPEL repository and install fail2ban:

```bash
sudo yum install epel-release
sudo yum install fail2ban
```

## Configuration

Create a local jail configuration file:

```bash
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
```

Find or add the `[ssh-iptables]` section:

```ini
[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/secure
maxretry = 5
bantime  = 600
findtime = 600
```

* **maxretry**: Number of failures before a ban is triggered.
* **bantime**: Ban duration in seconds (600 = 10 minutes).
* **findtime**: Time window in which failures are counted.

## Starting and enabling fail2ban

```bash
sudo service fail2ban start
sudo chkconfig fail2ban on
```

## Checking status

```bash
sudo fail2ban-client status ssh-iptables
```

## Unbanning an IP address

```bash
sudo fail2ban-client set ssh-iptables unbanip 203.0.113.5
```

## Viewing banned IPs via iptables

```bash
sudo iptables -L -n | grep fail2ban
```


# How to protect SSH using fail2ban on Ubuntu 16.04 (/docs/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-ubuntu-16-04)



If your SSH server is vulnerable to password-cracking attacks, this guide shows how to protect SSH from malicious login attempts using the `fail2ban` package on Ubuntu 16.04.

## What is fail2ban?

`fail2ban` monitors log files for repeated failed login attempts and temporarily bans the offending IP addresses using firewall rules.

## Installation

Update your package list and install fail2ban:

```bash
sudo apt-get update
sudo apt-get install fail2ban
```

## Configuration

The main configuration file is `/etc/fail2ban/jail.conf`. It is recommended to create a local override file rather than editing the original:

```bash
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
```

Find the `[sshd]` section and verify or adjust:

```ini
[sshd]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 5
bantime  = 600
findtime = 600
```

* **maxretry**: Number of failures before a ban is triggered.
* **bantime**: Duration of the ban in seconds (600 = 10 minutes).
* **findtime**: Time window in which `maxretry` failures must occur.

## Starting and enabling fail2ban

```bash
sudo systemctl start fail2ban
sudo systemctl enable fail2ban
```

## Checking status

View active bans and jail status:

```bash
sudo fail2ban-client status sshd
```

## Unbanning an IP address

```bash
sudo fail2ban-client set sshd unbanip 203.0.113.5
```


# How to replace password-based SSH authentication with key-based (/docs/tutorials/ssh-access/how-to-replace-password-based-ssh-authentication-with-key-based)



Secure your SSH access by setting up key-based authentication first and disabling password-based access afterward. Follow this guide carefully to avoid locking yourself out.

## Step 1: Add your public key to the server

Before disabling passwords, make sure your public key is already working. Follow the [How to Add a New SSH Key to a Cloud Server](/tutorials/ssh-access/how-to-add-new-ssh-key-to-a-cloud-server) article.

Verify key-based login works **before** proceeding:

```bash
ssh -i ~/.ssh/id_ed25519 username@server_ip
```

## Step 2: Disable password authentication in SSH config

Open the SSH daemon configuration file:

```bash
sudo nano /etc/ssh/sshd_config
```

Find and update (or add) these lines:

```
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
```

Also ensure root password login is disabled if not needed:

```
PermitRootLogin prohibit-password
```

## Step 3: Restart the SSH daemon

Apply the changes by restarting sshd:

```bash
# Debian/Ubuntu
sudo systemctl restart ssh

# CentOS/RHEL
sudo systemctl restart sshd
```

## Step 4: Verify in a new session

**Do not close your current session.** Open a new terminal and confirm you can still log in with your key:

```bash
ssh -i ~/.ssh/id_ed25519 username@server_ip
```

If it works, the configuration is complete. Only then close your previous session.

## Troubleshooting

If you get locked out, use the server's VNC console in the Customer Portal to regain access and revert the changes.


# SSH access (/docs/tutorials/ssh-access)



Secure Shell (SSH) is the primary method for accessing and administering Linux servers remotely. This section covers everything from establishing your first connection and managing key pairs to hardening SSH against brute-force attacks and restricting access by IP address.

## Explore SSH documentation

<Cards>
  <Card title="Connecting via SSH" description="Connect to a remote server from Linux, macOS, or Windows." href="/tutorials/ssh-access/connecting-to-a-remote-server-via-ssh" />

  <Card title="Create an SSH Key Pair" description="Generate a public/private key pair with ssh-keygen." href="/tutorials/ssh-access/how-to-create-a-new-ssh-key-pair" />

  <Card title="Add SSH Key to a Cloud Server" description="Place your public key on a server for passwordless access." href="/tutorials/ssh-access/how-to-add-new-ssh-key-to-a-cloud-server" />

  <Card title="Switch to Key-Based Authentication" description="Disable password login and enforce SSH key authentication." href="/tutorials/ssh-access/how-to-replace-password-based-ssh-authentication-with-key-based" />
</Cards>

## Explore SSH security instructions

<Cards>
  <Card title="Limit SSH Access by IP" description="Allow SSH only from trusted IPs using iptables, ufw, or firewalld." href="/tutorials/ssh-access/how-to-limit-ssh-access-by-ip-addresses-using-firewall" />

  <Card title="Protect SSH with fail2ban on Ubuntu" description="Ban IPs after repeated failed login attempts on Ubuntu 16.04." href="/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-ubuntu-16-04" />

  <Card title="Protect SSH with fail2ban on CentOS" description="Ban IPs after repeated failed login attempts on CentOS 6." href="/tutorials/ssh-access/how-to-protect-ssh-using-fail2ban-on-centos-6" />
</Cards>


# How to install Ubuntu with software RAID 1 (/docs/tutorials/storage-and-disk/how-to-install-ubuntu-with-software-raid-1)



RAID ("Redundant Array of Independent Disks") is a method of using multiple disks for different combinations to increase the reliability of data storage and/or improve performance of read/write operations, depending on the RAID level.

**RAID-1** (mirroring) writes identical data to two or more disks. If one disk fails, the other contains a full copy of all data, providing high availability.

## Prerequisites

* A server with at least two disks of equal or similar size.
* Ubuntu Server installation media (ISO or network boot).

## Setting up RAID-1 during Ubuntu installation

### Step 1: Boot the installer

Boot from the Ubuntu Server installation media. Proceed through the language, keyboard, and network setup screens until you reach the **Storage configuration** step.

### Step 2: Switch to manual partitioning

Select **Custom storage layout** (or **Manual** in older installers) instead of the automatic option.

### Step 3: Create partitions on both disks

For each disk (`/dev/sda` and `/dev/sdb`), create the same partition layout:

1. A small partition for `/boot` (e.g., 1 GB), type **Linux filesystem**.
2. A partition for the root filesystem (remaining space), type **Linux filesystem**.

Mark each partition as a **software RAID member** rather than assigning a filesystem directly.

### Step 4: Create RAID devices

Select **Create software RAID (md)** and configure:

* **RAID-1** for the boot partitions (`/dev/sda1` + `/dev/sdb1`) → `/dev/md0`
* **RAID-1** for the root partitions (`/dev/sda2` + `/dev/sdb2`) → `/dev/md1`

### Step 5: Format and assign mount points

* Format `/dev/md0` as `ext4`, mount as `/boot`.
* Format `/dev/md1` as `ext4`, mount as `/` (root).

### Step 6: Complete installation

Proceed with the rest of the installation. The installer will configure `mdadm` and update `initramfs` automatically.

## Verifying the RAID array after boot

Check the RAID status:

```bash
cat /proc/mdstat
```

Example healthy output:

```
md1 : active raid1 sdb2[1] sda2[0]
      976760832 blocks super 1.2 [2/2] [UU]
```

Two `U` characters indicate both disks are active and in sync.

## Monitoring with mdadm

```bash
sudo mdadm --detail /dev/md1
```

### Set up email alerts

Edit `/etc/mdadm/mdadm.conf`:

```
MAILADDR your@email.com
```

Then restart the monitoring daemon:

```bash
sudo systemctl restart mdmonitor
```

## Simulating and recovering from a disk failure

Mark a disk as failed (for testing):

```bash
sudo mdadm --fail /dev/md1 /dev/sdb2
sudo mdadm --remove /dev/md1 /dev/sdb2
```

Add a replacement disk:

```bash
sudo mdadm --add /dev/md1 /dev/sdb2
```

The array will automatically rebuild. Monitor progress with:

```bash
watch cat /proc/mdstat
```


# How to work with LVM (/docs/tutorials/storage-and-disk/how-to-work-with-lvm)



LVM (Logical Volume Manager) is a special Linux OS subsystem that provides additional options for managing partitions on hard disks. It adds a layer of abstraction between your physical storage devices and the file systems, making storage management flexible and dynamic.

## Key concepts

* **PV (Physical Volume)**: a physical disk or partition initialized for use by LVM.
* **VG (Volume Group)**: a pool of storage made up of one or more PVs.
* **LV (Logical Volume)**: a virtual partition carved out of a VG, which is what you format and mount.

## Installation

```bash
# Debian/Ubuntu
sudo apt-get install lvm2

# CentOS/RHEL
sudo yum install lvm2
```

## Creating an LVM setup

### Step 1: Initialize physical volumes

```bash
sudo pvcreate /dev/sdb /dev/sdc
```

Verify:

```bash
sudo pvdisplay
```

### Step 2: Create a volume group

```bash
sudo vgcreate my_vg /dev/sdb /dev/sdc
```

Verify:

```bash
sudo vgdisplay
```

### Step 3: Create a logical volume

Create a 10 GB logical volume:

```bash
sudo lvcreate -L 10G -n my_lv my_vg
```

Or use all remaining free space:

```bash
sudo lvcreate -l 100%FREE -n my_lv my_vg
```

Verify:

```bash
sudo lvdisplay
```

### Step 4: Format and mount

```bash
sudo mkfs.ext4 /dev/my_vg/my_lv
sudo mkdir /mnt/mydata
sudo mount /dev/my_vg/my_lv /mnt/mydata
```

Add to `/etc/fstab` for automatic mounting at boot:

```
/dev/my_vg/my_lv  /mnt/mydata  ext4  defaults  0  2
```

## Extending a logical volume

Extend the logical volume by 5 GB and resize the filesystem:

```bash
sudo lvextend -L +5G /dev/my_vg/my_lv
sudo resize2fs /dev/my_vg/my_lv
```

## Reducing a logical volume

**Warning:** always back up data before shrinking. Unmount first.

```bash
sudo umount /mnt/mydata
sudo e2fsck -f /dev/my_vg/my_lv
sudo resize2fs /dev/my_vg/my_lv 8G
sudo lvreduce -L 8G /dev/my_vg/my_lv
sudo mount /dev/my_vg/my_lv /mnt/mydata
```

## Adding a new disk to an existing volume group

```bash
sudo pvcreate /dev/sdd
sudo vgextend my_vg /dev/sdd
```

## Removing an LVM setup

```bash
sudo umount /mnt/mydata
sudo lvremove /dev/my_vg/my_lv
sudo vgremove my_vg
sudo pvremove /dev/sdb /dev/sdc
```


# Storage and disk (/docs/tutorials/storage-and-disk)



Reliable storage management is critical for server performance and data safety. This section covers LVM for flexible logical volume management and software RAID-1 for disk mirroring and redundancy at the OS level.

### Explore storage instructions

<Cards>
  <Card title="How to Work with LVM" description="Create, extend, and manage logical volumes with LVM." href="/tutorials/storage-and-disk/how-to-work-with-lvm" />

  <Card title="Install Ubuntu with Software RAID-1" description="Set up disk mirroring during Ubuntu installation using mdadm." href="/tutorials/storage-and-disk/how-to-install-ubuntu-with-software-raid-1" />
</Cards>


# How to configure the network on ESXi 5.5/6.0/6.6 virtual machine on dedicated servers (/docs/tutorials/virtualization/configure-network-esxi-5-5-6-0-6-6)











This guide covers network configuration for virtual machines running on ESXi 5.5, 6.0, and 6.6 on Servers.com dedicated servers, including adding port groups for private networking, uploading OS images to the datastore, and configuring network interfaces inside the guest OS.

## Setting up and installation of virtual machines

### Adding a port group for a private network

A setup script creates only one port group: "VM Network" on **vSwitch0**. This port group is used for the public network on the virtual machine. If you need to set up a private network, you must add another port group on **vSwitch1**. To do this:

1. Click **Add port group**

<img alt="Clicking Add port group in the ESXi networking interface" src={__img0} />

2. Specify the **Name** and **Virtual switch** for the new port group

<img alt="Updating details for the new port group" src={__img1} />

3. Click **Add**

You will get a ready port group that can be used when creating a virtual machine.

### Adding images

To add images for future virtual machines:

1. On the **Storage** page, navigate to the storage you are using and click **Datastore browser**

<img alt="Navigating to the datastore browser in ESXi storage" src={__img2} />

2. In the opened window, click **Create directory** and specify the name "images". Then, select the created directory, click **Upload** and choose the image to upload

<img alt="Creating a directory and uploading images in the datastore browser" src={__img3} />

The upload process will be displayed in the window or in **Recent tasks** at the bottom of the page. Once complete, the image can be used to create a virtual machine.

### Creating a virtual machine

1. Go to the main **Host** page or the **Virtual Machines** page and click **Create/Register VM**
2. Select **Create a new virtual machine** and click **Next**
3. Specify the name of the virtual machine, the Guest OS family, and the Guest OS version
4. Click **Next**
5. Choose the storage to be used for the installation and click **Next**
6. In the next window, select the necessary resources for the virtual machine
7. Configure public and private networks:
   * Add another network adapter by clicking **Add network adapter** if both public and private networks are needed
   * Specify the public (VM Network) and private (VM net\_int) port groups for the adapters
8. Expand the **CD/DVD Drive 1** section and choose **Datastore ISO file** from the drop-down menu
9. Click **Browse** and specify the path to the previously uploaded image
10. On the last page, review the selected parameters and click **Finish**
11. Go to the virtual machine page, open the console, and complete the OS installation

## Network configuration on the virtual machine

A vSwitch acts as a "bridge" to the physical interfaces. To configure the network on the virtual machine, you can use the IP addresses and gateway assigned to the physical server network.

To use an alias IP address, assign it as the primary on the interface included in the public vSwitch port group, and use the main public network's gateway as the gateway.

### Ubuntu

For a virtual machine running Ubuntu 20.04:

`/etc/netplan/00-installer-config.yaml`

```yaml
network:
  ethernets:
    ens18:
      dhcp4: false
      addresses:
      - $IP/$NETMASK
      routes:
        - to: 0.0.0.0/0
          via: $PUBLIC_GW
          on-link: true
      nameservers:
        addresses:
        - $DNS_SERVERS
    ens19:
      dhcp4: false
      addresses:
      - $PRIVATE_IP/$NETMASK
      routes:
        - to: 10.0.0.0/8
          via: $PRIVATE_GW
        - to: 192.168.0.0/16
          via: $PRIVATE_GW
        - to: 188.42.208.0/21
          via: $PRIVATE_GW
      nameservers:
        addresses:
        - $DNS_SERVERS
  version: 2
```

Where:

* `$IP` – any available IP address in the range assigned to the dedicated server (can also be an alias IP)
* `$NETMASK` – the subnet mask (can be /32 if configuring an alias IP)
* `$PRIVATE_IP` – the private IP address available to the dedicated server
* `$PUBLIC_GW` – the IP address of the gateway in the public network
* `$PRIVATE_GW` – the IP address of the gateway in the private network
* `$DNS_SERVERS` – DNS servers available to the dedicated server


# How to configure the network on Hyper-V virtual machine on dedicated servers (/docs/tutorials/virtualization/configure-network-hyper-v)



This guide covers network configuration for virtual machines running on Hyper-V on Servers.com dedicated servers, including virtual switch setup and network interface configuration inside the guest OS.

## Setting up and installation of virtual machines

### Setting up

When setting up virtual machines on Hyper-V, include the `aggi` interface in the virtual switch and configure a free IP address on the virtual machine, specifying the main gateway of the physical server's public network.

### Installation

Instructions on how to install Hyper-V and create a virtual machine can be found on the official Microsoft website:

* [Installing the Hyper-V role on Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Install-Hyper-V?pivots=windows-server)
* [Creating a virtual switch for Hyper-V virtual machines](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines?tabs=hyper-v-manager\&pivots=windows-server)
* [Creating a virtual machine in Hyper-V](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-machine-in-hyper-v?tabs=hyper-v-manager)

### Creating vSwitch

Starting with Windows Server 2016, the LBFO (Load Balancing/Failover) teaming method is outdated and not recommended for Hyper-V.

When creating a vSwitch for Hyper-V via the GUI, you might encounter an error. This can be bypassed by creating the vSwitch through PowerShell with the `-AllowNetLbfoTeams $true` parameter:

```powershell
New-VMSwitch -Name "vSwitch" -NetAdapterName "aggi" -AllowNetLbfoTeams $true
```

## Network configuration examples

### CentOS 7

`/etc/sysconfig/network-scripts/ifcfg-eth0`

```
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPADDR=188.42.29.222
PREFIX=32
GATEWAY=188.42.128.203
DNS1=8.8.8.8
```

Where:

* `IPADDR` – any available IP address in the range assigned to the dedicated server (can also be an alias IP)
* `PREFIX` – the subnet mask of the IP address range (can be /32 for an alias IP)
* `GATEWAY` – the IP address of the gateway in the public network

### Ubuntu

`/etc/netplan/00-installer-config.yaml`

```yaml
network:
  ethernets:
    eth0:
      addresses:
      - 188.42.29.222/32
      gateway4: 188.42.128.203
      nameservers:
        addresses: [8.8.8.8, 1.1.1.1]
        search: []
  version: 2
```

`/etc/network/interfaces`

```
iface eth0 inet static
address 188.42.29.222
mask 255.255.255.255
gateway 188.42.128.203
```

Where:

* Address: any available IP in the range assigned to the dedicated server (can also be an alias IP)
* Mask: the subnet mask (255.255.255.255 for a /32 alias IP)
* Gateway: the IP address of the gateway in the public network


# How to configure the network on Proxmox VE 6.4-7.4 virtual machines on dedicated servers (/docs/tutorials/virtualization/configure-network-proxmox-ve-6-4-7-4)



These instructions are suitable for Proxmox VE versions 6.4 and 7.4.

When creating a virtual machine, you need to select a bridge interface to which the virtual machine's network port will be connected. If two network ports are required, the second one can be added via the web interface: **Hardware** → **Add** → **Network device**. Then, you can configure IP addresses and the gateway on the respective interfaces within the virtual machine.

For example, configure the alias IP on the interface connected to **vmbr1** along with the corresponding **default route**, while the private IP and routes are configured on the interface connected to **vmbr0**.

## Ubuntu 20.04-22.04

An IP address from the server's additional public network is used for the public network. One of the free IPs from the main private network is used for the private network. The interface `ens18` is created during VM deployment; `ens19` is added via the web interface.

`/etc/netplan/00-installer-config.yaml`

```yaml
network:
  ethernets:
    ens18:
      dhcp4: false
      addresses:
      - $IP/$NETMASK
      routes:
        - to: 0.0.0.0/0
          via: $PUBLIC_GW
          on-link: true
      nameservers:
        addresses:
        - $DNS_SERVERS
    ens19:
      dhcp4: false
      addresses:
      - $PRIVATE_IP/$NETMASK
      routes:
        - to: 10.0.0.0/8
          via: $PRIVATE_GW
        - to: 192.168.0.0/16
          via: $PRIVATE_GW
        - to: 188.42.208.0/21
          via: $PRIVATE_GW
      nameservers:
        addresses:
        - $DNS_SERVERS
  version: 2
```

Where:

* `$IP` – any available IP address in the range assigned to the dedicated server (can also be an alias IP)
* `$NETMASK` – the subnet mask (can be /32 if configuring an alias IP)
* `$PRIVATE_IP` – the private IP address available to the dedicated server
* `$PUBLIC_GW` – the IP address of the gateway in the public network
* `$PRIVATE_GW` – the IP address of the gateway in the private network
* `$DNS_SERVERS` – DNS servers available to the dedicated server (e.g., `192.168.8.8`)

## Debian 11-12

The interface `ens18` is created during VM deployment; `ens19` is added via the web interface.

`/etc/network/interfaces`

```
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
```

`/etc/network/interfaces.d/ens18`

```
auto ens18
iface ens18 inet static
address $PUBLIC_ADDITIONAL_IP/$NETMASK
gateway $GW_OF_THE_ADDITIONAL_NETWORK
```

`/etc/network/interfaces.d/ens19`

```
auto ens19
iface ens19 inet static
address $PRIVATE_ADDITIONAL_IP/$NETMASK
post-up /sbin/ip route add 10.0.0.0/8 via $GW_OF_THE_ADDITIONAL_NETWORK dev ens19
post-up /sbin/ip route add 192.168.0.0/16 via $GW_OF_THE_ADDITIONAL_NETWORK dev ens19
post-up /sbin/ip route add 188.42.208.0/21 via $GW_OF_THE_ADDITIONAL_NETWORK dev ens19
```

Where:

* `$PUBLIC_ADDITIONAL_IP` – any available public IP address of the additional network
* `$PRIVATE_ADDITIONAL_IP` – any available private IP address of the additional network
* `$GW_OF_THE_ADDITIONAL_NETWORK` – the IP address of the gateway in the additional network

## AlmaLinux / CentOS 8 Stream

The interface `ens18` is created during VM deployment; `ens19` is added via the web interface.

`/etc/sysconfig/network-scripts/ifcfg-ens18`

```
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
NAME=ens18
DEVICE=ens18
ONBOOT=yes
IPADDR=$PUBLIC_IP
NETMASK=255.255.255.248
GATEWAY=$PUBLIC_GW
ETHTOOL_OPTIONS="-K ens18 tx off tso off"
```

`/etc/sysconfig/network-scripts/ifcfg-ens19`

```
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=no
NAME=ens19
DEVICE=ens19
ONBOOT=yes
ETHTOOL_OPTIONS="-K ens19 tx off tso off"
IPADDR=$PRIVATE_IP
NETMASK=255.255.255.248
```

`/etc/sysconfig/network-scripts/route-ens19`

```
10.0.0.0/8 via $PRIVATE_GW dev ens19
192.168.0.0/16 via $PRIVATE_GW dev ens19
188.42.208.0/21 via $PRIVATE_GW dev ens19
```

Where:

* `$PRIVATE_IP` – the private IP address available to the dedicated server
* `$PUBLIC_IP` – the public IP address available to the dedicated server
* `$PUBLIC_GW` – the IP address of the gateway in the public network
* `$PRIVATE_GW` – the IP address of the gateway in the private network


# Virtualization (/docs/tutorials/virtualization)



This section covers network configuration guides for virtual machines running on dedicated servers. When you run a hypervisor such as Proxmox VE, VMware ESXi, or Microsoft Hyper-V on a dedicated server, you need to correctly configure the virtual machine network to use the IP addresses and gateways assigned to your physical server.

Note that provisioning, installation, and configuration of virtual machines and their network settings are not included in unmanaged support — these guides are provided as a reference for customers managing their own virtual infrastructure.


# Virtual machines and support responsibilities (/docs/tutorials/virtualization/virtual-machines-and-support-responsibilities)



EBM server users can independently install and deploy virtual machines and connect them to available networks.

However, provisioning, installation, and configuration of these virtual machines, as well as network setup on them, are **not included in unmanaged support**.

This means that while Servers.com provides and maintains the underlying physical dedicated server hardware and network connectivity, the configuration of hypervisors (Proxmox, ESXi, Hyper-V, etc.) and their virtual machines is the customer's responsibility.

For guidance on configuring network settings for virtual machines on common hypervisors, refer to the other articles in this section:

* [How to configure the network on Proxmox VE 6.4-7.4 virtual machines on dedicated servers](/tutorials/virtualization/configure-network-proxmox-ve-6-4-7-4)
* [How to configure the network on ESXi 5.5/6.0/6.6 virtual machine on dedicated servers](/tutorials/virtualization/configure-network-esxi-5-5-6-0-6-6)
* [How to configure the network on Hyper-V virtual machine on dedicated servers](/tutorials/virtualization/configure-network-hyper-v)


# How to connect to a Windows server (/docs/tutorials/windows-administration/connect-to-windows-server)

























































































This article provides a step-by-step guide for connecting to a Windows server from Windows, macOS, Linux, iOS, and Android. It also covers how to transfer files between your local machine and the remote server.

### Before you start

Make sure the server is powered on. You will need the server's IP address, username, and password — these are provided in the welcome email sent during server setup.

### Connecting from Microsoft Windows

Windows includes the built-in **Remote Desktop Connection** client (`mstsc`).

1. Open the **Start** menu, type **mstsc**, and press **Enter**.

<img alt="Open Start and type mstsc" src={__img0} />

2. Click **Show Options** in the Remote Desktop Connection window.

<img alt="Click Show Options" src={__img1} />

3. On the **General** tab, enter your server's IP address in the **Computer** field, the username in the **User name** field, and check **Allow me to save credentials**.

<img alt="Remote Desktop Connection settings" src={__img2} />

4. **Optional — share local drives for file transfer:**
   * Switch to the **Local Resources** tab.

<img alt="Switch to Local Resources tab" src={__img3} />

* Click **More**.

<img alt="Click More" src={__img4} />

* Expand **Drives**, select the drives to share, and click **OK**.

<img alt="Select drives to share and click OK" src={__img5} />

5. Click **Connect**.

<img alt="Click Connect" src={__img6} />

6. Enter your password and click **OK**.

<img alt="Enter credentials" src={__img7} />

7. Click **Yes** to accept the certificate. The connection will be established.

<img alt="Accept the certificate" src={__img8} />

If you shared drives, they will appear as additional drives under **This PC** in Windows Explorer on the server.

### Connecting from macOS

Install the official **Windows App** from the [Mac App Store](https://apps.apple.com/us/app/windows-app/id1295203466?mt=12).

#### Add the server

1. In the top menu, click **Connections → Add PC**.

<img alt="Add PC in Windows App on macOS" src={__img9} />

2. On the **General** tab, enter the server IP in the **PC name** field.

<img alt="Enter server IP address" src={__img10} />

3. In the **Credentials** drop-down, select **Add Credentials** and enter your username and password. Click **Add**.

<img alt="Add credentials" src={__img11} />

<img alt="Enter username and password" src={__img12} />

#### Optional — share folders for file transfer

1. Switch to the **Folders** tab, check **Redirect folders**, click **+**, and choose a folder. Click **Add**.

<img alt="Redirect folders for file transfer" src={__img13} />

<img alt="Click Add to confirm folder selection" src={__img14} />

#### Connect

1. On the **Devices** tab, click your saved server.

<img alt="Click the saved server in Devices" src={__img15} />

2. Click **Continue** to accept the certificate. The connection opens.

<img alt="Accept the certificate" src={__img16} />

### Connecting from Linux

Install [Remmina](https://remmina.org/how-to-install-remmina/), then:

1. Click the **New Connection** button in the top-left corner.

<img alt="New connection button in Remmina" src={__img17} />

2. Enter the server address, username, and password in their respective fields.

<img alt="Enter server address and credentials in Remmina" src={__img18} />

3. In the **Protocol** drop-down, select **RDP**.

<img alt="Select RDP protocol" src={__img19} />

4. Set **Color depth** to **True color (32 bpp)**.

<img alt="Set color depth to True color 32bpp" src={__img20} />

5. **Optional — share a folder:** check **Share folder**, select the folder from the drop-down, then click **Save and Connect**.

<img alt="Share a folder and click Save and Connect" src={__img21} />

### Connecting from iOS (iPhone / iPad)

Install **Windows App Mobile** from the [App Store](https://apps.apple.com/us/app/windows-app-mobile/id714464092).

1. Open the app. Decline the Bluetooth and local network permission requests — they are not needed.

<img alt="Decline Bluetooth permission" src={__img22} />

<img alt="Decline local network permission" src={__img23} />

2. Skip the welcome screen.

<img alt="Welcome screen" src={__img24} />

3. Tap **+** at the top, then select **PC**.

<img alt="Tap + to add a PC" src={__img25} />

<img alt="Select PC" src={__img26} />

4. Tap **PC Name**, enter the server address, and return to the previous screen.

<img alt="Tap PC Name" src={__img27} />

<img alt="Enter server IP" src={__img28} />

5. Tap **Credentials → Add Credentials**, enter username and password, tap **Save**, and return.

<img alt="Tap Credentials" src={__img29} />

<img alt="Add Credentials" src={__img30} />

<img alt="Enter credentials" src={__img31} />

<img alt="Select saved account" src={__img32} />

6. Tap **Save**.

<img alt="Tap Save" src={__img33} />

7. Rotate your device sideways and tap the server card on the **Devices** tab.

<img alt="Saved devices list" src={__img34} />

<img alt="Remote connection in progress" src={__img35} />

<img alt="Remote Windows desktop on iPhone" src={__img36} />

### Connecting from Android

Install the **Microsoft Remote Desktop** app from [Google Play](https://play.google.com/store/apps/details?id=com.microsoft.rdc.androidx).

1. Accept the license agreement on first launch.

<img alt="Accept license agreement" src={__img37} />

2. Tap **+** in the top-right corner and select **Add PC**.

<img alt="Tap + and select Add PC" src={__img38} />

3. Enter the server address in **PC NAME**, then under **USER ACCOUNT** select **Add user account** and enter your credentials.

<img alt="Enter server address" src={__img39} />

<img alt="Add user account" src={__img40} />

4. Tap **SAVE** twice.
5. Rotate your device sideways. On the **PCs** tab, tap your server card.

<img alt="Rotate device and tap server card" src={__img41} />

6. On the certificate pop-up, check **Never ask again** and tap **CONNECT**.

<img alt="Accept certificate and connect" src={__img42} />


# How to configure network on Windows Server 2012 (/docs/tutorials/windows-administration/how-to-configure-network-on-windows-server-2012)























For the correct operation of the network on Windows — regardless of whether connection redundancy is ordered for a server or not — you must set up link teaming (aggregating two physical interfaces into one logical interface).

Servers with link aggregation have five network ports: two connected to a pair of switches on the private network, two on the public network, and one for out-of-band (OOB) management. Link teaming is configured for each pair of public and private ports using the LACP protocol. By convention:

* **aggi** — private network aggregation interface
* **agge** — public network aggregation interface

### Setting up link aggregation

Open **Server Manager**, go to **Local Server**, and in the **Properties** panel click **Disabled** next to **NIC Teaming**.

<img alt="NIC Teaming disabled in Server Manager" src={__img0} />

In the NIC Teaming window, open the **Tasks** drop-down in the **Teams** section and select **New Team**.

<img alt="New Team option in NIC Teaming" src={__img1} />

Configure the **private network** team first:

1. Set the team name to **aggi**.
2. Select **int1** and **int2** as member adapters.
3. Set **Teaming mode** to **LACP**.
4. Leave **Load balancing mode** as **Dynamic**.
5. Click **OK**.

<img alt="Configure aggi team for private network" src={__img2} />

If your system shows different adapter names in **Member adapters**, contact technical support.

Repeat the same process for the **public network** team, using:

* **Team name**: agge
* **Member adapters**: ext1 and ext2

<img alt="Configure agge team for public network" src={__img3} />

### Configuring IPv4

After both teamed interfaces are created, configure IPv4 for each. You will need the private IP, public IP, and gateway addresses — all available on the server's **Details** page in the Customer Portal.

<img alt="Server details page in the Customer Portal" src={__img4} />

Open **Control Panel → Network and Internet → Network and Sharing Center → Change adapter settings**. Right-click **aggi** and select **Properties**.

<img alt="Adapter settings showing aggi interface" src={__img5} />

Select **Internet Protocol Version 4 (TCP/IPv4)** and click **Properties**.

<img alt="Select IPv4 in adapter properties" src={__img6} />

Enter the following values for **aggi** (private network):

* **IP address**: your server's private IP address
* **Subnet mask**: 255.255.255.248
* **Default gateway**: leave blank
* **Preferred DNS server**: 192.168.8.88
* **Alternate DNS server**: 192.168.8.8

Click **OK**.

<img alt="IPv4 settings for the private network interface" src={__img7} />

Repeat for **agge** (public network):

* **IP address**: your server's public IP address
* **Subnet mask**: 255.255.255.248
* **Default gateway**: your public gateway IP
* **Preferred DNS server**: leave blank
* **Alternate DNS server**: leave blank

Click **OK**.

<img alt="IPv4 settings for the public network interface" src={__img8} />

### Adding static routes

Press **Win + R**, type **cmd**, and click **OK**. Run the following command to find the interface index numbers:

```
netsh int ipv4 show interfaces
```

<img alt="Interface index numbers from netsh command" src={__img9} />

In the example above, **aggi** has index 5 and **agge** has index 8. Now add the static routes, replacing the placeholders with your actual values:

```
route -p add 192.168.0.0 mask 255.255.0.0 [Private_Gateway_IP] if [Private_Interface_ID]
route -p add 188.42.208.0 mask 255.255.248.0 [Private_Gateway_IP] if [Private_Interface_ID]
route -p add 10.0.0.0 mask 255.0.0.0 [Private_Gateway_IP] if [Private_Interface_ID]
```

Using the example values:

```
route -p add 192.168.0.0 mask 255.255.0.0 10.148.197.76 if 5
route -p add 188.42.208.0 mask 255.255.248.0 10.148.197.76 if 5
route -p add 10.0.0.0 mask 255.0.0.0 10.148.197.76 if 5
```

Network configuration is now complete.


# How to reset an administrator password on Windows on a dedicated server (/docs/tutorials/windows-administration/how-to-reset-admin-password-windows)











You can reset a Windows administrator password using two methods: using a Windows installation image, or using Rescue mode.

### Method 1: Using a Windows installation image

To reset the administrator account password for a 2012–2022 Windows server:

1. Download a Windows installation image from the official [Microsoft Evaluation Center](https://www.microsoft.com/en-gb/evalcenter/)
2. Connect the installation image to iDRAC according to [How to boot a server into a custom ISO image using iDRAC](/tutorials/idrac-boot-management/how-to-boot-server-custom-iso-idrac)
3. Boot with the installation image and click **Next** in the **Windows Setup** window

<img alt="Windows Setup window with Next button" src={__img0} />

4. Click **Repair your computer**

<img alt="Repair your computer option in Windows Setup" src={__img1} />

5. Choose **Troubleshoot**

<img alt="Troubleshoot option on the recovery screen" src={__img2} />

6. In the **Advanced options** window, click **Command Prompt**

<img alt="Advanced options screen with Command Prompt selected" src={__img3} />

7. In the command line, run the following commands (where X is the letter of the disk on which Windows is installed):

   ```
   X:
   cd windows\system32
   ren Utilman.exe Utilman.exe.old
   copy cmd.exe Utilman.exe
   ```

8. Close the command line and click **Continue** — the server will reboot

9. Press **Windows Key + U** on the login screen

10. Run the following command in the command prompt, replacing `Password123` with your desired password (case-sensitive):

    ```
    net user administrator Password123
    ```

    After closing the command prompt, you can log into the OS using the new password.

### Method 2: Using rescue mode

1. Open the command prompt using Win+R and shut down Windows correctly:

   ```
   shutdown /s
   ```

2. Open the [Customer Portal](https://portal.servers.com/login) and navigate to **Dedicated Servers** → **Manage**

3. Choose the server and click **Details**

4. In the **Details** section, click **Reboot to rescue**

Credentials will be sent to the email addresses of contacts with the **primary** and **technical** roles.
5\. Log in to rescue mode using the credentials you received
6\. Find the partition where the OS was installed (usually `/dev/sda1`):

```bash
fdisk -l
```

7. Mount the partition:

   ```bash
   ntfs-3g -o force /dev/sdX /mnt
   ```

   If you see an error about unsafe state, run `ntfsfix /dev/sdX` first.

8. Navigate to the config folder:

   ```bash
   cd /mnt/Windows/System32/config/
   ```

9. Use the `chntpw` utility to reset the password:

   ```bash
   chntpw -u Administrator SAM
   ```

10. Press **1** and confirm overwriting of SAM file by pressing **Y**

Remove the server from rescue mode and run the operating system. You will not need to enter an administrator password when logging in. You can set a new password by pressing **Ctrl+Alt+Del** and clicking **Change password**.


# Windows administration (/docs/tutorials/windows-administration)



This section covers essential administration tasks for Windows servers hosted on the Servers.com platform — from connecting via RDP on any device and configuring network interfaces, to hardening your server against brute-force attacks and collecting diagnostics for support.

### Explore Windows Administration

<Cards>
  <Card title="Connect to a Windows Server" description="Connect via RDP from Windows, macOS, Linux, iOS, and Android." href="/tutorials/windows-administration/connect-to-windows-server" />

  <Card title="Protect Admin Account from Brute-Force" description="Use a PowerShell script to harden RDP and prevent lockouts." href="/tutorials/windows-administration/prevent-admin-account-brute-force-lockout" />

  <Card title="Configure Network on Windows Server 2012" description="Set up LACP link teaming, IPv4, and static routes." href="/tutorials/windows-administration/how-to-configure-network-on-windows-server-2012" />

  <Card title="Network Diagnostics for Support" description="Run ping, traceroute, and ipconfig and share results with support." href="/tutorials/networking-and-ip-management/how-to-provide-network-diagnostic-results" />
</Cards>


# How to protect your administrator account from brute-force lockout (/docs/tutorials/windows-administration/prevent-admin-account-brute-force-lockout)



By default, Windows exposes its RDP port to the internet, making it an attractive target for brute-force attacks. When an attack occurs, the administrator account may be blocked after numerous failed login attempts. If this happens, you could lose access to the server until the issue is resolved.

To prevent this, use the PowerShell script below. It changes default RDP settings and makes it difficult for attackers to target you with malicious activity.

### How the script works

The script has two sections:

1. **Configuration section** — lets you choose which protections to enable by uncommenting the relevant lines (remove the `#` at the start of the line).
2. **Code section** — performs the actual work. Do not modify this part.

Insert the script into the **user data** field when ordering a server or reinstalling an operating system.

The script is designed for **Windows Server 2016, 2019, 2022, and 2025**.

### Available options

| Option                               | Description                                                                                                                                                         |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `$AdministratorAccountLoginName`     | Renames the built-in Administrator account to a custom name.                                                                                                        |
| `$RDPPort`                           | Changes the RDP port from the default 3389 to a custom port. Triggers an additional reboot during installation.                                                     |
| `$TrustedClients`                    | Restricts RDP access to specific trusted IP addresses or ranges. Recommended when connecting from static IPs.                                                       |
| `$EnableAdministratorAccountLockout` | Enables automatic lockout of the Administrator account after repeated failed logins (KB5020282). Enable only after creating a separate admin account for daily use. |
| `$DisableRemoteDesktop`              | Disables RDP entirely. Recommended if you access the server only via WinRM, SSH, or another protocol. Takes precedence over all other RDP settings.                 |

### User data script

```powershell
#ps1
# BEGINNING OF THE CONFIGURATION SECTION

# When an RDP port is exposed to the Internet, it may be a target of brute-force attacks.
# This may lead to your server being compromised, administrative account lockouts etc. This script helps you to reduce those risks.
# You may amend the script in accordance with your requirements.
# To enable settings you need, remove the octothorpe (#) symbol from the beginning of that line.

# Renames the built-in Administrator account.
# Make sure that your software / scripts support the built-in Administrator account having a non-default name.

    # $AdministratorAccountLoginName = 'ExampleNewLoginName'

# A new RDP port number instead of the default 3389.
# Enabling this parameter triggers an additional reboot during server installation.

    # $RDPPort = 3403

# Restricts RDP access only to trusted IP addresses.
# This parameter is recommended when you connect to the server from static IP addresses.
# Do not use if your RDP clients use dynamic IP addresses.
# You can specify here a range of IP addresses that your ISP allocated to you.

    # $TrustedClients = @('10.0.0.0/8', '192.0.2.1')

# Enables lockout for the built-in Administrator account.
# In KB5020282 Microsoft introduced a new feature to automatically lockout the Administrator account when a malicious actor tries to brute-force its password.
# While enabling this setting increases security of your system, if your server is exposed to the Internet, the Administrator account will be locked-out almost immediately.
# Therefore, prior to enabling this setting, we recommend you to create a separate account with administrative privileges and use it for daily administrative tasks.

    # $EnableAdministratorAccountLockout = $true

# Disables Remote Desktop server.
# We recommend you to enable this setting if you access your server only via WinRM, SSH, or some other protocol that is not RDP.
# This setting takes precedence over the RDP port and trusted clients settings.

    # $DisableRemoteDesktop = $true

# END OF THE CONFIGURATION SECTION

#Requires -Version 5

if ($AdministratorAccountLoginName) {
    $BuiltInAdministrator = Get-LocalUser | Where-Object -FilterScript { $_.SID -like 'S-1-5-21-*-500' }
    Rename-LocalUser -InputObject $BuiltInAdministrator -NewName $AdministratorAccountLoginName
}

if ($EnableAdministratorAccountLockout) {
    $SecurityPolicyTempFileName = Join-Path -Path $env:TEMP -ChildPath (New-Guid).Guid
    $SecurityDBTempFileName = Join-Path -Path $env:TEMP -ChildPath (New-Guid).Guid
    secedit /export /cfg $SecurityPolicyTempFileName /quiet
    (Get-Content -Path $SecurityPolicyTempFileName).Replace('AllowAdministratorLockout = 0', 'AllowAdministratorLockout = 1') | Set-Content -Path $SecurityPolicyTempFileName
    secedit /configure /db $SecurityDBTempFileName /cfg $SecurityPolicyTempFileName /areas SECURITYPOLICY /quiet
    Remove-Item -Path $SecurityPolicyTempFileName -Force
    Remove-Item -Path $SecurityDBTempFileName -Force
}

if ($DisableRemoteDesktop) {
    Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name 'fDenyTSConnections' -Value 1 -Force
    Set-NetFirewallRule -Name 'RemoteDesktop-UserMode-In-TCP' -Enabled False
    Set-NetFirewallRule -Name 'RemoteDesktop-UserMode-In-UDP' -Enabled False
}
else {
    if ($TrustedClients -or $RDPPort) {
        $SetNetFirewallRuleParameters = @{}

        if ($TrustedClients) {
            $SetNetFirewallRuleParameters.Add('RemoteAddress', $TrustedClients)
        }
        if ($RDPPort) {
            $SetNetFirewallRuleParameters.Add('LocalPort', $RDPPort)
        }

        Set-NetFirewallRule -Name 'RemoteDesktop-UserMode-In-TCP' -Enabled True @SetNetFirewallRuleParameters
        Set-NetFirewallRule -Name 'RemoteDesktop-UserMode-In-UDP' -Enabled True @SetNetFirewallRuleParameters

        if ($RDPPort) {
            Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'PortNumber' -Value $RDPPort -Force
            # Exit code 1001 triggers cloudbase-init to reboot the host after finishing userscripts plugin and not run it again after the reboot.
            exit 1001
        }
    }
}
```


# What's new on Servers.com (/docs/news)



# What's new in 2026 (/docs/news/2026)



# January 2026 (/docs/news/2026/news-01-26)



<NewsSection tags={['billing']}>
  ### Private rack invoices — description field and faster generation

  Private rack charges on invoices are easier to identify, and large invoice files are always available for download without delays.

  * custom description can be defined per private rack entity and appears in invoices
  * invoice generation for large files has been made faster and more reliable

  <Badge type="improved" />

  <Tag>
    Billing
  </Tag>
</NewsSection>

<NewsSection tags={['account', 'platform', 'dns']}>
  ### IAM permissions — extended to PTR records and additional network ordering

  More operations across the platform are now covered by IAM, reducing gaps in access control.

  * PTR record management is now subject to IAM permission checks
  * ordering additional networks no longer fails when switching between accounts in a multi-account setup

  <Badge type="improved" />

  <Tag>
    Account
  </Tag>

  <Tag>
    DNS
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>


# February 2026 (/docs/news/2026/news-02-26)



<NewsSection tags={['billing']}>
  ### Pre-paid service billing — ECB exchange rates applied

  Invoices and charges for pre-paid services are calculated using up-to-date currency conversions from European Central Bank rather than a fixed monthly rate.

  <Badge type="improved" />

  <Tag>
    Billing
  </Tag>
</NewsSection>

<NewsSection tags={['platform', 'account']}>
  ### Account settings page — redesigned, 2FA guidance improved

  The account settings page has an improved layout and 2FA enforcement guidance on what to do next. More in [Enforce 2FA](/account/enforce-2fa).

  * account settings page layout redesigned for easier navigation
  * 2FA setup flow includes better UX guidance when 2FA is enforced at the organisation level

  <Badge type="improved" />

  <Tag>
    Account
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['platform', 'direct_connect']}>
  ### IAM permissions — extended to Direct Connect and Portal dashboard widgets

  Identity and Access Management permissions have been extended:

  * all Direct Connect operations are now subject to IAM permission checks
  * Portal dashboard widgets are hidden for users who lack the required permissions

  <Badge type="improved" />

  <Tag>
    Direct Connect
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['account']}>
  ### Contact-level permissions — managed independently from account-level administrative scope

  Account administrators have finer-grained control over what contacts can do without affecting account-wide settings.

  <Badge type="improved" />

  <Tag>
    Account
  </Tag>
</NewsSection>

<NewsSection tags={['managed_kubernetes']}>
  ### Kubernetes minor version upgrades — self-service

  Kubernetes clusters can be upgraded to a new minor version directly from the Customer Portal, with full control over how worker nodes are upgraded. More in [Kubernetes upgrades](/managed-kubernetes/upgrades).

  * supported upgrade paths: versions 1.27 through 1.35
  * configurable upgrade strategy per node batch: drain with halt, drain with skip, drain with force, or force
  * configurable batch size and delay between batches
  * per-node upgrade status visible in real time during the upgrade
  * individual failed nodes can be retried
  * per-node report available for download after upgrade

  *Note: clusters cannot be downgraded. Upgrades proceed one minor version at a time.*

  <Badge type="new" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>

<NewsSection tags={['sbm']}>
  ### Scalable Bare Metal — available

  Physical dedicated servers are available on an hourly, no-commitment basis in four predefined configurations. More in [Scalable Bare Metal](/sbm/getting-started).

  * available flavors range from 8-core entry to dual-socket 56-core with NVMe storage and up to 10 Gbps networking
  * available in AMS7, WAS4, DFW5, and SJC2;
  * average provisioning time \~15 minutes;
  * billing is hourly; public outbound traffic charged per GB; private traffic is free
  * manageable via Customer Portal, `/v1/hosts/sbm_servers` PAPI endpoint, and Terraform

  <Badge type="new" />

  <Tag>
    Scalable Bare Metal
  </Tag>
</NewsSection>


# March 2026 (/docs/news/2026/news-03-26)



<NewsSection tags={['platform', 'account']}>
  ### IAM — beta release with updated Team and Permission Policy management

  Identity and Access Management is now in beta, with documentation and UX improvements that make it easier to configure access control for account members and resource groups. More in [IAM documentation](/account/iam).

  <Badge type="improved" />

  <Tag>
    Account
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['managed_kubernetes']}>
  ### Kubernetes Node Groups — available

  Worker nodes can be grouped within a cluster to separate workloads logically and apply consistent scheduling labels across a group. More in [Node Groups](/managed-kubernetes/node-groups).

  * create, rename, and delete node groups from the Portal or via `/v1/kubernetes_node_groups` PAPI endpoint
  * nodes can be assigned to a group at add time, or moved later individually or in bulk
  * existing clusters have been automatically included into a default node group

  <Badge type="new" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>

<NewsSection tags={['managed_kubernetes']}>
  ### Kubernetes worker nodes — addable in nearby locations

  When the cluster's primary location has no available bare-metal capacity, worker nodes can be added in a nearby location with the same location prefix (e.g. AMS2 or AMS3 for a cluster in AMS1). More in [Add a worker node](/managed-kubernetes/service-management).

  * cross-location connectivity handled automatically over GPN; no manual network configuration required
  * Portal shows a Location selector when adding a node and a Location column in the nodes list

  <Badge type="new" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>


# April 2026 (/docs/news/2026/news-04-26)



<NewsSection tags={['platform', 'account']}>
  ### IAM permission policies — export and import across accounts

  Permission policies can be exported to JSON and imported into other accounts, making it easier to maintain consistent access configurations across a multi-account organisation. More in [IAM documentation](/account/iam).

  <Badge type="new" />

  <Tag>
    Account
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['platform']}>
  ### SSL certificate renewal errors — actionable messages returned

  An issue that caused SSL certificate renewal failures to return unclear error responses has been resolved; the API now returns specific, actionable messages.

  <Badge type="fixed" />

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['rbs']}>
  ### Remote Block Storage — available in beta

  Scalable block storage can be added to servers without replacing or installing local disks. More in [Remote Block Storage](/rbs/getting-started).

  * create, attach, resize, disable, and delete volumes via Customer Portal, Public API, Terraform, and Kubernetes (RBS CSI driver)
  * currently available in AMS7; volumes can be used from other locations, but IOPS and bandwidth depend on network latency
  * volumes can be resized and temporarily disabled without deletion

  *Note: this is a beta release. For best performance, use RBS with servers in the same datacenter (AMS7).*

  <Badge type="new" />

  <Tag>
    Remote Block Storage
  </Tag>
</NewsSection>

<NewsSection tags={['managed_kubernetes']}>
  ### Managed Kubernetes — pod limit increased to 250 per node

  New clusters support up to 250 pods per worker node, up from 110. The Pod CIDR per node has been widened to /23 to accommodate the higher pod count.

  *Note: applies to new clusters only. Existing clusters and nodes added to existing clusters are unaffected. No action required.*

  <Badge type="improved" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>

<NewsSection tags={['ebm']}>
  ### iPXE boot — available for EBM servers

  EBM servers can boot from a custom iPXE script over the network on every start, without going through the standard OS installer. More in [Public API](/api-reference/ipxe-boot/).

  * two modes available: public iPXE boot (via public network interface) and private iPXE boot (via private interface)
  * script URL and optional `user_data` string configurable without reprovisioning
  * MAC addresses and DNS server addresses automatically injected as variables before the script runs
  * activate at order time via the `features` field, or on an existing server via `/features/public_ipxe_boot/activate` or `/features/private_ipxe_boot/activate`
  * to update the script on a running server: deactivate, update `ipxe_config` via `PUT`, reactivate, and reboot

  <Badge type="new" />

  <Tag>
    Enterprise Bare Metal
  </Tag>
</NewsSection>


# May 2026 (/docs/news/2026/news-05-26)



<NewsSection tags={['platform', 'account']}>
  ### GPG key management — governed by IAM permissions

  Access to GPG key creation and deletion in the Portal is now controlled by IAM permissions, consistent with other key management operations.

  <Badge type="improved" />

  <Tag>
    Account
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>


# June 2026 (/docs/news/2026/news-06-26)



<NewsSection tags={['managed_kubernetes']}>
  ### Managed Kubernetes — controlled version lifecycle introduced

  Managed Kubernetes clusters now follow a support lifecycle for Kubernetes versions, keeping clusters on supported and secure versions.

  * each Kubernetes version now has three lifecycle dates: maintenance start, end-of-life (EOL), and automatic upgrade
  * notifications appear in the portal and by email as a cluster approaches each date
  * when a cluster reaches its automatic upgrade date and a safe upgrade path exists, the cluster is upgraded to a supported version, using the configured maintenance window where possible

  Current version status and upgrade dates are shown in the Managed Kubernetes section of the portal.

  *Note: a cluster that fails auto-upgrade three times is flagged for unmanaged conversion, which starts the offboarding notice sequence.*

  More in [version support policy](https://www.servers.com/docs/managed-kubernetes/version-support-policy/)

  <Badge type="new" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>

<NewsSection tags={['managed_kubernetes']}>
  ### Managed Kubernetes — DNS-based high availability API

  Cluster API access can now stay reachable through DNS endpoints instead of a single IP, reducing disruption during failover.

  * Portal, and kubeconfig generation support public and private DNS endpoints in the form `public.<zone>:6443` / `private.<zone>:6443`
  * enabled by default for new clusters
  * existing IP-based kubeconfigs remain fully compatible

  <Badge type="new" />

  <Tag>
    Managed Kubernetes
  </Tag>
</NewsSection>

<NewsSection tags={['l2_segments', 'platform']}>
  ### Resource groups — aggregative type added for L2 Segments

  L2 Segments can now be organized and access-controlled through IAM the same way other resources are.

  * a resource group type — Aggregative or Resource-based — must be chosen on creation
  * a default aggregative resource group is created automatically and existing L2 Segments assigned to it
  * L2 Segment pages now respect IAM permissions for Hosts, Kubernetes nodes, and Direct Connect

  <Badge type="new" />

  <Tag>
    L2 Segments
  </Tag>

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['load_balancer']}>
  ### L7 Load Balancer — GRPC and HTTP/2 combination restricted

  New load balancers can no longer be created with a protocol combination known to cause issues.

  * creating or editing an L7 load balancer is now blocked when GRPC/GRPCs protocols are combined with HTTP/2 enabled

  *Note: existing load balancers already using this combination are unaffected and continue to work.*

  <Badge type="improved" />

  <Tag>
    Load Balancer
  </Tag>
</NewsSection>

<NewsSection tags={['platform']}>
  ### AI Compute — access request form enabled

  Customers interested in AI Compute can now request access directly from the [Customer Portal](https://portal.servers.com/ai-compute/welcome) instead of contacting sales separately.

  <Badge type="new" />

  <Tag>
    Platform
  </Tag>
</NewsSection>

<NewsSection tags={['platform']}>
  ### Dedicated servers — OS reinstall via Terraform

  Dedicated server reinstalls can now be scripted as part of infrastructure-as-code workflows.

  Reinstalling the operating system on dedicated servers is now supported through the [Terraform provider](https://registry.terraform.io/providers/serverscom/serverscom/latest/docs/resources/dedicated_server).

  <Badge type="new" />

  <Tag>
    Platform
  </Tag>
</NewsSection>