Secure VPS hosting for custom web applications, built on AlmaLinux and Nginx
Managed hosting platforms are convenient until you need a background worker, a specific runtime, or a monthly bill that doesn't jump with traffic. A properly built VPS gives you all three. We set up the server, harden it, put Nginx in front of your app, and hand over documentation so it isn't a black box.
/ Fit check
Best for
Next.js, Node, PHP and Python apps, client portals, internal tools and APIs
Not for
Apps that must scale across many servers automatically. That's a cloud platform job
Deliverables
Hardened server, reverse proxy, TLS, deploy process, backups, monitoring and a runbook
/ Direct answer
What is secure VPS hosting for a custom web application?
Secure VPS hosting means running your application on a virtual private server that was hardened before it went live: key-only SSH, a restrictive firewall, SELinux enforcing, automatic security updates, Nginx as a reverse proxy with TLS, the application bound to localhost, and off-server backups with tested restores. BPro Technologies builds and documents this stack, usually on AlmaLinux, and can manage it afterwards.
- Hardened before the app goes live
- App reachable only through Nginx
- Backups off the server and tested
/ 01
Why use AlmaLinux for a production web server?
AlmaLinux is a free, community-run rebuild of Red Hat Enterprise Linux. That means long security support (about ten years per major version), predictable updates and SELinux switched on by default. For a server you want to leave running for years without surprises, that stability matters more than having the newest packages.
We also work with Ubuntu LTS where a project or team prefers it. The hardening principles are the same, only the commands change.
/ 02
What does an Nginx reverse proxy do?
Nginx sits in front of your application and handles everything the app shouldn't have to: TLS certificates, HTTP/2, compression, static file caching, rate limiting and security headers. The application listens only on localhost, so the internet can only reach it through Nginx. This website runs on the same pattern.
server {
listen 443 ssl http2;
server_name app.example.com;
ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
server_tokens off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}On AlmaLinux, SELinux stops Nginx connecting to a local app port by default. The fix is one boolean (setsebool -P httpd_can_network_connect 1), not switching SELinux off.
/ 03
How is the server hardened before launch?
Before any application code arrives, the server is fully patched, root login and password SSH are disabled, the firewall allows only the ports the app needs, SELinux stays enforcing, security updates install automatically, and brute-force attempts get banned. The app then runs as its own unprivileged user, with secrets kept outside the web root.
The full step-by-step procedure, with commands, is in our technical runbooks.
- Named admin user with SSH keys, no root login
- Firewall limited to SSH, HTTP and HTTPS
- SELinux enforcing, with the minimum booleans
- Automatic security updates via dnf-automatic
- fail2ban watching SSH
- App user with no shell and no sudo
/ 04
How do you deploy a Next.js app on a VPS?
Build the app on the server or in CI, run it with a process manager such as PM2 or systemd on a localhost port, and put Nginx in front for TLS, compression and security headers. Each deploy pulls the new code, builds it and reloads the process. This website is deployed exactly this way, and the full commands are in our technical runbooks.
Environment variables that start with NEXT_PUBLIC_ are baked in at build time, so the production .env file must be in place before the build runs. Quote any value that contains spaces, or shell tools that read the file will break it.
/ 05
How do deployments avoid downtime?
The new version is built alongside the running one, then the process manager reloads it so requests are handed over rather than dropped. If the health check fails, the previous release is still on disk and we switch back. For most business apps this is a simple scripted pipeline from GitHub. It doesn't need Kubernetes.
/ 06
What about backups and monitoring?
Backups go off the server on a schedule, with retention agreed up front, and restores are tested rather than assumed. Monitoring covers uptime from outside, TLS certificate expiry, disk space, memory and application errors, with alerts going to a person rather than a shared inbox nobody reads.
/ 07
Should we use a VPS or a managed platform?
A managed platform is the better choice when you want no server administration at all and traffic is very spiky. A VPS wins when you need background jobs, long-running processes, specific system packages, data kept in a chosen region, or a predictable monthly cost. We'll recommend the platform first and build second.
Frequently Asked Questions
Whichever suits your region, budget and support needs. We recommend the server sits in your own account, not ours, so the setup is portable and you're never locked in.
Yes. We start with an audit covering what's running, what's exposed, how it's backed up and what isn't documented. You get a findings list before we change anything.
It can be, if it's hardened, patched, monitored and backed up, and if the application itself is secure. The server is only one layer, so we review both.
Let's Encrypt certificates are issued and renewed automatically, and we monitor expiry separately in case a renewal ever fails quietly.
Yes, as part of a web maintenance or managed IT agreement: patching, monitoring, backups, restore tests and incident response.
/ Next step
Need a server built, or one someone else built checked over?
Tell us what the application is, where it runs today and what worries you about it. We'll come back with a scoped plan.