Website AutoDeploy using GitHub Action to NameCheap SharedHosting via SSH access
Let me introduce I’m Serghei, and I’ve been a PHP Developer for over 10 years. I’ve got heaps of experience with all sorts of apps and, throughout my career, I’ve seen plenty of coding practices — the good, the bad, and everything in between.
Now, I’d love to share a few simple, yet essential steps for building a web app. These are must-haves, no matter how small the project is.
Auto Deploy System
Why is so important?
Let’s talk about Auto Deploy Systems and why they’re super important.
So, I once made this website with PHP Symfony. But really, the kind of tech I used isn’t the main point. What’s cool is that everything in the app changed based on what was in the database. I didn’t hardcode anything — no fixed logos, names, or URLs.
My big idea was to create a White Label App. This is like a one-size-fits-all tool that lots of different users could use later on.
Why are Auto Deploy Systems a big deal in this case? Let me explain to you!
So, here’s the scoop: I had this neat website up and running, powered by my app’s logic. Whenever I tweaked the code, I’d just hop onto the server for a quick manual update. It was a simple routine: a git pull, a composer update if needed, and a migrations:migrate .
Easy peasy, right? It only took me like 2 minutes, so I didn’t really see the point of an AutoDeploy system at that time.
But then, plot twist! My website started getting loads of traffic. Thanks to my Symfony App being totally database-driven and free from hardcoded stuff, I was able to spin up an entirely new website. Different niche, different style, different data, but under the hood? The same slick PHP logic. Pretty cool, huh?
So, the plot thickens! With every new code update, I’m now playing double duty — deploying to not one, but two sites. That’s 2 times 2, which equals 4 minutes. Sure, it’s not like I’m spending an eternity, but guess what? After a few days packed with updates, this routine starts feeling like a never-ending game of ‘Deploy Déjà Vu’. It’s not just about the time anymore; it’s the ‘been there, done that’ feeling that starts to make it a bit of a yawn fest.
But here’s the kicker: Fast forward two months, and my collection of websites had ballooned to a whopping 20, all sharing the same code source. Now, let’s do the math: 20 times 2 equals 40 minutes. You might think, ‘Hey, that’s not a huge chunk of your day,’ and you’d be right. But let me tell you, manually deploying the latest code to each server became the most mind-numbingly dull task I’ve ever done in my entire coding career.
It was like watching paint dry, but less exciting.
So there I was, realizing that an AutoDeploy system wasn’t just a ‘nice to have’ — it was essential. My PHP Symfony App was gaining traction, and the need for automation became clear.
Picture this: My app’s on GitHub, and I’m managing a growing portfolio of websites, all hosted with NameCheap.com. Why NameCheap? Simply because it’s affordable.
But with every code update, I faced the repetitive task of deploying to all 20 servers. At times, I even held back on making new updates, dreading the tedious manual deployment that would follow. Looking back, I can see it was a bit silly not to embrace automation sooner.
Alright, enough with the backstory. Let’s get into the technical details.
How to Set Up AutoDeploy System using GitHub Action and NameCheap.com SSH?
In fact, setting up an AutoDeploy system is quite straightforward. It’s easier than you might think.
1. SSH Credentials
First things first, you need to get your SSH credentials to connect to your server. If you’re using NameCheap.com like I did, you can find all the necessary info in the cPanel. Alternatively, this info might be in the email you received from them after signing up for their service. What you’re looking for specifically are these details:
- Host
- Port
- Username
- Password
Remember, the port is crucial, especially if you’re on a shared hosting plan. It’s not the standard ‘22’ but ‘21098’.
2. YAML Deploy File Setting
In your app, create a YML file
.github/workflows/deploy.yml
# This is a basic workflow to help you get started with Actions
name: Build And Deploy
# Controls when the workflow will run
on:
# Triggers the workflow on push or pull request events but only for the "main" branch
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy Website1.com
uses: appleboy/ssh-action@v0.1.4
with:
host: ${{ secrets.W1_HOST }}
port: ${{ secrets.W1_PORT }}
username: ${{ secrets.W1_USERNAME }}
password: ${{ secrets.W1_PASSWORD }}
script: |
cd ~/public_html/
git pull
cp .env.local .env.backup
cp .env.Website1 .env.local
cp .env.Website1 .env.test
composer install
bin/console doctrine:migrations:migrate --no-interaction
bin/console cache:clear
echo "Deployment successful!"
- name: Deploy Website2.com
uses: appleboy/ssh-action@v0.1.4
with:
host: ${{ secrets.W2_HOST }}
port: ${{ secrets.W2_PORT }}
username: ${{ secrets.W2_USERNAME }}
password: ${{ secrets.W2_PASSWORD }}
script: |
cd ~/public_html/
git pull
cp .env.local .env.backup
cp .env.Website2 .env.local
cp .env.Website2 .env.test
composer install
bin/console doctrine:migrations:migrate --no-interaction
bin/console cache:clear
echo "Deployment successful!"and just add as many as you want websites/servers
3. GitHub Secret and Variables
Now the final step is to set your SSH credentials for each website/server to GitHub
Never, ever, not even in your wildest dreams, think of saving your credentials in YML files.
Always, and I mean always, buddy up with secret variables.
Remember, storing your credentials in YML files is like keeping your house keys under the welcome mat. It’s the first place everyone looks! Always opt for secret variables — it’s like having a secret handshake with your application.
And just like that, our AutoDeploy System is all set up. Quick and efficient, right? It’s amazing how a few simple steps can make such a big difference in streamlining our deployment process.
So, how does this AutoDeploy System work?
It’s pretty simple. Whenever there’s a deployment to the main branch (and you can customize this to any branch you prefer, like prod or staging), the script’s actions are automatically executed on the server. This means your website will always be running the latest version of your code.
What we’ve discussed is a basic deployment system using GitHub. And if you’re wondering about GitLab, it follows the same logic. So, you can apply this approach there too!
Of course, experienced developers might point out that for larger applications, using Jenkins is a better approach. And yes, I agree with that. Jenkins offers more control and is suited for complex deployment needs. However, for simpler scenarios, GitHub Actions does the trick. It’s straightforward, efficient, and works wonderfully for basic deployment tasks.
I hope this article helps you out, and don’t be shy — leave a comment or a suggestion.
I’ve been a PHP developer for over 10 years, so trust me, I’ve heard all kinds of feedback about my coding, and not all of it was a pat on the back. But I’ve learned that every comment matters, even the not-so-nice ones. They’re often the most helpful. So go ahead, let me know what you think!
