How to host a website on VPS

How to host a website on VPS depends on the application you are deploying. A static site needs a web server and DNS. WordPress or another PHP CMS also needs PHP and a database. A Node.js or Python application usually runs behind a reverse proxy. You can build those pieces manually on a clean VPS or use a control panel to manage them through a browser.

This guide owns the fresh-VPS-to-live-website workflow. If you are moving an existing production site with live data, use Website migration to VPS for the cutover and rollback process.

For the broader buying decision, see VPS for website.

Quick sequence · Choose a path · Path checker · Manual path · DNS · Production checklist · FAQ

Quick deployment sequence

A reliable first deployment follows this order:

1. Choose and size the VPS.
2. Choose manual, control-panel or managed administration.
3. Provision a clean operating system or current provider panel image.
4. Secure first access and create a non-root administrative path.
5. Update the operating system.
6. Install only the web stack the application needs.
7. Configure the site/application before public DNS cutover where practical.
8. Deploy files/code and configure ownership, secrets and database access.
9. Restrict the firewall while keeping SSH and required HTTP/HTTPS access working.
10. Test the destination before public DNS.
11. Point the domain to the VPS.
12. Enable HTTPS after the hostname reaches the server.
13. Verify cron/workers, logs, backups and external monitoring.
14. Reboot once and confirm every required service returns automatically.
15. Only then call the deployment production-ready.

Do not install PHP, MySQL, mail or a control panel merely because a generic VPS guide includes them. Install the components your website actually needs.

Choose manual, panel or managed

There are three distinct operating paths.

Manual / no control panel

Choose a clean Linux VPS and administer the stack through SSH.

Good fit when:

• you understand the application stack;
• you want a minimal service footprint;
• you need custom Nginx/Apache/runtime configuration;
• you use scripts, Git or infrastructure-as-code;
• you do not need a traditional hosting-account interface.

This is the merged owner for the old VPS without Control Panel idea. We are not creating another competing URL for the same intent.

Control panel

Use a hosting panel when browser-based site, domain, PHP, database, mail or user management removes meaningful repetitive work.

See VPS with Control Panel. If FASTPANEL is already your choice, use FASTPANEL VPS Hosting.

Managed administration

A panel and management are different. If nobody on your side owns patching, security, backups, monitoring and incidents, decide that before launch.

See Managed vs Unmanaged VPS.

Deployment path checker

This tool identifies the stack path to investigate. It does not replace application documentation.

Prerequisites

Before touching the server, have:

• a VPS sized for the workload;
• the server IP address;
• SSH credentials or key access;
• a working provider console/VNC/recovery path;
• a registered domain and DNS access;
• the website files or application repository;
• the required runtime versions;
• database requirements;
• a plan for secrets/environment variables;
• a backup location;
• an external way to test website availability.

Use VPS sizing for website before deployment if the resource requirement is still uncertain.

VDSina’s current Standard VPS page lists pure OS templates including Ubuntu 26.04/24.04/22.04/20.04, Debian 13/12/11/10, AlmaLinux, Rocky, CentOS, Oracle Linux and ArchLinux. This guide uses Ubuntu/Debian-style examples because the current web-server documentation and package flow are easy to follow; the architecture applies to other supported Linux distributions with different package/service commands.

Choose a VPS for the website

Disclosure: the editor has a professional relationship with VDSina, and this site may earn a commission if you order through this partner link. Choose the server size and operating model from the workload, not from commission.

Choose the operating system

For a manual website server, choose an operating system that:

• is supported by the application/runtime;
• is still maintained;
• your administrator understands;
• has current packages/documentation for the web stack;
• matches any panel requirement if you later use one.

Do not choose the OS only because it is newest. Application compatibility and administrator familiarity matter more.

For a simple current Linux example, Ubuntu 24.04 LTS or Debian 12 are reasonable documentation targets. If your application vendor specifies another supported distribution, follow that requirement.

Secure first SSH access

A new VPS gives you administrative access, but production work should not happen permanently as root.

A safe first-access sequence is:

