Choosing the right server is an important step when hosting Holy Unblocker. A server that is too limited may struggle with multiple users or heavy sites, while buying an expensive one before you need it wastes budget. The project's long-term development continued as InvisiProxy LTS (see Holy Unblocker vs InvisiProxy), and because it uses several components, requirements vary with the version, configuration and number of visitors.
This guide covers realistic starting specs, software dependencies, bandwidth and how to pick a hosting plan.
Estimates, not guarantees. The project documentation explains how to prepare a server but sets no universal CPU or RAM minimum. Every figure below is a practical planning estimate. Measure actual usage after installation.
1. What Are the Server Requirements?
Server requirements are the hardware and software needed to run an application reliably: processor, memory, storage, network capacity, an operating system and the right software environment. Here are practical starting points:
| Resource | Small test server | Initial public deployment |
|---|---|---|
| CPU | 1 vCPU | 2 vCPUs |
| RAM | 1–2 GB | 4 GB |
| Storage | 10–20 GB SSD | 25–40 GB SSD |
| Network | Basic connectivity | Reliable connection, sufficient transfer allowance |
| Operating system | Supported Linux distribution | Ubuntu LTS or another compatible Linux |
| HTTPS | Optional for local testing | Strongly recommended |
A small test server may be enough to explore the project or serve very few users. A public instance generally benefits from more memory, CPU and bandwidth, and busy instances may need more still.
2. How Much RAM Does It Need?
Holy Unblocker uses a Node.js-based environment and may run several proxy-related components. Memory use depends on the version, enabled features, active sessions, caching and traffic.
- 1 GB: may suit limited experiments if your version fits. The OS, package installs and background services also use memory. There is little room to grow, so it isn't dependable for a busy public proxy.
- 2 GB: a reasonable start for testing or a small deployment. Watch memory under simultaneous sessions, and upgrade if the server leans on swap or kills processes.
- 4 GB: more room for the app, supporting services and moderate growth. A sensible first target for a small public instance, though not a guarantee for any visitor count.
- 8 GB or more: extra headroom for larger workloads, but RAM alone won't fix CPU limits, network throughput, upstream site restrictions or configuration problems.
Tip: check real memory usage before upgrading. Monitoring a real workload beats guessing from visitor counts.
3. What CPU Does It Need?
The CPU runs the JavaScript-based services and manages concurrent connections. One vCPU is fine for basic testing, two give a small public deployment more capacity, and busier instances may want four or more. The right amount depends on:
- Concurrent users: more simultaneous activity raises demand.
- Proxy engines and transports: they can differ in CPU cost (see how Holy Unblocker works).
- Caching and background tasks: extra services compete for processor time.
- Heavy websites: complex pages with many requests add load.
- Configuration: poorly configured services can waste CPU (see how to configure Holy Unblocker).
If CPU stays high during normal use, find the cause before buying a bigger plan. Excessive requests, inefficient configuration and heavy sessions can all contribute.
4. How Much Storage Is Required?
Storage holds the application files, dependencies, configuration, logs and caches. An SSD gives responsive access to files and packages. For planning, 10–20 GB may do for a basic test environment and 25–40 GB gives a small public deployment more room. These are suggested allocations, not official minimums, and the real amount depends on the release, dependencies, logs and extra software.
Check whether your provider lets you expand storage later, and set a retention policy for logs. Don't delete application files or caches blindly, as some components depend on them.
5. Which Operating System Is Best?
A Linux server is a practical choice because it supports the tools web apps commonly use. Ubuntu LTS is beginner-friendly with extensive documentation, and other distributions may work if they support the required runtime. When choosing, consider:
- Availability of the required Node.js version
- Compatibility with your selected release
- Access to Git and the right package manager
- Support for a reverse proxy such as Nginx
- Security updates and long-term maintenance
- Your comfort with the command line
Compatibility with the exact version you deploy matters most. Check the official repository instructions rather than assuming every release uses the same runtime or commands.
6. Required Software and Dependencies
Hardware alone isn't enough. The current InvisiProxy repository documents several important dependencies:
- Node.js: the JavaScript runtime. The required version can differ between revisions, so follow the instructions for your branch.
- Git: to fetch the source and manage updates or branch switches.
- Package manager: recent documentation uses pnpm, while older versions may use npm. Use the one and the lockfile that match your release, and don't mix commands from unrelated versions.
- Nginx: can act as a reverse proxy for production. The repository warns that some configurations cause problems with WebSocket-like communication or loopback connections, so follow its current deployment guidance.
- HTTPS and a domain: a public deployment should normally have both, plus DNS records and firewall rules for the services you expose. HTTPS encrypts the visitor's connection but doesn't make a proxy anonymous or guarantee every site will work.
The full setup steps are in How to Self-Host Holy Unblocker.
7. How Much Bandwidth Does It Need?
Bandwidth is the data transferred between the server and other devices. For a web proxy it matters a lot, because the server relays everything visitors request. A page with many images, scripts or videos transfers far more than a simple text page. Your needs depend on:
- The number of active visitors and how long each stays
- The type and size of content requested, especially video
- Your provider's monthly transfer allowance
- Any throughput or fair-use limits the provider imposes
For example, if the service moves 100 GB a month, a plan with a 100 GB allowance leaves no room for extra traffic. Allow a margin, and check how the provider counts inbound and outbound data. Don't estimate from visitor counts alone. Measure real traffic and review usage reports before upgrading.
8. Can You Use Shared Hosting?
Traditional shared hosting is built for platforms such as WordPress, and it may not allow long-running Node.js processes, custom network services or the configuration a proxy needs. Before buying, confirm the provider allows:
- Long-running Node.js applications and persistent processes
- Installing the required dependencies
- Reverse-proxy configuration where needed
- The traffic your intended use creates, under its acceptable-use policy
A host may support Node.js yet still prohibit public proxy services, so read its terms first. A compatible VPS is usually a better start because it gives you control over the OS, processes and configuration.
9. VPS, Cloud or Dedicated?
- VPS: a defined allocation of CPU, RAM, storage and network, with control over the OS and predictable pricing. A straightforward choice for learning to run your own server.
- Cloud application hosting: simplifies deployment, but support for persistent processes, custom networking, WebSockets and proxy workloads varies. A platform that suits a normal website may not support every component here.
- Dedicated server: suits a larger service with sustained demand, and is usually unnecessary for an initial deployment.
Choose on compatibility, resource limits, network policy and total cost rather than the category alone.
10. Recommended Specs by Use Case
These are budgeting starting points, not official minimums or concurrent-user promises.
| Use case | Suggested starting allocation |
|---|---|
| Learning and local testing | 1–2 vCPUs, 2 GB RAM, 20 GB SSD |
| Small public deployment | 2 vCPUs, 4 GB RAM, 25–40 GB SSD |
| Growing traffic | 2–4 vCPUs, 4–8 GB RAM, 40 GB+ SSD |
| Higher or sustained traffic | Benchmark first, then scale CPU, RAM and bandwidth to measured demand |
A larger server isn't always the best first purchase. Start with a plan that supports your software and expected workload, then monitor it. If you expect high traffic, test carefully and confirm your provider permits the use before going public.
11. Is Your Server Powerful Enough?
After deployment, use these common Linux commands for a snapshot of resources:
free -h # memory usage df -h # disk space top # CPU and running processes cat /etc/os-release # operating system
For a real picture, monitor over time, especially during busy periods. Warning signs include:
- Memory approaching the limit, or processes repeatedly restarting
- CPU staying heavily occupied
- Disk filling up from logs or caches
- Slow responses at busy times
- Network transfer nearing your plan's limit
Identify the cause before changing anything. An application error or network bottleneck needs a different fix from a hardware upgrade. If something is broken rather than slow, see common problems and fixes.
12. Security for a Public Server
- Keep the system updated with OS security updates and supported dependencies.
- Protect the server: strong admin credentials, restricted ports, and no direct internet exposure for internal services.
- Configure HTTPS correctly and renew certificates on time.
- Monitor resource use, without retaining sensitive information unnecessarily.
- Control abuse: public proxies attract automated and excessive traffic, so consider access controls, rate limits and abuse monitoring.
- Back up configuration so you can recover from failed updates.
- Review provider policies to be sure the service and its traffic are allowed.
Running a proxy doesn't guarantee anonymity or privacy. Your server may handle requests and metadata, and its security depends on how you configure and maintain it (see our disclaimer). For how a proxy differs from a VPN, read Holy Unblocker vs VPN.
13. Common Mistakes
- Buying on price alone. A cheap plan may lack memory, bandwidth or required capabilities.
- Assuming a universal minimum. Requirements depend on version, features and workload.
- Ignoring software compatibility. The wrong runtime or package manager causes install failures.
- Skipping provider policies. Some hosts restrict proxies or custom network services.
- Underestimating bandwidth. Relaying large content burns through allowances quickly.
- Exposing internal ports. Only expose what needs to be public.
- Upgrading without measuring. Find out whether CPU, RAM, storage or network is the bottleneck.
Frequently Asked Questions
What are the minimum server requirements?
No single officially established CPU and RAM minimum guarantees every deployment will work. For planning, consider 1–2 vCPUs and 2 GB RAM for testing, then verify compatibility and resource use with your chosen release.
Is 2 GB RAM enough?
It may be for testing or a small deployment, depending on the OS, dependencies and workload. A 4 GB server gives a small public instance more headroom, but measure performance either way.
How much RAM for a public server?
A 4 GB VPS is a reasonable starting point to evaluate. Higher traffic or more demanding configurations may need more.
Does it require Node.js?
The InvisiProxy LTS codebase uses a Node.js environment. Check the documentation for your exact release for the supported version and install method.
Can I run it on a Windows server?
It depends on the release and its dependencies. Linux is a practical choice for many self-hosted deployments because the project documentation provides Linux-oriented setup instructions.
Is shared hosting suitable?
Often not, since it may restrict long-running processes or custom network services. A VPS is usually more flexible, provided the host permits proxy workloads.
Do I need a domain name?
Not for local testing, but you'll want one for a public deployment, along with HTTPS and correct DNS before opening it to visitors.
How much bandwidth does it use?
It depends on visitor activity and content. Media-heavy browsing uses far more than simple pages. Measure actual transfer and compare it with your provider's monthly allowance.
Can I upgrade my server later?
Yes, if your provider supports upgrading the VPS. Monitor CPU, RAM, storage and network use to decide when more is needed.
Where are the official setup instructions?
In the current InvisiProxy repository and its release-specific documentation. Holy Unblocker LTS is the former name of this project's development lineage.
Conclusion
Choosing a server means balancing hardware, software compatibility, bandwidth, security and cost. A modest VPS is a useful starting point for testing, and a small public deployment may do well with around 2 vCPUs and 4 GB RAM. Those are planning estimates, not official minimums. Start with a compatible server, follow the current documentation, monitor resource use and upgrade when measurements show you need more.