Mastering CloudLinux: Create Custom LVE Profiles for Heavy Staging vs. Production Environments

Running several web applications on a single server often feels like a juggling act, especially when a resource‑hungry staging environment threatens to steal CPU, RAM, or I/O from live production sites. CloudLinux’s Lightweight Virtual Environment (LVE) solves this problem by letting you set granular resource limits per user, per site, or per container. In this guide we’ll walk through the entire process of creating custom LVE profiles that give your staging environment the breathing room it needs without jeopardising production stability.

Why Use Separate LVE Profiles for Staging and Production?

Staging servers typically run heavy build tools, automated tests, and debugging utilities that can cause sudden spikes in CPU usage or flood the disk with temporary files. Without isolation, these spikes can:

• Degrade performance for live customers.
• Trigger unexpected downtime by exhausting memory or I/O limits.
• Complicate troubleshooting because it’s hard to tell whether a slowdown originates from staging or production.

Distinct LVE profiles let you:

1. Guarantee a minimum resource floor for production sites.
2. Allow staging to consume more resources temporarily, but never exceed a predefined ceiling.
3. Monitor usage per profile and adjust limits proactively.

Prerequisites and Initial Setup

1. Verify CloudLinux Installation and Update Packages

Make sure CloudLinux is the active OS and that cagefs and lve-utils are up to date:

yum update -y
yum install -y cagefs lve-utils

Restart the LVE manager to apply any updates:

systemctl restart lve-svcs

2. Identify Users and Groups

Decide which Linux users will run staging versus production. A common pattern is:

• prod_user1, prod_user2 – live sites.
• stage_user1, stage_user2 – staging environments.

Ensure each user has its own home directory and that the web server (Apache, Nginx, etc.) runs under the appropriate user context (via mod_ruid2, php-fpm pools, etc.).

Creating Custom LVE Profiles

1. Define Baseline Limits

Start with the default profile values as a reference:

lveinfo -c

Typical defaults look like:

• CPU: 100 % (full core)
• I/O: 1024 MB/s
• Memory: 2 GB
• Processes: 100
• Entrypoints (e.g., Apache workers): 30

For production you’ll usually want tighter caps, while staging can be more generous—but still bounded.

2. Create a Production Profile

Use lve-set to craft a profile named prod_profile:

lve-set --name prod_profile \
        --cpu 80 \
        --mem 1536M \
        --io 800 \
        --proc 80 \
        --entrypoints 25

This limits each production user to 80 % of a CPU core, 1.5 GB of RAM, 800 MB/s I/O, and a maximum of 80 processes.

3. Create a Staging Profile

Staging often needs bursts of CPU and memory for builds. Give it a higher ceiling while still protecting the host:

lve-set --name staging_profile \
        --cpu 120 \
        --mem 3072M \
        --io 1200 \
        --proc 120 \
        --entrypoints 40

Note that the cpu value can exceed 100 % because CloudLinux allows “burst” usage up to the defined limit, provided the host has idle cores.

4. Assign Profiles to Users

Map each Linux user to the appropriate profile:

# Production users
lve-set-user prod_user1 prod_profile
lve-set-user prod_user2 prod_profile

# Staging users
lve-set-user stage_user1 staging_profile
lve-set-user stage_user2 staging_profile

Verify the assignments:

lveinfo -u prod_user1
lveinfo -u stage_user1

Fine‑Tuning and Monitoring

1. Real‑Time Monitoring

CloudLinux includes lve-stat and a cPanel/WHM LVE Manager plugin. For CLI fans, run:

lve-stat -p prod_user1 -t 60

This displays CPU, memory, and I/O usage per second for the last minute. You can also schedule a cron job to log these stats to /var/log/lve_usage.log for trend analysis.

2. Adjust Limits Based on Data

If staging consistently hits its CPU ceiling, raise the cpu value by 10 % and retest. Conversely, if production users stay well below their caps, tighten the limits to free resources for other tenants.

After any change, reload the LVE manager:

systemctl restart lve-svcs

3. Protect Against Abuse

Even with profiles, a rogue script could spawn many processes. Enable the “process limit” alarm in /etc/lve/lve.conf:

PROC_LIMIT=80
PROC_LIMIT_EXCEEDED_ACTION=kill

CloudLinux will automatically terminate excess processes, preventing a single user from exhausting the system.

Best Practices and Common Pitfalls

• Document every profile. Keep a version‑controlled file (e.g., lve_profiles.sh) that records the exact lve-set commands used. This makes disaster recovery trivial.
• Separate filesystem mounts. Use cagefs or bind mounts to isolate /tmp and /var/tmp for staging, preventing large temporary files from filling the same partition as production.
• Test after each change. Run a synthetic load test (e.g., ab or wrk) against both environments to confirm the new limits behave as expected.
• Beware of over‑committing CPU. Setting many users to >100 % CPU can lead to contention on busy hosts. Balance burst capacity with the number of cores.
• Monitor I/O latency. High I/O limits don’t guarantee low latency; use iostat or CloudLinux’s I/O throttling graphs to spot bottlenecks.

Conclusion

Custom LVE profiles give you the precision needed to run resource‑intensive staging workloads alongside mission‑critical production sites on a single CloudLinux server. By defining clear limits, assigning them to the right users, and continuously monitoring usage, you protect live customers while still providing developers the sandbox they need to test new features.

Remember: start with conservative limits, gather real‑world data, and iterate. Following the steps above will give you a robust, automated way to keep both environments happy—ensuring smooth releases and a seamless experience for your end users.