Where to deploy

What deploying means

Deploying is copying your app to a server (a computer in a data centre that never sleeps), starting it, and giving it an address people can type. The Notes app has three parts, and each needs a home: the frontend (built files: HTML, CSS and JavaScript), the API (a Node.js process that must keep running) and the database (PostgreSQL, which must keep data safe for years).

Four kinds of homes

PaaS means Platform as a Service: you give it code, it gives you a running app. If you built the Notes app with Next.js instead (pages and API routes in one project), one project on Vercel can serve both. You still need a managed PostgreSQL database next to it.

Trade-offs: ease, control and cost

• Platforms are the easiest: push to GitHub and the new version goes live. You get less control, and the bill grows with traffic and extra services.
• Free plans are great for learning and demos. Many free services sleep when nobody uses them, so the first request after a quiet time is slow (a cold start). Do not run a paying client on them.
• A VPS gives full control and a predictable price, but you must install security updates, set a firewall, watch the disk and set up backups yourself.
• A managed database is usually worth paying for. Backups and safe upgrades are hard to get right, and a lost database cannot be rebuilt.

The VPS way: Nginx in front of Node

On a VPS you usually put Nginx in front of your app. Nginx is a reverse proxy: a server that receives every request from the internet and passes it on to your app, which listens on a private port such as 3000. Nginx also serves the built React files and handles HTTPS. A process manager keeps the API alive: systemd (built into Linux) or PM2 (a Node tool) restarts it after a crash or a reboot. Another common way is to run each part in a Docker container.

server {
    server_name notesapp.in;
    root /var/www/notes/dist;          # built React files

    location / {
        try_files $uri /index.html;    # let React Router handle paths
    }

    location /api/ {
        proxy_pass http://127.0.0.1:3000;   # the Express API
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Region, domain and HTTPS

A region is the city where the data centre stands. If most users are in India, pick Mumbai, or the nearest region your provider has (often Singapore). Keep the API and the database in the same region. One page load can make several database queries, and if the API is in the USA and the database in Mumbai, every query crosses the world and back.

DNS (the Domain Name System) turns a name like notesapp.in into an address computers can reach. You add records at the company where you bought the domain. An A record points a name to an IPv4 address (like 203.0.113.10), an AAAA record to an IPv6 address, and a CNAME record points a name to another name (like notes-api.onrender.com). The bare domain, called the apex (notesapp.in with nothing in front), cannot be a CNAME; many DNS providers offer an ALIAS record (or "CNAME flattening") for it, or you use an A record.

HTTPS needs a certificate, a small file that proves the site really is notesapp.in. Let's Encrypt is a free certificate authority. Platforms get and renew its certificates for you once your DNS points to them. On a VPS, the Certbot tool gets the certificate and renews it automatically before it expires.