From Git Push to Production: My Laravel Deployment Pipeline Without the Complexity

I’ve had exactly one catastrophic deployment failure in my career. Just one. But that single Friday afternoon disaster taught me more about deployment processes than a thousand successful pushes ever could.

It was a Magento e-commerce site, back in the days when we used SVN for version control (yes, I’m showing my age here). We had a proper setup with separate staging and production environments. We’d tested everything thoroughly on staging. The deployment checklist was complete. It was 3 PM on a Friday, and we were confident this would be a smooth rollout.

Fifteen minutes after pushing to production, the entire site was down.

Not just slow. Not just a broken feature. Completely, utterly down. White screen of death across every page. Customers couldn’t browse. They couldn’t check out. The client’s phone was ringing off the hook with angry customers trying to place orders.

The culprit? A single configuration file that existed in staging but hadn’t been tracked in SVN. Something about cache settings and database connections. In staging, the file was there and everything worked perfectly. In production, the file was missing and Magento couldn’t handle it gracefully.

What should have been a 15 minute deployment turned into a 4 hour emergency firefighting session. We had to SSH into the production server, manually recreate the configuration file from memory and staging comparisons, flush about seven different cache layers that Magento loved to maintain, and pray that we got all the settings right. All while the client was losing money with every passing minute.

Three critical lessons from that day:

1. Friday afternoon deployments are cursed and should be avoided at all costs
2. The gap between “it works on staging” and “it works in production” can destroy your weekend
3. Manual deployment processes, no matter how careful you are, will eventually betray you

That was over a decade ago, but the anxiety from that experience stuck with me. I developed a healthy, borderline paranoid respect for the dangers lurking in production deployments.

Fast Forward: Building a SaaS Changes Everything 🚀

When I started building ManageMemberships, I knew I needed something fundamentally different. Client projects have some built-in forgiveness. You can schedule downtime windows. You can call the client and explain what happened. You can work through the weekend to fix things.

SaaS applications don’t have that luxury. When you have paying customers relying on your application 24/7, “oops, sorry about the downtime” stops being acceptable. Every minute of downtime is money lost, trust damaged, and customers questioning whether they made the right choice.

Between that Magento disaster and launching my SaaS, I’d worked with various CI/CD systems. I’d seen the power of automated testing pipelines. I’d experienced the peace of mind that comes from knowing code gets validated before it hits production. I knew the tools existed to prevent my Friday afternoon nightmare from ever happening again.

I needed a deployment process that was reliable, automated, and would let me sleep at night without worrying about what I broke. After months of iteration and learning, I landed on a setup that works beautifully for a solo founder running a SaaS. It’s not perfect, and it’s definitely not the cutting edge Kubernetes setup that some developers obsess over. But it’s reliable, automated, and most importantly, it lets me ship code confidently without breaking things.

The Evolution: From Panic to Pipeline

My deployment journey probably mirrors many solo developers. In the beginning, I was SSHing directly into servers, running git pull, manually running migrations, restarting services, and hoping nothing exploded. Sound familiar? Every deployment felt like playing Russian roulette with my application.

The difference now was that I’d seen better approaches. I knew CI/CD pipelines existed. I’d worked with automated testing in other contexts. But the DevOps rabbit hole is deep and overwhelming. Docker Swarm? Kubernetes? CircleCI? GitHub Actions? Jenkins? The options were paralyzing, and most tutorials assumed you had a dedicated DevOps team or wanted to spend weeks configuring complex pipelines.

What I really needed was something that:

• Automatically ran my tests before deploying anything
• Handled zero downtime deployments without manual intervention
• Gave me a rollback option when things went wrong
• Didn’t require a PhD in infrastructure engineering
• Cost a reasonable amount for a bootstrapped SaaS

That’s when I discovered the combination of Laravel Forge, Envoyer, and a simple CI runner could give me 90% of what enterprise pipelines provide with 10% of the complexity.