1. connect using the credentials/key provided by the VPS provider;
2. confirm the server/IP is the one you intended to create;
3. keep the provider console/VNC/recovery route working;
4. create a named administrative user;
5. grant only the required sudo/admin rights;
6. add SSH-key authentication where practical;
7. verify the new login in a second session before disabling or restricting the original access method.

Example on Ubuntu/Debian:

ssh root@SERVER_IP
adduser deploy
usermod -aG sudo deploy

Do not lock out the only working administrative path while “hardening” the server.

Deep SSH/firewall hardening is covered in VPS Security Checklist; this guide keeps only the minimum needed for deployment.

Update the server before installing the stack

On Ubuntu/Debian:

sudo apt update
sudo apt upgrade -y

Reboot if the update requires it, then verify you can reconnect.

Do not postpone security updates until after the website is public.

Manual / no-control-panel path

A manual VPS should contain only the services the application needs.

The common choices are:

Static website

Needed:

• Nginx or Apache;
• website files;
• DNS;
• HTTPS.

Not automatically needed:

• PHP;
• MySQL/MariaDB/PostgreSQL;
• local mail server.

PHP / WordPress website

Usually needed:

• Nginx or Apache;
• PHP-FPM / PHP modules;
• database;
• website files/uploads;
• DNS;
• HTTPS.

For WordPress resource behavior, use VPS for WordPress.

Node.js / Python / custom application

Usually:

• application runtime;
• dedicated non-root application user;
• process manager/systemd service;
• application bound to localhost/private socket where practical;
• Nginx/Apache reverse proxy;
• database only when required;
• DNS;
• HTTPS.

Do not expose a development server directly to the public internet as the production architecture.

Install the web server

Ubuntu’s current server documentation supports both Nginx and Apache. Neither is universally “better”.

For the Nginx example:

sudo apt update
sudo apt install nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx

At this point the server IP should return the default Nginx page if network/firewall rules allow HTTP.

Use Apache instead when the application, team or existing configuration fits Apache better.

Configure the website hostname

DNS and web-server configuration are two halves of the same job.

The DNS provider must point the hostname to the VPS, and the web server must know which site should answer that hostname.

For Nginx, create a server block for the domain. Conceptually:

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.html index.htm;

    location / {
        try_files $uri $uri/ =404;
    }
}

On Ubuntu/Debian, site-specific configurations commonly live under:

• /etc/nginx/sites-available/
• /etc/nginx/sites-enabled/

After changes:

sudo nginx -t
sudo systemctl reload nginx

Always test configuration syntax before reloading.

For a reverse-proxy app, the server block instead proxies requests to the local application port/socket.

Deploy files or application code

Choose a repeatable deployment method.

SFTP/SCP

Good for:

• small sites;
• infrequent manual deployments;
• first-time simple projects.

Risk: it is easy for the production directory to drift away from the source repository.

rsync over SSH

Useful for repeatable file synchronization and efficient incremental updates.

Git-based deployment

Useful when production releases should correspond to repository commits.

CI/CD

Useful when deployment is frequent enough to justify automated build/test/release steps.

Whatever method you use:

• do not deploy as root unless the task genuinely requires root;
• keep application files owned by an appropriate deployment/application user;
• grant the web server only the access it needs;
• keep secrets outside public document roots;
• do not use world-writable permissions as a shortcut.

PHP / WordPress path

For a PHP site on Ubuntu/Debian, install the current supported PHP-FPM packages and required extensions for the application.

Typical architecture:

browser -> Nginx/Apache -> PHP-FPM -> database

Do not copy a random extension list from another CMS. Install what the application actually requires.

For WordPress:

• create a database and dedicated DB user;
• configure PHP upload/memory/execution limits from measured need;
• keep wp-config.php secrets protected;
• configure the site hostname;
• enable HTTPS;
• validate wp-cron/background jobs;
• add caching based on the workload.

Use VPS for WordPress for sizing and performance rather than duplicating it here.

Node.js / Python / custom-app path

Do not run the development command manually in a terminal and call it production.

Use:

• a dedicated application user;
• environment/config file with restricted permissions;
• systemd or an appropriate production process manager;
• automatic restart on failure/reboot;
• local/private application listener;
• Nginx/Apache reverse proxy;
• application logs;
• health checks.

