The Challenge • An existing JavaScript application, already built • No hosting chosen yet • A small budget, so cost mattered as much as reliability • A requirement that the app work correctly after deployment, not just “upload and hope”

Step 1: Work Out What Kind of App It Is

The hosting choice depends on what you are deploying, so I started there:

• Static frontend only (React, Vue, plain JS built into HTML, CSS, and JS files): needs file hosting only • Node.js backend or API: needs a server that stays running • Database: needs a managed database or a server you maintain • Background jobs or file uploads: needs persistent storage and a process that doesn’t sleep

Step 2: Match the App to a Hosting Type

Prices and free-tier limits change often, so check each provider’s current pricing page before deciding.

What I chose:Firebase Hosting, with Cloud Firestore as the database.

Why: The app was a JavaScript frontend that already used Firestore, so keeping hosting and database in the same Firebase project meant fewer moving parts and one place for the client to manage everything. Firebase Hosting serves files over a global CDN with free HTTPS, which fit a small budget, and its free tier was enough for an app of this size. Deploying takes one command from the project folder, so future updates are quick and the client doesn’t need me for small changes.

Step 3: Deploy It Properly

• Environment variables: moved secrets such as API keys and database URLs out of the code and into the host’s settings

• Build and start commands: [your commands, for example npm run build and node server.js], tested before the first deploy

• Git-based deploys: connected the repository so pushing to main redeploys automatically, which means the client doesn’t need me for small updates • Domain and HTTPS: pointed DNS to the host and confirmed the SSL certificate was active

• CORS and API URLs: checked that the frontend talks to the right backend in production, not localhost

Step 4: Test After Deployment

“It deployed” isn’t the same as “it works.” I checked:

• Every main page and user flow on desktop and mobile

• Forms, logins, and API calls in the live environment

• Browser console and server logs for errors

• Page load speed

• That refreshing a page doesn’t return a 404 (a common single-page-app problem)

Step 5: Keep It Running

• Added a free uptime monitor so the client is alerted if the site goes down

• Confirmed how logs can be viewed

• Explained backups, if a database is involved

• Wrote a short handover note covering how to redeploy, where the environment variables live, and what the monthly cost should be

Hidden Costs to Check Before You Choose a Host

• Bandwidth or request limits

• Database storage and connection limits

• Build minutes Domain renewal

• Email sending (often not included)

• The price after a free trial or free tier ends

A host that looks cheaper per month can cost more once these are counted.

Lessons Learned

1. Choose the host after you understand the app, not before.
2. The cheapest option isn’t always the best value. A server that sleeps can cost you users.
3. Automate deploys. Git-based deploys save the client money on every future change. Hand over documentation. A client who understands their setup is more likely to hire you again.\

Need Something Similar?

I help teams and small businesses deploy JavaScript, MERN, and Laravel applications on AWS, Azure, and budget-friendly hosts, with security and CI/CD included. If you have an app that’s ready to go live, you can reach me on www.linkedin.com/in/pdeep1506 or pdeep1506.work@gmail.com .

Related: How I Deployed a Laravel + React App to Production on AWS :- https://pdeep1506.hashnode.dev/laravel-react-aws-production-deployment

The Challenge

The client’s team had built the application and needed someone to own the infrastructure side:

• AWS environment setup

• Production LAMP stack configuration for the Laravel backend

• Deployment of the React frontend

• Security testing of the application

• A web application firewall (WAF) in front of everything

The project ran from July 2025 to early September 2025. It took longer than first planned because the scope grew along the way, which is common in real deployments.

Step 1: Laying the AWS Foundation

Before touching the application, I set up the cloud environment:

• Networking: a VPC with public and private subnets, so only what needs to be internet-facing is exposed

• Compute: EC2 instances for the application servers

• Access control: IAM roles with least-privilege permissions instead of shared credentials

• Security groups: tight inbound rules, allowing only the ports the app requires

Step 2: Production LAMP Stack for Laravel

Laravel runs well on Linux, Apache, MySQL, and PHP, but production needs more than composer install:

• Apache virtual hosts configured with the document root pointing to /public

• PHP-FPM tuned for production, with debug mode off

• A properly secured .env file, never exposed or committed

• Correct file permissions for storage and bootstrap/cache

• Queue workers and the scheduler managed with Supervisor and cron

• Database access locked down, with credentials separated from the app server

• HTTPS enforced with a valid SSL certificate

The goal is a setup that survives reboots, deploys cleanly, and can be reproduced.

Step 3: Deploying the React Application

The React frontend was built into static assets and served alongside the backend. Key points:

• Environment-specific API URLs set at build time

• Compressed, cached static assets

• Proper routing fallbacks so client-side routes don’t return 404s on refresh

• CORS configured so the frontend and API talk to each other, and nobody else

Step 4: Security Testing

Before calling anything production-ready, I tested the application the way an attacker would think about it. I checked for:

• Common vulnerabilities such as SQL injection, XSS, and CSRF

• Exposed files and directories, such as .env, .git, and backups

• Weak or missing security headers

• Outdated packages and server software

• Misconfigured permissions and open ports

Each finding was documented and fixed, then retested. Laravel’s built-in protections help a lot, but they don’t cover server misconfiguration. That part is the infrastructure owner’s job.

Step 5: Adding a Web Application Firewall

The last layer was an AWS WAF in front of the application. It filters malicious traffic before it reaches the servers:

• Managed rule sets covering common attacks (OWASP-style threats)

• Rate limiting to slow brute-force and bot traffic

• Blocking of known bad inputs and suspicious patterns

I started in monitoring mode to check for false positives, then switched to blocking once the rules were tuned. Going straight to blocking can break legitimate users.

Lessons Learned

1. Scope changes are normal. Deployments uncover things nobody planned for. Clear communication matters more than a perfect initial estimate.

2. Security is a layer cake. Network rules, server hardening, application checks, and a WAF each catch different problems.

3. Document everything. A deployment the client can’t understand or repeat is only half delivered.

4. Staging first. Test the full flow before production, every time.

Final Thoughts

The client left a 4.9/5 review and said they’d hire me again.

Need something similar?

I help teams take finished applications to secure, production-ready infrastructure on AWS and Azure: server setup, CI/CD, security hardening, and WAF. If you have a Laravel, Node.js, or React app ready to go live, you can reach me on www.linkedin.com/in/pdeep1506 or pdeep1506.work@gmail.com .