Back to Blogs
LaravelPowerShellHostingerDeploymentWinSCPSFTP

A Simple PowerShell Script for Faster Laravel Deployments to Hostinger

Muhammad Umar
4 min read

Deploying a Laravel project to shared hosting should be routine. For me, it often was not.

Each small update followed the same pattern:

  • build the project
  • review files manually
  • open WinSCP
  • upload everything over SFTP
  • wait for the transfer to finish
  • hope nothing important was missed

The process worked, but it was slow, repetitive, and too dependent on manual checks. After doing that enough times, I wrote a small PowerShell script to make the workflow faster and more reliable.

The Problem

The real issue was not whether deployment was possible. The issue was that the process added friction to every release.

I wanted a tool that could:

  • deploy a Laravel project quickly
  • avoid uploading unnecessary local files
  • work well with Hostinger shared hosting
  • reuse my existing WinSCP-based workflow
  • run with a single command

I was not looking for a full CI/CD pipeline. For smaller projects, that would have been unnecessary overhead. I wanted something lightweight, practical, and easy to trust.

What the Script Does

The script prepares a clean deployment package from a local Laravel project and uploads it to Hostinger using SFTP.

It supports:

  • reading deployment settings from a .env file
  • SSH key authentication
  • WinSCP when it is installed locally
  • fallback to OpenSSH sftp when WinSCP is not available
  • excluding local-only files and folders from upload
  • optionally skipping the vendor directory
  • optionally rebuilding vendor for a production-ready deploy

In practice, it turns a repetitive set of manual steps into one repeatable command.

Why SFTP Matters

People often use the term “FTP deployment” loosely, but this script uses SFTP over SSH, not plain FTP.

That distinction matters. SFTP is encrypted, better aligned with modern hosting environments, and a more sensible default for deployment automation.

Why I Kept It Simple

There are more advanced deployment approaches available. CI/CD pipelines, release directories, rollbacks, and server provisioning all have their place.

But not every Laravel project needs that level of complexity, especially when the target environment is shared hosting. In this case, the goal was not to build a complete deployment platform. The goal was to remove wasted time from a common task.

I built this for a very specific scenario:

  • the project is hosted on Hostinger shared hosting
  • the application still receives regular updates
  • manual uploads take longer than they should
  • a lightweight workflow is more useful than a highly engineered one

Typical Workflow

My deployment flow is now straightforward:

  1. Make changes locally.
  2. Build frontend assets if the project needs them.
  3. Confirm the deployment settings.
  4. Run the script.
  5. Verify the live application.

The command is as simple as:

.\deploy.ps1

That one change removes a surprising amount of repetitive work.

What the Script Excludes

One of the main benefits is that the script avoids uploading files that should remain local.

Common exclusions include:

  • .git
  • .github
  • .vscode
  • node_modules
  • tests
  • local .env files
  • log files
  • cache directories
  • helper files such as README.md and deploy.ps1

That keeps the deployment package cleaner and reduces the risk of pushing development-only files to production.

Handling Composer Dependencies

Composer dependencies are not always handled the same way across projects, so I added flexibility around the vendor directory.

Depending on the deployment target, I may choose to:

  • upload the local vendor directory
  • skip vendor entirely
  • rebuild production dependencies before upload

That makes the script useful across different hosting constraints and deployment preferences.

Why It Was Worth Building

This script did not solve every deployment problem, and it was never meant to. What it did solve was the day-to-day friction of shipping updates to shared hosting.

It helped by:

  • removing repetitive manual steps
  • reducing the chance of missing files during upload
  • making small production updates faster to ship
  • giving me a workflow I actually want to use

Sometimes the best internal tools are not the most elaborate ones. They are the ones that remove the most friction from normal work.

If You Are in the Same Situation

If you are deploying Laravel to Hostinger shared hosting and still relying on manual uploads, a script like this can be enough to make the process significantly better.

You do not always need a large deployment system. Sometimes a focused utility script is the right level of automation.

The script is available here:

GitHub Repository

The repository README covers the exact environment variables and setup steps required for your deployment target.

Final Thoughts

I built this because I was tired of spending unnecessary time on manual deployment.

It started as a personal utility, but it became worth publishing because the underlying problem is common: shared hosting is still widely used, and many deployment workflows are more manual than they need to be.

If your current release process feels slower than it should, the answer may not be more effort. It may simply be better automation.

Back to Blogs