Nginx has a reputation for being easy to start and easy to misconfigure. A fresh install serves a welcome page within a minute, and the next hour decides whether the server stays quick and safe or turns into a collection of copied snippets that nobody understands. Nginx is light, so even a small virtual server can carry a surprising amount of traffic as long as the application behind it does not eat the memory. The question at the start is therefore less about the web server than about the operating system image and the access rules. The VPS from DotRoll comes as a KVM virtual machine with root access at any hour, offered in sizes from 512 MB of RAM and one vCPU up to 8 GB and six vCPUs, with 1 to 6 TB of included bandwidth depending on the package. The plans include swap space, which gives a small machine some headroom but should not be mistaken for memory. The FAQ on that page lists several Linux distributions, and some of the releases it names are old, so check the current support status of the chosen release before installing anything and prefer the newest long-term version the provider offers. The official beginner's guide describes the process model in a few sentences. Nginx runs one master process and several worker processes, the master reads the configuration and manages the workers, and the workers handle requests using an event-based model. The number of workers is set by the worker_processes directive and can be adjusted automatically to the number of CPU cores. The configuration file is called nginx.conf and normally lives in /etc/nginx or a similar directory. Day-to-day control happens through signals. The command nginx -s reload applies a changed configuration without dropping connections, and nginx -s quit finishes current requests before stopping. Experienced administrators run nginx -t first, which checks the syntax of the configuration and reports the line of any error, so a typo never reaches the live server. Within the file, a server block decides which virtual host handles a request, and location blocks inside it decide how each path is served, either as static files from a root directory or as a proxied request to an application. Most performance gains come from a short list of settings. Setting worker_processes to auto matches the workers to the cores, and worker_connections limits how many connections each worker accepts, which on a small machine is bounded by the operating system's open file limit as much as by nginx itself. Enabling keepalive connections to clients and to upstream servers saves repeated handshakes, and compression of text responses reduces transfer size at a small cost in CPU. Caching headers for static files do more for repeat visitors than any server setting, because a file the browser already holds costs nothing to deliver. Nginx can also cache responses from an application server for short periods, which protects a slow backend during traffic peaks. On a 512 MB or 1 GB machine the limiting resource is usually the application, not nginx. PHP-FPM pools, Node processes and database buffers are what exhaust memory, so size them first and leave room for the operating system. Measure before changing anything, change one setting at a time and keep the previous file so that a rollback takes seconds. A useful habit is to load test with a tool such as ab or wrk from a second machine before and after a change, since a setting that sounds sensible can lower throughput on a particular workload. Start outside nginx. A firewall that admits only SSH, HTTP and HTTPS, SSH keys in place of passwords, a regular user with sudo instead of daily root logins and automatic security updates remove the most common ways in. Fail2ban or a similar tool slows down password guessing against any service that remains open. Inside nginx, redirect plain HTTP to HTTPS and obtain a free certificate from Let's Encrypt with an automated client, so renewal never depends on memory. Turning off server_tokens hides the version number from error pages, rate limiting through limit_req slows abusive clients, and denying access to hidden files such as .git and .env closes a favorite target of scanners. When the application runs on the same machine, bind it to localhost and let nginx act as the only public entry point. Keep default catch-all server blocks that return an error for unknown host names, so that bots scanning IP addresses do not reach the real site. Nginx writes an access log and an error log, usually under /var/log/nginx, and both pay off the first time something misbehaves. The error log explains failed upstream connections and permission problems, and the access log shows status codes, response times and unusual clients when a custom log format includes them. Make sure log rotation is active, because a full disk is among the more embarrassing causes of an outage. Add an external uptime check that tests the real page, a reminder for certificate expiry and a monthly routine of package updates, a configuration test and a restore check of the backup. Store a copy of /etc/nginx and the certificates off the server. A machine that can be rebuilt from notes and a backup in an hour is a machine that can be run calmly. Review the error log weekly for the first month after any change, because new configuration mistakes usually announce themselves in repeating lines before users notice.
Running Nginx on a VPS: Setup, Tuning and Security Basics
Starting with the right machine
How nginx is organized
Tuning that matters on a small server
Security basics
Logs, monitoring and upkeep