Typical flow:

browser -> HTTPS/Nginx -> application on 127.0.0.1:PORT -> database/external services

Verify the framework’s own production deployment guidance.

Database: install only when required

A static website needs no database.

For a dynamic application that needs one:

• install the supported database engine;
• create a dedicated database;
• create an application-specific user;
• grant only needed privileges;
• keep credentials out of the web root;
• do not expose the database port publicly unless there is a specific secured architecture requiring it;
• include the database in backup and monitoring plans.

Database work can become the real VPS bottleneck even when the web server is almost idle.

File ownership, permissions and secrets

Avoid two common mistakes:

1. running the website as root;
2. making application directories world-writable to “fix” permission errors.

Instead:

• use a deployment/application user;
• understand which process needs read vs write access;
• give uploads/cache directories only the write access they require;
• protect environment files and credentials;
• do not commit production secrets to Git;
• keep private keys outside public document roots.

Exact ownership depends on the application and web-server model; use the application’s documentation rather than copying a universal chmod 777 recipe.

Test before public DNS

Do not make DNS the first real test of the application.

Before public cutover, verify the new server using one of these methods where practical:

• access the server IP for a simple default/static check;
• use a local hosts-file override so example.com resolves to the new VPS only on your computer;
• use a private/test hostname that is not allowed to become an accidental indexed duplicate;
• test the application through the same Nginx/Apache hostname configuration that production will use.

Check more than the homepage:

• important internal pages;
• login/admin;
• forms;
• uploads;
• static assets;
• database reads/writes;
• application/API endpoints;
• redirects;
• logs.

A hosts-file test is especially useful because many applications behave differently under the real hostname than under the raw server IP.

If this is an existing live site, use the stricter cutover process in Website migration to VPS.

Point the domain to the VPS

At the DNS provider, configure the records that should reach this server.

Typical IPv4 setup:

An A record for www is also possible.

Add an AAAA record only if IPv6 is actually configured and reachable on the VPS. A broken AAAA record can make some visitors fail even when IPv4 works.

DNS alone does not make the website work: the Nginx/Apache site configuration must also have the matching hostname.

If you are moving an existing live site, DNS cutover and final-write handling belong to Website migration to VPS.

Add HTTPS after DNS resolves

Obtain a trusted certificate only after the public hostname resolves to the server that will answer the validation request. Make sure the firewall/provider network rules already permit the HTTP/HTTPS validation path you intend to use.

For Nginx/Apache, an ACME client such as Certbot can request and renew Let’s Encrypt certificates. Follow the current Certbot/OS instructions rather than copying an old package command blindly.

Verify:

• certificate covers root and www variants you use;
• HTTP redirects to HTTPS as intended;
• certificate renewal is automated;
• renewal can pass through the firewall/CDN configuration;
• the application generates the correct HTTPS URLs.

Do not enable an HTTPS redirect before you know the certificate path works.

Configure the firewall

Keep administrative access working while changing firewall rules.

A basic public website commonly needs:

• SSH from the required administration source/path;
• TCP 80 for HTTP/ACME/redirects;
• TCP 443 for HTTPS.

Do not expose MySQL/PostgreSQL, Redis or internal application ports publicly just because they listen locally by default.

On a server using UFW, allow the required SSH path before enabling restrictive rules.

Deep firewall/hardening details belong to VPS Security Checklist.

Cron jobs, queues and workers

Dynamic websites often fail after deployment because only the web request path was configured.

Inventory:

• cron jobs;
• queue workers;
• scheduled actions;
• imports/exports;
• email jobs;
• cache warmers;
• background processors.

Make them:

• run as the correct non-root user;
• start automatically when required;
• write to known logs;
• avoid overlapping in ways that exhaust CPU/RAM;
• survive server reboot.

Logs and basic observability

Before production traffic, know where to look when the site fails.

At minimum identify:

• Nginx/Apache access log;
• Nginx/Apache error log;
• application log;
• PHP-FPM/runtime log;
• database log/status;
• system journal;
• disk usage;
• memory/CPU pressure.