My Actual Deployment Stack

Here’s what my deployment pipeline looks like today, running on AWS infrastructure:

The Core Components:

• GitHub for version control and triggering deployments
• A CI runner that executes my test suite automatically
• Envoyer for zero downtime deployment orchestration
• Laravel Forge managing my AWS server infrastructure
• S3 for asset storage and backup management
• AWS snapshots for complete server backups
• Sentry for error tracking and application monitoring
• Aikido for security insights and vulnerability scanning

When I push code to my main branch, here’s exactly what happens:

1. Git receives the push and triggers my CI runner via webhook
2. The runner spins up and immediately starts running my PHPUnit test suite
3. Aikido scans for security vulnerabilities in my dependencies
4. If tests pass and no critical vulnerabilities are found, the runner makes an HTTP request to a specific Envoyer webhook URL
5. Envoyer receives the trigger and begins its deployment process
6. Zero downtime magic happens as Envoyer manages the entire deployment to Forge
7. My application updates without users experiencing any interruption
8. Sentry gets notified of the new release and starts tracking errors tagged with the deployment version

If tests fail or Aikido finds a critical security issue? Nothing deploys. The pipeline stops cold, and I get a notification that something’s broken. This single safeguard has saved me countless times from shipping bugs or vulnerabilities to production.

The CI Runner: My First Line of Defense

Setting up the CI runner was surprisingly straightforward, though it took some experimentation to get right. I’m running a GitHub Actions workflow that triggers on every push to my main branch.

My runner configuration does several critical things:

First, it sets up a clean PHP environment with all my dependencies. The runner installs Composer dependencies, sets up my test database, and configures environment variables. This ensures tests run in an environment that closely mirrors production.

Second, it runs my entire test suite. I’ll be honest, I don’t have 100% code coverage, and I’m okay with that. What I do have are tests covering critical paths: user authentication, payment processing, subscription management, API endpoints, and database migrations. These are the things that absolutely cannot break.

The tests typically take 5 to 10 minutes to run. Fast enough that I’m not waiting around, slow enough that I know they’re actually checking important things.

Here’s the clever part: If all tests pass, the runner executes a curl command to hit my Envoyer webhook URL. It’s literally just:

bash

curl -X POST https://envoyer.io/deploy/[my-webhook-url]

That single HTTP request is what kicks off the entire deployment process. Simple, reliable, and it works every single time.

Envoyer: The Deployment Orchestrator

Envoyer is where the real magic happens, and honestly, it’s worth every penny of the $10/month I pay for it. Before Envoyer, I was terrified of deployments. After Envoyer, deployments became boring. And boring is exactly what you want.

What Envoyer handles automatically:

When it receives the webhook trigger, Envoyer connects to my Forge managed server and starts a carefully orchestrated deployment dance:

1. Clones the latest code into a new release directory
2. Installs Composer dependencies with optimized autoloading
3. Runs database migrations in the correct order
4. Compiles frontend assets if needed
5. Symlinks the new release to become the active version
6. Restarts queue workers to pick up new code
7. Clears and warms caches for optimal performance
8. Keeps the last 5 releases for instant rollback if needed

The entire process takes about 30 to 45 seconds, and users don’t experience a single second of downtime. The symlink swap is atomic, which means there’s never a moment where the application is in a broken state.

The rollback safety net is what really lets me sleep at night. If I deploy something and realize there’s a problem, I can click one button in Envoyer and instantly roll back to the previous release. No scrambling, no panic, no restoring from backups. Just click and boom, you’re back to the working version.

I’ve used this rollback feature once in production, and it saved me a lot of stress and gave me breathing room to push a proper fix.

Forge: Managing Infrastructure Without the Pain

Laravel Forge is managing my AWS infrastructure, and it’s handling all the server configuration that I used to do manually and incorrectly.

What Forge does for me:

