How to Deploy a Web Application to the Cloud (Step-by-Step): From Git to Production

Deploying a web application to the cloud can feel intimidating at first—especially when you hear terms like CI/CD, containers, reverse proxies, load balancers, and SSL certificates. The good news: modern cloud platforms make deployment far more approachable than it used to be.

This step-by-step guide walks you through a professional deployment workflow from Git to a production-ready cloud deployment. It’s written in a platform-agnostic way, so you can apply it to AWS, Google Cloud, Azure, DigitalOcean, Linode, or a PaaS (Platform-as-a-Service) like Render, Fly.io, Railway, or Heroku-style platforms.

1) Before You Deploy: Define “Production” for Your App

A production deployment is more than “it runs on the internet.” At minimum, a real production setup includes:

A reproducible build process

Secure handling of environment variables (secrets)

HTTPS enabled

Basic monitoring/logging

A rollback strategy

A deployment method you can repeat (preferably automated)

If you’re deploying a simple project, you may not need advanced architecture—but you do want these basics.

2) Choose Your Deployment Approach (PaaS vs VPS vs Containers)

Before touching cloud resources, decide how you want to host.

Option A: PaaS (Easiest)

Examples: Render, Railway, Fly.io, Vercel, Netlify (frontend), Heroku-like services.

Pros

Very fast deployment from Git

Built-in SSL, scaling, logs

Minimal server management

Cons

Costs can rise at scale

Some limits (custom networking, long-running background jobs, etc.)

Best for: startups, MVPs, small teams, standard web apps.

Option B: VPS (More control)

Examples: DigitalOcean Droplet, AWS Lightsail, Linode.

Pros

Full control of OS and stack

Often cheaper for constant workloads

Cons

You manage updates, security, deployments

Best for: developers comfortable with Linux, custom stacks, lower costs.

Option C: Containers + Orchestrator (Most scalable)

Examples: Kubernetes (EKS/GKE/AKS), ECS, Cloud Run (container-based).

Pros

Powerful scaling and reproducibility

Great for microservices and teams

Cons

More complexity

Best for: serious production systems, complex infrastructure needs.

This guide focuses on a workflow that works for PaaS or VPS, and scales nicely toward containers later.

3) Step 1 — Prepare Your App for Deployment

A) Make your app configurable via environment variables

Production environments should not require code changes.

Examples of env vars:

DATABASE_URL

PORT

NODE_ENV=production

SECRET_KEY

JWT_SECRET

REDIS_URL

In Node.js, you typically read these from

process.env

. In Python/Django or Flask, from OS env vars. In Laravel, from

.env

(but you don’t commit secrets).

B) Add a production build command

Your app needs a “build” step if applicable.

Examples:

React/Vue:

npm run build

Next.js:

next build

Laravel:

composer install --no-dev

,

php artisan config:cache

Django:

pip install -r requirements.txt

, collect static files

C) Ensure the app binds correctly to the platform port

Many cloud platforms set the port dynamically via

PORT

.

A common production rule:

Your app should listen on

0.0.0.0:$PORT

(not localhost-only)

4) Step 2 — Set Up Git the Right Way (Branching + Releases)

A clean Git workflow keeps deployments safe.

A practical setup:

main

branch = production

develop

branch = staging (optional)

feature branches =

feature/...

Recommended best practices:

Tag releases:

v1.0.0

,

v1.0.1

Use pull requests/merge requests

Require checks (tests) before merging into

main

Even if you’re solo, this structure prevents “mystery deploys.”

5) Step 3 — Set Up a Production Database (Managed > Self-hosted)

Most production apps need a database. For production stability, managed databases are usually worth it.

Common managed options:

PostgreSQL (recommended for most modern apps)

MySQL/MariaDB

Managed Redis (for caching/queues)

Why managed DBs:

Automated backups

Monitoring

Easier scaling

Less risk than running your own database on a small VPS

If you do use a VPS database, secure it:

Bind to private network or localhost

Strong passwords

Regular backups

Firewall rules

6) Step 4 — Choose a Deployment Target (Example Plans)

Here are two realistic deployment paths.

Path 1: Deploy via PaaS (Git-to-Production)

Typical flow:

Connect GitHub/GitLab repo

Set build and start commands

Add env vars in dashboard

Deploy on push to

main

Platform provides HTTPS + logs

This is the fastest route for most teams.

Path 2: Deploy to VPS (Server-based)

Typical stack:

Nginx as reverse proxy

App runtime (Node/Python/PHP)

Process manager (systemd, PM2, Supervisor)

SSL via Let’s Encrypt

Firewall + SSH hardening

This is more hands-on but very flexible.

7) Step 5 — Configure CI/CD (Automated Deployments)

