Deploying to the cloud

What "the cloud" is

The cloud is other people's computers in big buildings called data centres, rented over the internet. Instead of buying a server for lakhs of rupees, you rent one by the hour and can switch it off any time. Cloud companies also rent ready services: databases, file storage, queues and more, so you do not have to run them yourself.

The big clouds and their Indian regions

A region is a group of data centres in one area. Picking a region near your users makes the app faster, and some Indian rules (for example the RBI rule on payment data) require certain data to be stored in India.

For a first project, simpler platforms like Render, Railway or Fly.io are often easier: connect your GitHub repo, set environment variables, and they build and run it with HTTPS. Use a managed database too (for example Amazon RDS, Google Cloud SQL, Neon or Supabase for Postgres): the provider handles backups, updates and failover, which are hard to do well yourself.

Domain, DNS and HTTPS

A domain is your name on the internet, like api.example.in, bought from a registrar for a yearly fee. DNS (Domain Name System) is the internet's phone book: it turns that name into the address of your server. You add records at your DNS provider: an A record points a name to an IPv4 address, a CNAME points a name to another name (common with platforms), and a TXT record holds text used to prove you own the domain.

dig +short api.example.in             # which address does this name point to?
sudo certbot --nginx -d api.example.in # get a free Let's Encrypt certificate for nginx
curl -I https://api.example.in/healthz  # check HTTPS works and see the response headers

HTTPS encrypts traffic between users and your server so nobody on the Wi-Fi can read passwords or OTPs. It needs a certificate. Let's Encrypt gives free certificates that last only a short time (90 days, and planned to get shorter), so renewal must be automatic. Certbot sets up that renewal for you.

Environment variables in production

In production, settings like DATABASE_URL, REDIS_URL and payment keys come from environment variables set in the platform's dashboard or a secret manager, never from a file in git. Check at startup that every required variable is present, and stop with a clear message if one is missing. Failing fast at boot is far better than failing on the first real payment.

Zero-downtime deploys

1. Start the new version next to the old one.
2. Wait until its health check (for example GET /healthz) answers 200.
3. Move traffic to the new version, a few servers at a time (a rolling deploy) or all at once to a ready copy (blue-green).
4. Stop the old version only after the new one is healthy. If the new one fails, traffic never moves, and rollback is instant.
5. Make database changes backward compatible: first add a new column, deploy code that uses it, and remove the old column in a later release.