Archive / Vps
To deploy CI/CD on a VPS, you set up a server-side automation runner—like GitHub Actions' self-hosted runner—directly on your virtual server, which then executes your pipeline scripts to test, build, and deploy code from your repository to the same machine or a staging environment.
Cloud-based CI/CD services (like GitHub-hosted runners) are simple but bill per minute and can't directly access your VPS's databases or file system. Running the runner on your own VPS consolidates costs, gives you full control over the execution environment, and allows direct file operations. This is ideal for deploying to the same server. You trade this for managing the runner's uptime and security yourself.
A common approach is using GitHub Actions' self-hosted runner. The process is similar for GitLab CI or Jenkins.
.github/workflows/deploy.yml file. Configure the job to use your self-hosted runner by setting runs-on: self-hosted or a matching label.Note
For a stable foundation, consider a KVM VPS with SSD storage. KVM virtualization ensures isolated resources, which leads to more consistent runner performance than oversold OpenVZ containers.
This basic GitHub Actions workflow runs on a self-hosted VPS runner to test and deploy a Node.js API.
name: Deploy to VPS
on:
push:
branches: [ main ]
jobs:
test-and-deploy:
runs-on: self-hosted
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
- name: Deploy application
run: |
pm2 stop my-api || true
pm2 start server.js --name my-apiThis pipeline triggers on a push to main. The runner checks out the code, installs Node.js and dependencies, runs the test suite, and if tests pass, uses PM2 to restart the application. All steps execute directly on your VPS.
Running a CI/CD service on your server introduces new considerations.
github-runner) with only the necessary sudo privileges for deployment commands.htop to monitor usage, which is important on smaller VPS plans.Setting up CI/CD on your VPS turns it into an automated deployment hub. The initial setup requires command-line work, but the payoff is a fast, private, and cost-controlled pipeline. For projects that have outgrown shared hosting, a Hostinger VPS provides a straightforward platform to host both your application and its automation engine.
Yes, you can run a CI/CD runner on an entry-level VPS. The runner itself is lightweight. Performance limits come from your pipeline's tasks (e.g., running complex test suites or building large applications). For simple web apps or scripts, a plan with 1 vCPU and 1GB RAM is often sufficient.
A cloud runner is a temporary, managed virtual machine provided by a service like GitHub. A self-hosted runner is software you install on your own server (like a VPS). The self-hosted runner gives you a persistent environment, direct server access, and no per-minute fees, but you are responsible for its maintenance and security.
For WordPress, your CI/CD pipeline on a VPS can use WP-CLI commands. A typical workflow would: 1) Check out your theme/plugin code, 2) Run PHP CodeSniffer tests, 3) Use SCP or rsync over SSH to copy files to your VPS's web directory, and 4) Execute WP-CLI commands to update the database. You'd store your SSH credentials and database details as secrets in your CI platform.
It's common but adds risk. The runner has access to your production environment. For better safety, use a separate staging VPS for the runner and deployments, then sync to production after verification. At a minimum, strictly limit the runner user's file permissions and never expose secrets in logs.
Affiliate disclosure: If you buy through our links, we may earn a commission at no extra cost to you.
Ready to get started? Check out Hostinger's plans.