CI/CD means: “when code changes in Git, tests run, and deployment happens automatically.”

A basic CI/CD pipeline usually includes:

Install dependencies

Run tests + linting

Build the app

Deploy to cloud

Good CI/CD habits

Deploy only from

main

Add a staging environment if possible

Keep secrets out of Git (use secret storage in CI)

Use “atomic” deployments when possible (avoid partial deploy states)

Even if you start manually, CI/CD is the long-term win for reliability.

8) Step 6 — Set Environment Variables (Secrets) Correctly

Never hardcode secrets in code or commit them to Git.

Store them in:

PaaS environment variables UI

CI secret store (GitHub Actions Secrets, GitLab CI variables)

Secret Manager services (AWS Secrets Manager, GCP Secret Manager)

Typical required secrets:

Database credentials

API keys (payment gateways, email providers)

App secret key / session secret

OAuth client secrets

Pro tip: maintain a

.env.example

file with placeholder values to document required variables without exposing secrets.

9) Step 7 — Deploy the App

PaaS deployment (common steps)

Connect repo

Set:

Build command (e.g.,

npm run build

)

Start command (e.g.,

npm start

)

Add env vars

Deploy

VPS deployment (high-level steps)

Provision VPS

Install system dependencies

Pull code from Git

Install app dependencies

Build app

Run with process manager (PM2/systemd)

Put Nginx in front

Add HTTPS

Set up logs and restarts

If you want the most professional and repeatable VPS setup, consider deploying with Docker (even on one server).

10) Step 8 — Set Up a Domain + DNS

To go from an IP address to a real website:

Buy a domain (or use an existing one)

Set DNS records:

A

record: points

example.com

to your server IP

CNAME

record: points

www

to

example.com

(or to the provider domain if PaaS)

DNS changes can take minutes to propagate, sometimes longer depending on TTL.

11) Step 9 — Enable HTTPS (SSL)

HTTPS is non-negotiable in production:

SEO benefits

Security for logins and payments

Browser trust

On PaaS

Usually one click: “Enable SSL”.

On VPS

Most common approach:

Let’s Encrypt + Certbot

Auto-renewal enabled

Make sure Nginx redirects HTTP → HTTPS.

12) Step 10 — Add Logging, Monitoring, and Alerts

Production without monitoring is like flying blind.

Minimum recommended:

Centralized logs (platform logs or structured logs)

Uptime monitoring (simple ping checks)

Error tracking (Sentry is popular)

Basic metrics (CPU/RAM/disk, response time)

Set alerts for:

app crash/restart loops

high error rate (5xx responses)

database connection errors

disk almost full

13) Step 11 — Run Migrations and Handle Zero-Downtime Changes

If your app has a database schema, you’ll likely need migrations.

Best practices:

Run migrations during deploy

Write migrations that are backward-compatible when possible

Avoid destructive schema changes without a plan

Keep rollout safe: deploy code that supports both old and new schema if needed

Advanced teams use:

blue/green deployments

canary releases

feature flags

But you can start simple: deploy during low-traffic time and have rollback ready.

14) Step 12 — Have a Rollback Strategy

A professional deployment always assumes something can go wrong.

Rollback options:

Re-deploy previous Git tag (

v1.0.2

→

v1.0.1

)

Use container image versions (roll back image tag)

Restore database from backup (last resort)

Use platform “rollback” button (if PaaS supports)

Important: database changes are the hardest to roll back. Plan migrations carefully.

Example Deployment Workflows (Realistic Scenarios)

Scenario A: Frontend + Backend API (PaaS)

Frontend: Vercel/Netlify

Backend: Render/Railway/Fly.io

Database: managed Postgres

DNS:

app.example.com

for frontend,

api.example.com

for API

CI/CD: auto deploy from

main

Scenario B: Full-stack on a VPS

Nginx reverse proxy

Node or Laravel app behind it

PostgreSQL on managed service (recommended)

Redis for cache/queues

PM2/systemd for app uptime

Certbot for SSL

Final Checklist: Git to Production (Quick Summary)

App uses environment variables for config

main

branch is deployable anytime

Managed database provisioned and secured

CI runs tests and builds on push/PR

Deployment target configured (PaaS or VPS)

Secrets stored in env vars (not in Git)

Domain + DNS configured

HTTPS enabled

Monitoring + error tracking enabled

Rollback plan ready

Conclusion

Deploying a web application to the cloud isn’t just “uploading files”—it’s establishing a repeatable, secure, production process. When you build your deployment pipeline from Git, configure secrets properly, enable HTTPS, and set up monitoring, you’re not just launching an app—you’re operating it professionally.

With this workflow, you can start with a simple deployment today and scale toward more advanced infrastructure as your traffic and requirements grow—without needing to rebuild everything from scratch.