< _

VPS Deployment Basics for Developers

Abstract generated cover for VPS Deployment Basics for Developers.

A VPS is a virtual private server. That means you rent a small Linux server and manage it yourself. For a developer, a VPS is useful because it gives you control. You can run a static site, a Django app, a Go service, a database, background workers, cron jobs, or small internal tools without needing a large platform. The tradeoff is responsibility. If you manage the server, you need to understand the basics:

  • SSH
  • users
  • firewalls
  • updates
  • services
  • logs
  • reverse proxies
  • backups
  • deployment steps You do not need to become a full-time sysadmin to run small projects, but you do need a careful baseline.

The Mental Model

Think of a VPS as a remote Linux machine. Your app is only one part of the setup. The server also needs:

  • a secure way to log in
  • a user to run the app
  • a way to start the app after reboot
  • a way to accept web traffic
  • a way to inspect failures
  • a way to recover if something breaks Deployment is not just copying code. Deployment is making the project run reliably somewhere other than your laptop.

SSH Access

SSH is the normal way to access a VPS. You connect with:

ssh [email protected]

For real use, SSH keys are better than password login. A common flow is:

ssh-keygen -t ed25519 -C "[email protected]"

Then you add the public key to the server. Once key access works, password login can often be disabled. That reduces one common attack surface. The exact setup depends on the server provider and Linux distribution, but the principle is the same:

Use SSH keys and keep login access narrow.

Users and Permissions

Do not run every app as root. Root can change anything on the system. That is useful for administration and dangerous for application processes. A better pattern is:

  • use root or a sudo user for server setup
  • create a dedicated user for the app
  • keep project files owned by the app user
  • give the app only the permissions it needs For example: ```plain text /srv/my-site/
could be owned by a \`deploy\` or project-specific user.
This keeps mistakes smaller.
## Firewall
A basic web server usually needs only a few open ports:
```plain text
22   SSH
80   HTTP
443  HTTPS

Everything else should be closed unless there is a reason. On Ubuntu, many people use `ufw`:

sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

The command details may vary, but the idea is simple:

Expose only what the project actually needs.

Running the App

For a static site, deployment may be as simple as copying files into a directory served by Nginx. For a backend service, you need a process manager. On Linux, `systemd` is commonly used to run services. A service can:

  • start on boot
  • restart on failure
  • write logs
  • be controlled with `systemctl` Example commands:
sudo systemctl status my-app
sudo systemctl restart my-app
sudo journalctl -u my-app

Even if you do not write the service file immediately, understand the job it performs.

Reverse Proxy

Nginx is often used as a reverse proxy. It can:

  • listen on ports 80 and 443
  • serve static files
  • forward traffic to an app running on an internal port
  • handle TLS certificates
  • apply redirects For example, your app might run on: ```plain text localhost:8000
Nginx listens publicly on:
```plain text
https://example.com

and forwards requests to the app. That keeps the app process away from direct public exposure.

Logs

Logs are not optional. When something breaks, you need to know where to look. Useful places:

sudo journalctl -u my-app
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

Application logs and web server logs answer different questions. Nginx logs may show that requests are failing before they reach your app. App logs may show errors inside your code.

Common Mistakes

Mistake 1: Deploying manually with no notes

If deployment only exists in your memory, it will break later. Write down the steps or script them.

Mistake 2: Running everything as root

It may work, but it increases risk. Use dedicated users and limited permissions where practical.

Mistake 3: Ignoring backups

Deployment is not complete if you cannot recover important data. Static files may be rebuildable. Databases and user uploads may not be.

Where This Shows Up in Real Projects

A VPS is a good fit for many personal and small business projects:

  • static personal site
  • Django app
  • Go API
  • internal dashboard
  • webhook listener
  • scheduled automation
  • small PostgreSQL-backed service The key is not making the server fancy. The key is making it repeatable and understandable.

Key Takeaways

  • A VPS is a remote Linux server you manage.
  • Use SSH keys and narrow access.
  • Run apps with limited permissions where possible.
  • Use a firewall to expose only needed ports.
  • Use a service manager for long-running apps.

  • Keep deployment steps and recovery notes documented.

    Related Articles

  • Nginx Basics for Developers

  • Docker Compose for Small Projects
  • PostgreSQL Backups for Small Projects

← Back to Blog Index