How LYLIX bills resources and what changes happen at the next reboot

LYLIX VPS plans are simple: a base price per product type, plus configurable options for CPU, RAM, and disk. Some changes apply live; others wait until the next reboot. This article walks through how billing works for plan changes, what's prorated and what isn't, and which changes actually take effect for your guest OS at what point.

How plan pricing works

Every VPS has:

• A base price set on the product itself. Linux VPS = $10/month; PBX VPS = $20/month.
• Three configurable options:
  • CPU cores
  • RAM
  • Disk
  Each level above the baseline adds a fixed monthly cost. See the order form for the current per-level rates.

Your total monthly is: base + sum of configurable-option increments.

What happens when you change resources

The cart's upgrade flow handles the billing automatically:

1. You pick new values for CPU / RAM / Disk.
2. The billing system calculates the prorated charge or credit for the rest of the current billing cycle.
3. You confirm and (for upgrades) pay the prorated amount immediately.
4. The new monthly total takes effect at your next renewal.

For mid-cycle upgrades, the prorated invoice is the difference between the old and new monthly rate, scaled by the remaining days in the cycle.

Prorated charges — quick example

You're 10 days into a 30-day billing cycle on a $20/month VPS. You upgrade to a $30/month config:

• Old daily rate: $20 / 30 = $0.67/day
• New daily rate: $30 / 30 = $1.00/day
• Days remaining: 20
• Old credit: 20 × $0.67 = $13.33
• New charge: 20 × $1.00 = $20.00
• Net charge today: $20.00 − $13.33 = $6.67

Next month's invoice is the full new rate ($30) for a fresh cycle.

Downgrades

Downgrades generate a credit, not a refund. The credit applies to your next invoice automatically. If your account balance goes positive (credit exceeds the next invoice), the credit carries forward until consumed.

If you want an actual refund rather than account credit, open a billing ticket — handled case-by-case.

Which changes apply live vs. require a reboot

Change	Hypervisor side	Guest OS sees it
CPU cores ↑ or ↓	Applied immediately (hot-config)	After next reboot (most kernels)
RAM ↑ or ↓	Applied immediately (hot-config)	After next reboot (most kernels)
Disk ↑ (grow only)	Applied immediately	After next reboot, plus filesystem resize
Disk ↓ (shrink)	Not supported on VM-based VPSes	—
Network rate limit	Applied immediately	Live; no reboot needed

Why CPU/RAM changes need a reboot

The hypervisor adds (or removes) the resources from the VM immediately. But Linux kernels enumerate CPU and memory at boot time; hot-plug support exists but is inconsistent across distros and kernel versions. The reliable behavior is "see the new resources after reboot."

On a VM-based VPS (most LYLIX products), when you change CPU or RAM the portal shows a banner reminding you to reboot when convenient. The customer chooses the moment — a reboot might be disruptive at the wrong time, so LYLIX doesn't auto-reboot you. The banner clears as soon as you reboot.

On a container-based VPS (legacy product line — most older accounts), container-style virtualization handles resource changes live for all three resources (CPU, RAM, disk) without a reboot. No banner; changes are immediate.

Why disk growth needs a filesystem resize

The hypervisor grows the underlying disk image. Inside the VM, the guest OS sees a bigger block device but the filesystem inside is still the old size. After reboot:

# For ext4:
resize2fs /dev/vda1

# For xfs:
xfs_growfs /

# For btrfs:
btrfs filesystem resize max /

If the disk is partitioned, you'll also need to grow the partition first with growpart (or parted). Cloud-init images often handle this automatically on first boot after a disk resize; if not, do it manually.

Why disk shrink isn't supported

Shrinking a virtual disk requires shrinking the filesystem first (offline, single-user mode), then shrinking the partition, then shrinking the underlying image. Each step has failure modes that can lose data. VM-based VPSes don't support online disk shrink at all, and offline shrink is error-prone enough that LYLIX doesn't expose it as a self-service operation.

The portal blocks shrink at the cart UI (you can't select a smaller disk option than your current allocation) AND the server- side module rejects shrink attempts as a safety net. The only way to "shrink" a disk is to:

1. Order a smaller VPS as a new service.
2. Migrate data from the old to the new.
3. Cancel the old when migration is done.

The renewal cycle

The billing system generates the renewal invoice 14 days before your service's due date. Monthly cycle = renewal invoice 14 days before each month. Annual cycle = renewal invoice 14 days before annual due date.

Auto-pay (if you have a card on file) charges the renewal on the due date. Manual-pay invoices wait for you to log in and pay.

If a renewal invoice isn't paid within ~7 days of the due date, the service goes through:

• Day 0-7 past due: reminders sent. Service still running.
• Day ~7+: service suspended (powered off; data intact).
• Day ~30+: service terminated (data may be deleted; we don't guarantee retention past this).

Easiest avoidance: card on file + auto-pay on. Set under Account → Credit Card.

Manual rebooting after a CPU/RAM change

From the customer portal:

1. Open your service.
2. Action buttons row at the top: click Reboot VM.
3. Confirm.

The reboot takes ~30 seconds typically. After it completes, the banner reminding you about the pending change disappears, and your guest OS sees the new CPU/RAM allocation.

You can verify from inside the VM:

# See current CPU count:
nproc

# See current memory:
free -h

# Or for the full picture:
lscpu
cat /proc/meminfo

If anything looks wrong on the invoice

Open a billing ticket. Common questions:

• I upgraded mid-cycle and the charge looks high — the prorated math accounts for both the credit and the new full-month charge starting at renewal; check the next invoice rather than just the immediate one.
• I downgraded and didn't see a refund — it applied as account credit; check your account balance and the next invoice.
• I see a one-time charge I don't recognize — might be a setup fee, an additional IP, or a manual adjustment. Ticket us with the invoice number and we'll explain.

Billing should never be confusing — if it is, we want to know.