E1 Series Nodes
Use this page to manage E1-series nodes after launch.
E1-series nodes are cost-focused compute nodes with custom root storage. They behave like regular nodes for common lifecycle actions, monitoring, security groups, backups, snapshots, and saved images, but they also have E1-specific behavior for root storage, public IP assignment, Stop, and plan changes.
For the full launch flow, see Create a node. For choosing between node families, see Choose a node family.
E1-series behavior applies to Linux E1 nodes and Windows E1 nodes where the selected image and plan support it. The portal shows only the actions that are valid for the selected node, state, project, region, and billing configuration.
For post-launch E1 management, open Compute > Nodes, select the E1 node, then use the node details tabs or the node action menu. The operational flows below assume you have already selected the E1 node.
What Is Different for E1
E1-series nodes differ from other node families in these management areas:
| Area | E1 behavior |
|---|---|
| Root storage | Root storage is selected separately from the compute plan during launch. It can be increased later where supported. |
| Public IP | E1 nodes do not include a default primary public IPv4 address. You can attach a primary public IP where supported, then attach Add-on IPs if extra public addresses are needed. |
| Stop | Stop pauses compute billing while the node remains Stopped. Storage and attached add-ons continue to bill. |
| Power Off | Power Off keeps the node allocated and normal node billing continues. |
| Plan changes | E1 plans use Update Node Plan where available. The node must be in a supported state before the plan can be changed. |
| Images and snapshots | E1 supports image and snapshot workflows where the selected image, state, and system validation allow them. |
Create an E1 Node
During node creation, select an E1 or E1 Windows plan from the plan family list. After you select the plan, the create-node flow asks for root storage separately.
Review these points before launch:
- E1 nodes do not include a default public IPv4 address.
- Select the root storage size before launching the node.
- Root storage has its own monthly charge per GB.
- The selected root storage affects the IOPS value shown in the launch flow.
- SSH keys, security groups, VPC, backup, public IP, volumes, labels, and advanced settings still follow the normal create-node flow.
If you create an E1 node from a saved image, the minimum selectable root storage can depend on the saved image size. The portal validates the available sizes before launch.
Root Storage
E1-series root storage is separate from the compute plan. The root disk is selected in the E1 Root Storage section during launch and can be increased later from the node details page.
Current root storage rules:
| Rule | Value |
|---|---|
| Minimum root storage | 75 GB |
| Default root storage | 150 GB |
| Maximum root storage | 2400 GB |
| Size steps below 150 GB | 25 GB increments |
| Size steps from 150 GB and above | 50 GB increments |
Root storage cannot be reduced after launch. If you need a smaller root disk, create a new node with the required size and migrate the workload.
IOPS
The portal displays read/write IOPS while you select E1 root storage.
The default E1 root storage IOPS baseline is:
| Root storage | Read IOPS | Write IOPS |
|---|---|---|
| 150 GB | 15000 | 10000 |
For root storage above 150 GB, IOPS increase with the selected size. Each additional GB above 150 GB adds 5 read IOPS and 5 write IOPS to the baseline.
Examples:
| Root storage | Read IOPS | Write IOPS |
|---|---|---|
| 200 GB | 15250 | 10250 |
| 250 GB | 15500 | 10500 |
| 300 GB | 15750 | 10750 |
The portal is the source of truth for the final root storage price and IOPS shown before launch or upgrade.
Increase Root Storage
Use Increase Root Storage from the node details page when an E1 node needs a larger root disk.
To increase root storage:
- Open the node action menu.
- Select Increase Root Storage.
- Choose a larger allowed root storage size.
- Review the estimated monthly cost difference and IOPS.
- Confirm the upgrade.
After confirmation, the node enters an upgrade flow. Wait for the node status to settle before starting another lifecycle or storage action.
Requirements
Root storage increase is available only when system validation allows it.
Common requirements include:
- The node must be an E1-series node.
- The node must be Running or Powered off.
- The new size must be greater than the current root storage size.
- The new size must be within the allowed E1 root storage range.
- The node must not be locked.
- The node must not be in rescue mode.
- The node must not be part of a Disaster Recovery plan.
- The root disk must not have active snapshots.
- The node must not already be in a disk resize or upgrade operation.
- The node must have enough free disk space for the upgrade check.
If the root disk has active snapshots, delete the snapshots first and retry the root storage upgrade only after snapshot deletion is complete.
Stop and Power Off
E1 nodes support both Power Off and Stop, but they are not the same action.
| Action | What happens | Billing behavior | Typical use |
|---|---|---|---|
| Power Off | The node shuts down but remains allocated. | Normal node billing continues. | Short maintenance windows, safe shutdowns, or actions that require Powered off state. |
| Stop | The node is deallocated into Stopped state. | Compute billing pauses; storage and attached add-ons continue billing. | Longer idle periods when you want to pause compute charges. |
Starting a Stopped E1 node can take longer than starting a Powered off node because the node must be allocated again.
If the node is running disk-intensive workloads, shut down the operating system cleanly before using Stop. Stopping an active system can risk data loss or data corruption.
While an E1 node is Stopped, most node actions are unavailable. Start the node before performing management actions such as plan changes, storage changes, snapshots, saved images, network changes, or security updates.
Update Node Plan
Use Update Node Plan to change the compute plan for an eligible E1 node.
Plan updates are useful when you need to change CPU or memory capacity without rebuilding the node.
Before updating the plan:
- Power off the node if the portal requires it.
- Check that the node is not locked.
- Confirm the node is eligible for E1 plan changes.
- Review the target plan price and billing impact.
- Wait for any current lifecycle, storage, backup, snapshot, or image operation to finish.
The portal lists compatible target plans and disables invalid options. If no plan is shown, the selected E1 node is not currently eligible for a plan update.
For the full checklist, see Action Availability.
Networking
E1 nodes do not include a default public IPv4 address.
Use one of these access patterns:
| Access pattern | Use it when |
|---|---|
| Primary public IP | You need direct internet-facing access to the node. |
| Add-on IP | The node already has a primary public IP and needs an additional public address. |
| Private IP inside a VPC | You access the node from other resources in the same private network. |
| Bastion or VPN path | You want private access without exposing the node directly to the internet. |
If you attach a public IP later, update security groups and operating system firewall rules before exposing application ports.
Do not open SSH, RDP, database, or application ports to the public internet unless the workload requires it and the source ranges are restricted.
Images and Snapshots
E1 nodes can participate in saved-image and snapshot workflows where supported.
Use saved images when you want to create future nodes from the same configured system state. Use snapshots when you need point-in-time copies of node storage.
Important E1 considerations:
- Root storage size matters when launching from a saved image.
- A saved image can require a minimum root storage size based on the source image.
- Active snapshots can block root storage increase.
- Image and snapshot actions depend on node state and snapshot support.
For the manage-level guides, see Node Images and Node Snapshots.
Backups, Monitoring, and Security
E1 nodes use the same node management areas as other node families:
| Area | What to check |
|---|---|
| Backups | Confirm whether CDP Backup is enabled and review backup status before risky changes. |
| Monitoring | Review CPU, memory, disk, network, and alerts before resizing or troubleshooting. |
| Security groups | Keep access rules limited to required ports and trusted source ranges. |
| Audit logs | Review lifecycle, billing, and configuration changes for operational history. |
| Labels | Use labels to organize E1 nodes by workload, owner, environment, or cost center. |
Storage and attached add-ons continue billing while an E1 node is Stopped. Review attached resources before leaving a node stopped for a long period.
Related Resources
| Resource | Use it for |
|---|---|
| Manage Nodes | Understand the full post-launch node management surface. |
| Create a node | Launch a new E1 or other CPU node. |
| Choose a node family | Compare E1 with other node families before launch. |
| Node Images | Understand how saved images interact with E1 nodes. |
| Node Snapshots | Understand how snapshots interact with E1 nodes. |
| Action Availability | Check why E1 actions are hidden, disabled, or rejected. |
| Node Encryption | Understand creation-time encryption behavior for nodes. |