Certain domain extensions require you to supply extra information before your registration can be completed. This information is collected in addition to your standard contact details. It depends on the domain extension, your location, and whether you are registering as a private individual or an organisation.

This article explains what is required for each supported domain extension.

.IT – Italian Domains

To register a .it domain, the registrant must be an Italian national or a national of any EU member state. Two scenarios apply depending on whether you are registering as a person or an organisation:

Private Individual (Person)

If you are registering as a private individual, then you must provide the following details:

Organisation

If you are registering as an organisation, then you must provide the following details:

What is Extended Lifecycle Support?

When an operating system (OS) reaches its End-of-Life (EOL) date, the vendor stops issuing security updates, leaving servers and virtual machines on that OS more exposed to vulnerabilities. 

WebPros, the company behind Plesk and cPanel, runs an Extended Lifecycle Support (ELS) program for affected OS versions. This gives customers additional time to plan an upgrade while continuing to receive critical security updates. 

How ELS fees work

Where an ELS program is active, an additional monthly fee applies per control panel license on the affected OS. Leaseweb passes this fee through to customers and it appears as a separate line item on your invoice. 

New ELS fees can be introduced, or prices can be adjusted on a half-yearly or annual basis. Leaseweb will communicate any changes in advance via email. 

Affected operating systems

cPanel

Plesk

How to avoid ELS fees

Upgrading to a supported OS is the only way to remove the ELS fee from your invoice. Leaseweb strongly recommends doing this as soon as possible, as running an EOL OS carries security risks regardless of the ELS program, and fees may increase over time. 

For a list of currently supported operating systems, refer to the official documentation for Plesk and cPanel. 

Leaseweb Managed Kubernetes Availability Target

The monthly Availability of Leaseweb Managed Kubernetes Availability shall be as set forth in the table below (the “Leaseweb Managed Kubernetes Availability Target”).

Leaseweb Managed Kubernetes Services Availability Target is not met in case the following conditions are met:

• all connection requests to the applicable cluster’s Kubernetes endpoint fail after the cluster was successfully created;
• when the number of ready worker nodes is lower than the requested number by more than one (1) node, after the cluster was successfully created; and
• this situation lasts for five (5) or more consecutive minutes.

Read more about the terms and conditions on our website.

• Leaseweb makes commercially reasonable efforts to provide the Leaseweb Managed Kubernetes Availability Target of 99.95% on the Kubernetes control plane of the Leaseweb Managed Kubernetes Services. Leaseweb shall not be held liable for damages if this Service Level is not met. Leaseweb owns the management of the Kubernetes control plane, which is included in the Service Fees.
• Leaseweb will make commercially reasonable efforts to support the scalability of worker nodes. For the avoidance of doubt, the 99.95% the Leaseweb Managed Kubernetes Availability Target applies to the availability of existing worker nodes. Leaseweb shall not be held liable by Customer or any third parties for any damages resulting from an inability to provision additional worker nodes.
• Leaseweb Managed Kubernetes Availability Target does not apply to the accessibility of the Leaseweb Website, Customer Portal or API. the Leaseweb Managed Kubernetes Availability Target is also not applicable (i) when scheduled Maintenance occurs with a minimum of a seventy-two (72) hour notice, (ii) in case of an Excluded Event, or (iii) in case a time-critical update must be applied by Leaseweb.
• In the event that in any calendar month the Leaseweb Managed Kubernetes Availability Target is not met by Leaseweb Customer shall be eligible to receive a Service Credit (the “Leaseweb Managed Kubernetes Availability Credit”). Leaseweb Managed Kubernetes Availability Credit shall be equal to one (1) % of the Monthly Services Fees payable by Customer to Leaseweb for the Leaseweb Managed Kubernetes Services.
• The maximum total amount of Leaseweb Managed Kubernetes Availability Credits that Customer may be eligible to in a particular month, shall be limited to fifty (50)% of the Monthly Services Fees for the Leaseweb Managed Kubernetes Service payable by Customer to Leaseweb.

With the introduction of the Ordering API for VPS, we enable you to order VPS via the API. You can leverage this API to streamline and automate your ordering process, enhancing efficiency and reducing manual effort.

What is included in this release?

• The API supports ordering all available VPS products
• Only verified existing customers who do not need to do prepayment while placing an order via website can place orders via API. To get excluded from prepayment, please reach out to Leaseweb Sales. If you are a new customer, KYC needs to be done before an order via the API can be available.
• Orders are restricted to the sales organisation the API key belongs to
  • For example, with an API key belonging to the US entity, customers can see and order the VPS products available in our US Data Centers
• Available locations
  • Amsterdam (AMS-01)
  • Frankfurt am Main (FRA-01)
  • London (LON-01)
  • Montreal (MTL-02)
  • San Francisco (SFO-12)
  • Singapore (SIN-01)
  • Sydney (SYD-12)
  • Tokyo (TYO-11)
  • Washington DC (WDC-02)

