Fair Usage Policy

At VisiHost, our shared container environments (Pterodactyl bot containers, game servers, and managed Lavalink instances) are hosted on high-density multi-tenant nodes powered by enterprise AMD EPYC and Ryzen processors.

This Fair Usage Policy ("FUP") ensures that every customer receives consistent, low-latency performance without any single tenant overconsuming shared hardware and degrading the experience of others on the same host node.

1. CPU & Compute Resources#

Shared containers are engineered for burstable compute workloads. This allows your bot, game server, or application to utilize maximum compute power during resource-heavy moments, such as container startup, Java compilation, chunk loading, or sudden user traffic spikes.

Permitted vs. Prohibited CPU Behavior#

• Burstable Utilization (Permitted): You may utilize up to 100% of your allocated CPU allocation during initial boots, script recompilation, temporary traffic spikes, or player joins.
• Sustained Continuous Saturation (Unfair Usage): Keeping a shared CPU core pinned at 95%–100% continuous utilization for extended periods (exceeding 2 to 4 continuous hours) negatively impacts neighboring containers. In such cases, our automated hypervisor may throttle CPU scheduler priority to preserve node health.
• Prohibited Workloads:
  • Cryptocurrency mining of any kind (e.g., Monero, Bitcoin).
  • Distributed grid computing or volunteer computing clients (e.g., Folding@home).
  • High-intensity hash cracking or password-cracking scripts.
  • Stresser or booter software execution.

2. Memory (RAM) Allocation & OOM Management#

Each hosting plan is provisioned with a strict physical RAM allocation backed by dedicated memory cgroups:

1. Hard Memory Ceilings: Containers cannot allocate memory beyond the purchased plan threshold.
2. Linux OOM Killer: If an application (such as a Node.js process with a memory leak or a Minecraft server with an oversized heap) exceeds its RAM quota, the Linux kernel's Out-Of-Memory (OOM) killer will immediately terminate the process with exit code 137.
3. No Swap Thrashing: To maintain NVMe storage performance across the entire node, swap memory is tightly controlled and not designed as a substitute for adequate RAM.
4. Optimizing Memory: We encourage customers to profile memory consumption, avoid unnecessary message caching in Discord bots, and configure Java heap parameters (-Xmx and -Xms) accurately.

3. NVMe Storage & Disk I/O#

VisiHost deploys enterprise-grade Gen4 NVMe SSDs in redundant RAID arrays to ensure sub-millisecond file read and write operations.

• Intended Use: Storage space must be used solely for files, libraries, configuration scripts, logs, and database records necessary to execute your hosted application.
• Prohibited Storage Use:
  • Using containers as general personal cloud storage or external file backup vaults.
  • Operating BitTorrent seedboxes, public file mirrors, or large video file distribution hubs.
  • Continuous, unbuffered disk write loops (such as runaway debug logging writing gigabytes of text per hour) that prematurely exhaust SSD flash endurance.
• Log Management: Applications generating excessive log files should implement log rotation or log-level throttling to prevent disk exhaustion.

4. Bandwidth & Network Throughput#

All unmetered bandwidth plans operate under a fair-share networking model:

• Shared Network Port: Host nodes feature 1 Gbps to 10 Gbps redundant network interfaces shared dynamically among resident services.
• Fair-Share Consumption: Standard game server traffic, Discord API communication, voice packets, and web queries are welcomed.
• Prohibited Network Workloads:
  • Operating unauthenticated public proxies, Tor exit nodes, or open VPN relays.
  • Hosting high-bandwidth video or music streaming redistribution proxies.
  • Launching network floods, packet reflection attacks, or automated port scanning.
• Mitigation: Sustained, multi-hour port saturation that endangers node network stability will trigger automated rate-limiting while our team contacts you.

5. Workload-Specific Guidelines#

A. Discord & Telegram Bots#

• Configure appropriate cache sweeps: Discord.js bots should disable caching for messages and members if they are not actively required.
• Do not run continuous heavy image rendering or video transcode pipelines on low-tier shared bot containers.

B. Lavalink Audio Nodes#

• Audio encoding and decoding are CPU-intensive. Keep simultaneous audio streams within the capacity of your purchased plan to prevent audio stutter and node degradation.
• Self-managed Lavalink nodes must utilize proper buffer configurations to prevent CPU spikes.

C. Minecraft Servers#

• World pre-generation must be throttled to prevent CPU lockups.
• Avoid unoptimized mob farms or massive redstone loops that drop server tick rate (TPS) below 10 for prolonged periods.

6. Multi-Stage Enforcement Process#

When a container exceeds fair usage boundaries, VisiHost follows a structured, constructive enforcement sequence wherever security permits:

[Level 1: Automated Protection] ➔ [Level 2: Support Ticket & Advisory] ➔ [Level 3: Upgrade Recommendation] ➔ [Level 4: Temporary Restriction]

1. Level 1 — Automated Protection: The container may have its CPU scheduler priority dynamically throttled, or the container process may be restarted if it is causing host instability.
2. Level 2 — Support Advisory Ticket: Our support team opens a ticket in your account detailing the resource bottleneck, providing diagnostic advice, and outlining remediation steps.
3. Level 3 — Upgrade Assistance: If your application has naturally outgrown shared hosting limits, we assist you in migrating smoothly to a dedicated compute container or Cloud VPS.
4. Level 4 — Temporary Restriction: If an advisory is ignored or if the workload continues to degrade node stability, the service may be temporarily stopped until you work with our team to resolve the issue.

Immediate suspension without notice is reserved strictly for malicious behavior, active attacks, cryptomining, or intentional circumvention of system limits.

7. Frequently Asked Questions (FAQ)#

What does burstable CPU mean for my bot or server?#

Burstable CPU means your container can temporarily utilize 100% of an allocated CPU core during heavy spikes—such as when compiling packages, loading game chunks, or restarting your bot. As long as this spike is temporary and settles down, it is completely permitted.

Why was my container terminated with exit code 137?#

Exit code 137 means your process exceeded the RAM limit allocated to your plan, and the Linux kernel Out-Of-Memory (OOM) killer stopped the process to prevent crashing the host server. Review our Crash Troubleshooting Guide to diagnose memory leaks or upgrade your plan.

Can I host a general file download mirror or video storage site?#

No. High-speed NVMe storage on shared containers is strictly reserved for the files, configurations, and databases necessary to run your application. Using containers purely as public download mirrors or media repositories violates this Fair Usage Policy.

How will I know if my container is using too many resources?#

Our automated system will first apply temporary compute throttling if necessary to preserve host stability, and our support team will open an advisory ticket explaining the spike and suggesting optimization steps.

8. Appeals & Questions#

If you believe an automated resource restriction was applied in error or if you have questions regarding your application's resource footprint:

• Client Area Ticket: https://billing.visihost.in
• Discord Help Channel: https://discord.gg/sYbJEyXgW4
• Email Contact: support@visihost.in