In this article I’m going to show you exactly how to deploy your WordPress site from Gitlab for FREE! Yes that’s free — no more paying for deployments if you’re a solo dev. We’re going to get a bit technical here, so if a lot of tech speak creeps you out, you may want to hire a developer to do this for you. I’ll do my best to define everything though, so hang in there.
It’s important to distinguish Gitlab.com from a self-hosted Gitlab instance in this article. The reason is if you’re self-hosting your own GitLab instance, you’ll need to set up a runner yourself and this article will not cover that. However, I’ve linked the article on the official site above for your viewing if need be.
In this article, you’re going to see a ton of tech speak, ( or hear, if you talk to yourself like me ). If you don’t need all this lingo, feel free to jump to the Getting Started section. So here’s some common lingo included in this post:
- CI – Continuous Integration – the act of merging code/assets to an environment multiple times a day and ensuring they integrate properly
- CD – Continuous Deployment – the act of deploying code/assets to an environment multiple times a day ( for the purpose of my sanity I call everything CI, it’s a bad habit and you may see that in this article )
- Encryption – Basically changing readable data to garbage which can only be read by those who hold the key or used to verify something.
- Job – A task that runs within the CI/CD environment.
- Local – Your local machine in front of you currently.
- Pipeline – Basically a file cabinet for a set of jobs.
- Prod – Short for production, the ‘live’ site if you will
- RSA – An encryption technique
- SSH – Secure Shell – Think of it as a remote command line.
( scary to some, but stay with me )
- Staging – Where you test your code, usually a mirror copy of production.
Alright, now we’re over all that mumbo jumbo, time to get to the juicy bits. Deploying for free does not come without some gotchas, work, and specific requirements. You didn’t think it was going to be “hit a button and it’s done” did you? *insert creepy laugh here* I promise I’ll try to make it as easy as possible.
One major gotcha here is the 2,000 limit of CI time per month. Depending on the size of your project or the amount of build time you need, this may not be suitable for non-freelancers. However, the technique listed in this article can be used across all packages.
- A text editor.
- The ability to create an RSA or ED25519 ( if your host supports it ) key
- A host which supports rsync ( I use a cheap SiteGround site, $3.95 a month is great to start with, scale from there )
- “OH NO… my host doesn’t support rsync” – I can hear this now in my head… well if that’s the case, give this post a like and/or comment telling me just how bad you want to know how to do FTP from GitLab, I can show you that too.
- “Why not use FTP in the first place” – well, rsync was simply faster, and my host supports it.
Generate an SSH key set for GitLab
In order to push code to your host via rsync, you’ll need to create a private and public key. Making sure to not overwrite your own id_rsa if you already have one.
For me, on a Mac, the command is as follows:
ssh-keygen -o -t rsa -b 4096 -C "firstname.lastname@example.org" -f ~/.ssh/deploy_rsa
This will create a mine_rsa and mine_rsa.pub in your user directory right under the .ssh directory. Now the -f flag is optional as it’s entirely up to you where you want to store these keys. I find it helpful to keep them in a single location.
- -o – This flag uses a different method for encoding the key, in a more secure fashion
- -t specifies the method to use, in this case, rsa which for me is compatible with SiteGround
- -b sets the encoding length, in this case 4096 bytes, double the standard of 2048
- -C adds a comment to the generated set, making it easy to remember who the key is actually for. For myself, I use something like email@example.com for GitLab to make it more obvious what the key is for.
- -f – specifies where you want to save the generated files, you can omit this if you want the files generated in your current directory you’re in. For the sake of this how-to we’ll call the file deploy_rsa from here out.
Once you run this command the ssh-keygen application will ask you for a passphrase – for the purpose of this how-to, just hit enter and do not enter a passphrase for this key set.
On to Page 2 below, let’s keep going.