First steps

1. Generate an API key
   • Go to https://secure.leaseweb.com > Administration > API Keys
   • For detailed instructions, refer to API Key Management
2. For all endpoints, you need to set the following header: X-LSW-Auth: {API_KEY}

Endpoints

There are 3 API endpoints available.

1. List all available VPS
2. Get more information on a particular VPS
3. Place the order

1. List endpoint

/products/vps

With this GET endpoint, you can get all the available VPS products for the provided location. The response of this endpoint shows the base price of a VPS. Applicable discounted prices can be queried using the second endpoint.

2. Get a single VPS and its price

/products/vps/{vpsid}

This GET endpoint provides more details about a particular VPS, such as its price, discounts, and all configuration options.

Please note that not all control panels are compatible with the different operating systems. Refer to the link below for compatibility details.

By default, if no operating system is specified in the GET request, Ubuntu 24.04 is chosen as the default, and the response returns the control panels compatible with that operating system. To see the list of compatible control panels with a different operating system, please specify the respective operating system in the request.

Below is an example request to query the details of VPS 3 in AMS-01 location with Ubuntu 22.04 operating system. The response to this request will include the list of compatible control panels with Ubuntu 22.04.

/v1/products/vps/VPS02_3?&location=AMS-01&operatingSystem=Ubuntu 22.04

3. Order a VPS

/products/vps/{vpsid}/order 

A chosen VPS can be ordered with this POST endpoint. To order multiple VPSes, you should send multiple requests.

While placing an order, several extras can be chosen.

• Disk can be upgraded. This upgrade disk is an extra disk that is added to the VPS.
• An operating system can be chosen. This is free of cost. If you don’t provide any parameter for this, by default it is Ubuntu 24.04
• A Control Panel can be added if required. As mentioned above, it needs to be compatible with the selected operating system.
• A Service Level Agreement can be selected.

API Documentation

The API documentation can be found at https://developer.leaseweb.com/docs/#tag/Ordering/operation/getVpsList1

Examples:

Querying all the available VPS products in the Amsterdam entity

curl --location 'https://api.leaseweb.com/ordering/v1/products/vps?location=AMS-01' \
--header 'Content-Type: application/json' \
--header 'X-LSW-Auth: auth'

Querying more details about Leaseweb VPS 3

curl --location 'https://api.leaseweb.com/ordering/v1/products/vps/VPS02_3?location=AMS-01' \
--header 'Content-Type: application/json' \
--header 'X-LSW-Auth: auth'

Ordering Leaseweb VPS 2 in location AMS-01 with Debian 13, a 50GB disk upgrade, Bronze SLA, 1 year billing cycle for a 3-year contract term

curl --location 'https://api.leaseweb.com/ordering/v1/products/vps/VPS02_2/order?location=AMS-01' \
--header 'Content-Type: application/json' \
--header 'X-LSW-Auth: auth' \
--data '{
"operatingSystem": "Debian 13",
"diskUpgrade": "50GB",
"location": "AMS-01",
"serviceLevelAgreement": "BRONZE",
"billingCycle": "1_YEAR",
"contractTerm": "3_YEARS"
}'

Additional Documentation

You can find more information about the VPS product specifications below.

This article explains how to migrate your existing redirects from the Old Redirect Platform to the New Redirect Platform.

Overview

We have introduced a new redirect platform with improved capabilities and HTTPS support. Since this migration is not automated, customers must manually recreate their redirects in the new platform.

What changed?

Migration steps

Migrate Redirects from the old portal to the new portal

1. Log in to Customer Portal
2. Click on “Redirects” from the left menu

3. Click on the “Old redirects page” button in the top right of the page. This will navigate to the old redirects page.

4. In the old redirect page, note down the following values of the redirect that you want to migrate:
   • Domain
   • Redirect Target
   • Type
5. Click the “Go to new redirects” button in the top right of the page. This will take you back to the new redirects page

6. Click the “Create New Redirect” button in the top right

7. Follow the steps from here: Adding a new redirect

Update DNS configuration

Your next step depends on where your DNS is managed.

DNS managed by Leaseweb

If your domain uses Leaseweb nameservers, then:

1. Go to the hosting overview page
2. Search for the domain name
3. Click on Manage DNS
4. Update or create an A record to point to the new redirect platform IP address

DNS managed by an external provider

If your DNS is managed externally, then log in to your DNS provider. And update or create an A record to point to the new redirect platform IP address.

Secure your redirect (HTTPS)

To make your redirect more secure, you can enable HTTPS using the Let’s Encrypt SSL certificate.

In the new redirect platform, this can be done from the Secure page. For step-by-step instructions, please refer to this guide.

Possible downtime/break scenarios