• Provisions and configures my AWS EC2 instances
• Sets up Nginx with optimal Laravel configuration
• Manages SSL certificates automatically via Let’s Encrypt
• Configures PHP-FPM with proper memory limits and workers
• Sets up my database with correct permissions
• Manages my queue workers and keeps them running
• Handles scheduled tasks (Laravel’s cron jobs)
• Monitors server resources and sends alerts

The biggest value? I don’t have to remember obscure server configuration commands. I don’t have to debug why Nginx is returning 502 errors. I don’t have to manually renew SSL certificates. Forge just handles it.

The Backup Strategy: S3 and Snapshots

Here’s something I learned the hard way: automated deployments are great until you need to recover from a catastrophic failure. My backup strategy has two layers, and both are automated.

Layer 1: S3 for File Storage

All user uploaded files go directly to S3. Profile images, documents, exports, everything. This serves two purposes:

First, it keeps my server lean. I’m not filling up disk space with gigabytes of user files. Second, S3 is inherently backed up and distributed. If my server explodes, all user files are completely safe in S3.

I’m using Laravel’s built-in filesystem abstraction, so switching from local storage to S3 was literally just changing the FILESYSTEM_DISK environment variable. The application code didn’t change at all.

Layer 2: AWS Snapshots for Complete Server State

Every single day at 3 AM UTC, AWS automatically takes a complete snapshot of my server. This captures everything: the database, the application code, the configuration files (yes, including those configuration files that bit me in the Magento days), all of it.

I keep 7 daily snapshots and 4 weekly snapshots. This gives me a 30 day window to recover from almost any disaster scenario. Accidentally deleted critical data? Restore from yesterday’s snapshot.

Here’s what I actually test: Every quarter, I restore a snapshot to a staging server and verify that everything works. Database intact? Check. Files accessible? Check. Application functional? Check. I learned this lesson from a startup that discovered their backups were corrupted only when they desperately needed to restore them. Testing your restore process is just as important as having backups in the first place.

Monitoring: Knowing When Things Break (Before Customers Tell You) 👀

Here’s a truth about production applications: things will break. The question isn’t if, but when. And more importantly, will you find out from your monitoring tools or from an angry customer email?

After that Magento disaster where we were flying blind for the first 15 minutes, I knew monitoring had to be a core part of my deployment strategy. I use two tools that give me complete visibility into what’s happening in production.

Sentry for Error Tracking and Logs

Sentry is my eyes and ears in production. The moment an exception gets thrown anywhere in my application, I get a detailed report. Not just the error message, but the full stack trace, the user’s browser information, the route they were hitting, and even the breadcrumb trail of actions that led to the error.

I integrated Sentry early in ManageMemberships, and it’s caught bugs I never would have found through manual testing. Database query timeout on a specific edge case? Sentry caught it. JavaScript error only happening in Safari? Sentry flagged it. Payment processing failure at 2 AM? Sentry woke me up (well, sent me a notification at least, my alerts are configured sanely).

The Laravel integration is straightforward. Install the package, add your DSN to the environment variables, and suddenly you have enterprise level error tracking. When Envoyer deploys a new release, Sentry automatically tags errors with the release version, so I can immediately see if a deployment introduced new problems.

Real world example: Last month I deployed a feature that worked perfectly in my local environment and passed all tests. Within an hour of deployment, Sentry caught a PHP memory exhaustion error that only happened when processing exports with more than 5,000 records. The error report included the exact query that caused it, the memory usage graph, and even the user’s session data. I had a fix deployed within 30 minutes. Without Sentry, I would have discovered this issue only when a customer complained about failed exports.

Aikido for Security Insights

While Sentry tells me when my code breaks, Aikido tells me when my code might be vulnerable. It’s my security co-pilot, constantly scanning for dependency vulnerabilities, suspicious patterns, and potential attack vectors.

Aikido integrates directly into my GitHub repository and runs security checks as part of the deployment pipeline. If a critical vulnerability is discovered in one of my Composer dependencies, I know about it immediately. It’s caught several high severity issues in third party packages before they became problems.

