DEV Community

Cover image for Configuring a VPS From Scratch (Debian)
Elvis Ansima
Elvis Ansima

Posted on

Configuring a VPS From Scratch (Debian)

A practical guide for developers who want control, security, and predictable infrastructure costs.

+Bonus: Using a Cloudflare Worker as a Secure Proxy

Introduction

Modern application development often relies on managed cloud services such as PaaS platforms, serverless functions, and hosted databases. While these services reduce operational overhead, they can become expensive and opaque as projects grow.

An alternative approach is to deploy applications on a Virtual Private Server (VPS), configured and secured from the ground up. This method provides greater control, predictable costs, and a deeper understanding of the underlying infrastructure.

This guide covers:

  • Secure configuration of a Debian-based VPS
  • Installation of a modern web application stack
  • Best practices for permissions, backups, and monitoring
  • A bonus section on using a Cloudflare Worker as a reverse proxy to protect production servers

1. Why choose a VPS from scratch?

A properly configured VPS offers:

  • Fixed and predictable monthly costs
  • Full control over system configuration
  • Reduced attack surface
  • No vendor lock-in

In many cases, a low-cost VPS can replace multiple managed services that are billed per request, per second, or per gigabyte.

2. Base operating system: Debian Stable

Debian Stable is well suited for servers due to:

  • Long-term stability
  • Reliable security updates
  • Minimal breaking changes
  • Strong community support

Debian releases a new stable version approximately every three years, making it ideal for long-running production environments.

3. Securing the primary entry point: SSH

SSH is the primary administrative access point and should be hardened carefully.

Recommended SSH practices

  • Disable root login
  • Disable password-based authentication
  • Use SSH keys exclusively
  • Change the default SSH port
  • Protect against brute-force attacks

Example SSH configuration (/etc/ssh/sshd_config)

PermitRootLogin no
PasswordAuthentication no
Port 24560
Enter fullscreen mode Exit fullscreen mode

⚠️ Always confirm key-based authentication works before disabling password access to avoid lockout.

Protection tools

apt install fail2ban
Enter fullscreen mode Exit fullscreen mode

Optional:

  • CrowdSec for collaborative attack detection and mitigation

4. Firewall configuration

A default-deny firewall policy is recommended.

Using UFW (Uncomplicated Firewall is a program for managing a netfilter firewall designed to be easy to use.) :

ufw allow 24560/tcp   # SSH
ufw allow 80
ufw allow 443
ufw enable
Enter fullscreen mode Exit fullscreen mode

Only explicitly required ports should be exposed.

5. Application stack

A typical modern VPS stack includes:

Web server

  • Apache

Backend and tooling

  • PHP (via sury.org for newer versions if needed)
  • Node.js
  • Composer
  • NPM

Data and caching

  • MariaDB
  • Redis

Installing only required services reduces complexity and limits attack vectors.

6. File permissions and ownership

A core security principle:

The web server user (www-data) must only have write access where strictly necessary.

For frameworks such as Laravel, this usually includes:

  • storage/
  • bootstrap/cache/

Example permission setup

# Application code owned by deployment user
chown -R elvis:www-data /var/www/app

# Writable directories owned by web server
chown -R www-data:www-data storage bootstrap/cache
chmod -R 775 storage bootstrap/cache
Enter fullscreen mode Exit fullscreen mode

This ensures:

  • Clean Git operations
  • Controlled write access for the web server
  • Reduced impact in case of application compromise

7. Backups and data protection

Backups should be:

  • Encrypted
  • Incremental
  • Stored off-site

Recommended tools:

  • BorgBackup or Restic
  • Automation with backupninja
  • Storage on S3-compatible services

Key considerations:

  • Who can access the backups?
  • Are backups encrypted at rest?
  • What happens to data when disks are decommissioned?

8. Disk encryption and threat modeling

Threat modeling should include:

  • Trust in the hosting provider
  • Physical access to disks
  • Disk lifecycle and disposal policies

Disk encryption (LUKS)

  • Uses AES encryption
  • Encryption keys protected by a passphrase

Trade-off:

  • Manual intervention may be required on reboot

Disk encryption is a risk-based decision depending on operational constraints.

9. Monitoring and observability

Basic monitoring should include:

  • Service availability
  • Disk usage
  • Memory consumption
  • Log inspection

Visibility into system health enables faster detection and resolution of issues.

Here you can use Grafana & Prometheus

10. Bonus: Cloudflare Worker as a secure proxy

A Cloudflare Worker can be used as a reverse proxy to:

  • Hide the origin server IP
  • Filter traffic at the edge
  • Restrict direct access to production infrastructure
  • Reduce attack surface

Redirect handling considerations

When using:

redirect: 'manual'
Enter fullscreen mode Exit fullscreen mode

If the response is returned directly to the browser, the browser will follow redirects independently, outside Worker control.

Safe redirect strategies

  • Allow the Worker to follow redirects (redirect: 'follow')
  • Manually inspect and rewrite Location headers
  • Enforce a whitelist of allowed redirect domains

This ensures that all navigation remains under controlled domains.

Conclusion

Deploying applications on a VPS configured from scratch provides:

  • Cost efficiency
  • Full infrastructure control
  • Strong security boundaries
  • Long-term flexibility

Managed cloud services remain valuable for specific use cases, but for many applications, a well-secured VPS combined with edge-level proxying offers a powerful and economical alternative.

Top comments (0)