Migration is generally smooth, but issues may occur in the following cases:

• DNS not updated: Redirect will continue pointing to the old platform. The new redirect will not work.
• Incorrect IP Address: Redirect may fail. The domain may not resolve properly.
• Delay in DNS Propagation: Temporary inconsistent behavior, some users may see the old redirect, others may see the new.
• HTTPS Not Enabled: Redirect may fail for HTTPS requests. The browser may show security warnings.
• Old Platform Dependency: If you delete the old redirect before the DNS update completes, this may stop the redirect from working as expected.

To avoid these issues, always follow the best practices:

• Create the redirect in the new platform first
• Update the DNS
• Verify the redirect is working
• Only then, remove the old redirect

Leaseweb offers a variety of uplink capacity and bandwidth options, ranging from 100Mbps to multiple 100Gbps ports.

Uplink types are split in 2 categories: equipment in shared racks (with a shared Top-of-Rack switch) and racks (Dedicated and Colocation). See more details below:

This article focuses on providing a brief overview of the advanced features and how to enable them as part of your backup plans, such as:

1. How to modify a pre-existing protection plan
2. How to configure this protection plan to enable Advanced features
3. What features are not included as part of the standard protection plan

Modify a pre-existing protection plan

To benefit from the advanced features of Acronis, you first need to create or edit a protection plan. The examples below explain the plan settings from the perspective of a pre-existing protection plan.

The following instructions should lead you to the protection plan settings :

1. In the Management / Protection Plans menu
   
2. Select a Protection plan, and click Edit
   
3. Expand the Backup Section by using the light-blue arrow on the side.
   
4. You will now see advanced options available for this protection plan
   
   

Customize Advanced Options

Here is an overview of the different options that are available under a protection plan, and where to find more information about these features. Feel free to enable one or more of these features according to your needs.

Allows Continuous Data Protection (CDP)​

To enable Continuous Data Protection (CDP)​, simply turn on the toggle for “Continuous Data Protection (CDP)​”:

Antivirus & Antimalware protection

To enable Antivirus & Antimalware protection, turn on the associated Toggle and customize the appropriate options.

Data protection map

To enable Data protection map, turn on the associated Toggle and customize the appropriate options.

Backup of applications

For backup application such as 

• Microsoft SQL Server
• Microsoft Exchange Server
• Microsoft Active Directory
• Oracle Database
• cPanel

The following instructions should guide you on how to enable it for the protection plan :

1. Click “Disabled” beside the “Application backup” category
   
2. Select and customize the application you want to backup as part of this Management plan
   
   

For further information about advanced application backup, please visit the following

One-click recovery

Features not available as part of Standard Protection

While a lot of new features were made available as part of Acronis Standard protection, the following features are only available by purchasing a specific package, that will involve additional costs.

Please contact Leaseweb’s sales team to verify availability if you need one of the following features:

Our Managed Kubernetes platform supports the Gateway API – a modern and flexible way to manage ingress and traffic routing in Kubernetes.

You can either use Cilium as your Gateway API provider out of the box or install any other compatible implementation you prefer.
The platform does not require you to use a specific Gateway API provider. You have full control over which implementation you use.

What Is Gateway API?

Gateway API is a native Kubernetes API that standardizes how traffic enters and moves through a cluster. It is meant to be the long-term replacement for the traditional Ingress API.
Compared to Ingress, Gateway API provides:

• A role-oriented model (cluster operators, platform admins, application owners)
• Clear separation between infrastructure (Gateways) and routing rules (Routes)
• First-class support for advanced use cases such as:
  • Multiple listeners (HTTP, HTTPS, TCP, TLS)
  • Cross-namespace routing
  • Fine-grained traffic policies
• A provider-agnostic contract, allowing multiple implementations to coexist

Thanks to these improvements, more teams are choosing the Gateway API as their preferred way of managing traffic in Kubernetes.

Responsibilities and Operational Model

Cluster Administrator Responsibilities

Gateway API uses Custom Resource Definitions (CRDs) that work with all implementations.
The cluster administrator is responsible for:

• Installing the Gateway API CRDs
• Upgrading the Gateway API CRDs when required
• Ensuring CRD versions are compatible with the chosen provider

Managing the CRD lifecycle is kept separate from installing providers. This helps prevent unexpected changes across your cluster.

Using Cilium as a Gateway API Provider

If you decide to use Cilium as your Gateway API provider, follow these steps:

1. Prerequisites required in the Cilium configuration are already considered by us.
2. The following Gateway API CRDs must be installed. Please follow the instructions for installing the gateway CRDs according to Cilium’s Gateway API documentation.
   • Make sure the version of the Gateway API CRDs you chose to install is compatible with the installed Cilium version in your cluster.
3. After installing the Gateway API CRDs, you need to restart the Cilium Components using the following commands:

kubectl -n kube-system rollout restart deployment/cilium-operator 
kubectl -n kube-system rollout restart ds/cilium

Since you are managing the Gateway APIs, it is important to consider these items:

1. Once in a while, we will update Cilium and will announce it to our customers.
   • Do not forget to update CRDs after Cilium Upgrades if it is required.
2. Configure Cilium Gateway resources according to your traffic requirements.

For detailed installation steps, configuration options, and supported Gateway API features, see the official Cilium documentation.

Using Other Gateway API Providers

If you choose another Gateway API provider, you need to follow their documentation accordingly. Check the provider’s documentation for details on supported features, limitations, and how to upgrade. not modify or restrict third-party Gateway API providers.

Summary

• Gateway API is the modern, extensible successor to Ingress. Our platform supports the Gateway API in a provider-agnostic manner.
• Customers remain free to choose and operate alternative implementations.
• Cilium is fully managed and supported as a Gateway API provider.
• Cluster administrators manage Gateway API CRDs.This approach gives you flexibility, follows standards, and ensures long-term compatibility with Kubernetes.          

Bare metal servers deliver raw performance and give full control. Every workload, application, and service running on a Dedicated Server depends directly on the health of its physical components. That makes hardware monitoring not just useful but essential.

Native hardware monitoring via IPMI

For bare metal servers, Leaseweb provides hardware monitoring:

The hardware health metrics are collected directly from the server’s management interface – without having to install an agent on the operating system and thereby ensuring that we do not interfere with the customer environment.

This includes data from sensors such as temperature, power, fan, and other system health indicators. Each server exposes different metrics depending on the brand and the model.

Key Characteristics

How to enable hardware monitoring on your server

Our monitoring system collects all the metrics via the server’s IPMI interface. For this purpose, we create a dedicated read-only IPMI user called “lswhwmon” on each server.

This user is exclusively used to collect hardware metrics for monitoring.

How to manage hardware monitoring:

1. To create the required user an IPMI reset is needed
   • The user then gets created automatically
2. To disable hardware monitoring, delete the user
   • The details of this user can be found in the remote management portal of the server and under the Credentials page of the server in the Customer Portal:

3. See the collected metrics in the Customer Portal under Usage -> Hardware Monitoring
   • The metrics are refreshed every 5 minutes:

What Are Labels for Kubernetes Node Pools?

In Kubernetes, labels are key–value pairs that you can attach to cluster resources to describe and categorise them. When applied to node pools, labels offer a straightforward and adaptable method for categorising groups of nodes based on their characteristics or intended purpose. These labels are propagated to the individual worker nodes, allowing workloads and cluster components to make scheduling or operational decisions based on them.

Label Prefix

All labels defined on a node pool are automatically prefixed by the platform to avoid conflicts with system and Kubernetes-reserved labels.

Prefix applied to all node pool labels:

label.leseweb.io/

For example, a label defined as:

environment:production

Will appear on worker nodes as:

label.leaseweb.io/environment=production

The prefix is applied automatically and cannot be changed.

Setting Labels

You can assign labels to a node pool when creating or updating it.

1. To set labels, navigate to your cluster -> go to the Node Pools tab
2. Click Edit on the node pool you want to label
3. In the Labels section, enter your key–value pairs
4. Click Update -> Confirm to apply the changes.

To view the labels for a node pool, you can expand the node pool details.

Updating or Deleting Labels

You can modify or remove labels at any time using the node pool Edit option

1. Go to the Node Pools tab -> select Edit for the desired node pool
2. In the Labels section, add new labels, modify existing ones, or remove labels as needed
3. Click Update -> Confirm to apply the changes.

Viewing Labels on a Node Using kubectl

You can view the labels applied to a specific worker node using kubectl.

Run the following command, replacing <node-name> with the name of the worker node:

kubectl get node <node-name> -o yaml

The command returns the full node definition. Labels applied through the node pool are visible under the metadata.labels section.

Example

metadata:
  labels:
    kubernetes.io/arch: amd64
    kubernetes.io/os: linux
    label.leaseweb.io/environment: staging
    label.leaseweb.io/labels: "true"
    node-role.kubernetes.io/worker: ""

In this example:

• label.leaseweb.io/environment: staging was defined on the node pool
• The label is automatically prefixed and propagated to the worker node
• All node pool labels appear alongside standard Kubernetes labels

Labels Lifecycle

Labels defined on a node pool follow a consistent lifecycle.

• New worker nodes (for example, through autoscaling) automatically receive the labels
• When a label is updated on the node pool, the change is propagated to all corresponding worker nodes
• When a label is removed from the node pool, it is automatically removed from the worker nodes
• Manual modification of node pool labels directly on individual nodes is not supported, as labels are reconciled from the node pool configuration
• When a label is removed from the node pool, it is automatically cleaned from the worker nodes