Add an external HTTP(S) uptime check so a server failure is visible even when nobody is logged into the VPS.

Deep threshold/alert design belongs to VPS Monitoring.

Reboot validation

A surprising number of first VPS deployments work until the first reboot.

Before calling the server ready:

sudo reboot

After it returns, confirm:

• SSH access;
• Nginx/Apache;
• PHP-FPM or app service;
• database;
• cron/queue workers;
• HTTPS;
• website pages/forms;
• monitoring;
• backup schedule.

If the application only returns after somebody manually launches a command, the deployment is not complete.

When manual / no-panel hosting is the wrong fit

Use a control panel or managed administration instead when:

• nobody is comfortable with SSH and command-line recovery;
• nobody owns OS/security updates;
• nobody can diagnose web-server/runtime/database failures;
• backups are created but nobody can restore them;
• business-critical downtime has no incident owner;
• the team wants mail/users/domains managed through a hosting UI rather than server configuration;
• the application stack is better served by a managed platform.

A manual VPS can reduce panel overhead and maximize control, but it does not reduce the amount of operational responsibility.

Use VPS with Control Panel for panel selection or Managed vs Unmanaged VPS when the missing piece is operational ownership.

Production acceptance checklist

A website is not production-ready merely because the homepage returns HTTP 200.

Backups and monitoring handoff

This page only establishes the minimum handoff.

Before relying on the site:

• schedule backups;
• keep an independent/off-server copy;
• include the database and configuration/secrets required for recovery;
• verify restoreability;
• monitor website availability;
• monitor disk growth;
• watch CPU/RAM/database pressure;
• watch certificate renewal.

The deeper recovery design belongs to VPS Backup Strategy. Monitoring thresholds and alert design belong to VPS Monitoring.

Multiple websites

For several sites:

• use a separate server block/virtual host per hostname;
• separate document roots;
• use separate application/database credentials;
• use separate system users where the trust model requires it;
• avoid one site’s cron/import/backups starving the others;
• account for combined peak load;
• understand that all sites still share one VPS failure domain.

Use VPS for Multiple Websites for capacity and isolation planning.

Technical references

• Ubuntu Server: install Nginx
• Ubuntu Server: configure Nginx
• Ubuntu Server: web services
• VDSina Standard VPS — current pure OS templates

Choose a VPS for your website

Disclosure: the editor has a professional relationship with VDSina. Partner links are marked sponsored. Verify current VPS pricing, operating-system availability and provider terms before ordering.

FAQ

Can I host a website on a VPS without a control panel?

Yes. A clean Linux VPS can host a website with SSH plus the web server/runtime/database components the application needs. That no-panel intent is part of this guide rather than a separate competing page.

Do I need Nginx to host a website on VPS?

No. Nginx and Apache are both common choices. Use the web server that fits the application, configuration and administrator experience.

Does every VPS website need a database?

No. Static websites do not need one. Install MySQL/MariaDB/PostgreSQL only when the application requires a database.

Should I use root to host the website?

No. Root is for administration. Run/deploy the website under appropriate non-root users and services with only the permissions they need.

When should I use a control panel?

Use one when browser-based management of sites, domains, PHP, databases, users, mail or backups removes enough repetitive administration to justify the overhead and constraints.

Can I host WordPress on a VPS without cPanel?

Yes. WordPress needs a compatible web server, PHP, a database, the WordPress files, correct permissions, DNS and HTTPS. A panel is optional.

When should I point DNS to the VPS?

For a new site, once the server is ready to answer the real hostname. For an existing production site, test first and use a controlled migration/cutover plan.

Why does my domain point to the VPS but show the wrong site?

DNS only sends the hostname to the server IP. Nginx/Apache must also have a matching server block/virtual host for that hostname.

When should I enable HTTPS?

After the public hostname resolves to the server and the validation path works. Then issue the certificate, verify root/www coverage and configure the intended HTTP-to-HTTPS redirect.

What should I check after rebooting the VPS?

Confirm the web server, application service/PHP-FPM, database, workers, HTTPS, monitoring and website all return without manual intervention.