How They Work Together

Sentry and Aikido complement each other perfectly. Sentry tells me what’s actually breaking. Aikido tells me what could break or what might be under attack. Together, they give me confidence that I’ll know about problems quickly and can respond before they impact customers.

Both tools integrate seamlessly with my deployment pipeline. When the GitHub Actions runner completes tests and triggers the Envoyer deployment, both Sentry and Aikido are notified of the new release. This means all my monitoring is automatically tagged with deployment information, making it trivial to correlate issues with specific code changes.

The combined cost? Free for both services at my current scale. For a solo founder, these tools are force multipliers. They let me sleep at night knowing that if something breaks, I’ll know about it immediately with enough context to fix it quickly.

The Solo Founder Perspective: What Actually Matters

Here’s the thing about DevOps as a solo founder: you’re optimizing for different goals than a large engineering team.

Large teams optimize for:

• Maximum flexibility and customization
• Supporting dozens of microservices
• Complex compliance requirements
• Scaling to millions of users
• Multiple deployment environments and teams

Solo founders optimize for:

• Shipping features quickly without breaking things
• Sleeping soundly without 3 AM emergency pages
• Minimal maintenance overhead
• Reasonable costs for bootstrapped budgets
• Simple enough to understand when something breaks

My pipeline isn’t the most sophisticated. I’m not doing blue green deployments or canary releases. I don’t have separate staging, QA, and production environments. I’m not running infrastructure as code with Terraform.

But you know what? My deployment success rate is probably 99%+. I can push code multiple times per day without anxiety. When something does break, I can roll back in 10 seconds. And the entire setup costs me $20/month in tooling on top of my AWS hosting costs.

The Practical Takeaway

If you’re running a Laravel application and doing manual deployments, or you’re afraid to ship code because you might break production, here’s what I recommend:

Start simple, automate incrementally:

1. Get your tests running in CI first. Even basic tests are better than no automated testing. GitHub Actions has a generous free tier.
2. Use Forge for server management. Stop manually configuring servers. It’s not worth your time, and you’ll probably misconfigure something important.
3. Add Envoyer for zero downtime deployments. The peace of mind is worth far more than $10/month.
4. Set up automated backups immediately. S3 for files, snapshots for complete server state. Test your restore process quarterly.
5. Install Sentry before you launch. You want error tracking from day one, not after you’ve accumulated technical debt.
6. Add Aikido for security scanning. In today’s threat landscape, you can’t afford to be reactive about security vulnerabilities.
7. Add monitoring gradually. Start with basic uptime monitoring, then layer in performance monitoring as you grow.

You don’t need to implement everything at once. I built this pipeline over months, adding pieces as I encountered problems and learned what mattered. The key is to automate the critical path first (testing and deployment) and then add observability (monitoring and security) as quickly as your budget allows.

The Friday Afternoon Test

Here’s how I know my deployment pipeline actually works: I can push code on a Friday afternoon without fear.

That might sound trivial, but it’s the ultimate test. If you’re comfortable deploying significant changes right before the weekend, when you won’t be around to fix things immediately, your automation is working.

I pushed a major feature update last Friday at 4 PM. Tests passed, Aikido gave it the green light, Envoyer deployed smoothly, Sentry started monitoring the new release, users began using the new feature, and I went to dinner without checking my phone every five minutes. That’s the dream.

My deployment process isn’t revolutionary. It’s not going to be written up in tech blogs or win architecture awards. But it works reliably, it’s affordable, and it lets me focus on building features instead of babysitting infrastructure or recovering from deployment disasters.

And honestly? That’s exactly what a solo founder’s deployment pipeline should do. It should be boring, reliable, and forgettable. Save the excitement for shipping features, not fixing broken deployments.

The goal isn’t to have the fanciest CI/CD setup. The goal is to never experience your own Friday afternoon Magento disaster. Mission accomplished.