Why CI/CD Matters (and Why Most Developers Skip It)
If you're shipping side projects or small production apps, you've probably felt the friction: merge code, SSH into your server, run tests, build, deploy, pray nothing breaks. Repeat fifty times a week.
CI/CD pipelines automate that grind. But setting them up feels like a chore — shell scripts, config files, environment variables scattered everywhere. Most solo developers and small teams don't bother, which means they're debugging in production and shipping slower than they could.
The good news: with an AI pair programmer in a managed Linux VPS environment, you can scaffold a working pipeline in an afternoon instead of spending a weekend reading documentation.
What You'll Build: A Practical CI/CD Setup
By the end of this post, you'll have:
- A GitHub Actions workflow (or GitLab CI, or similar) that runs on every push
- Automated tests, linting, and build steps
- A deployment script that pushes code to your Linux server without manual SSH
- Rollback capability if something goes wrong
You won't need a DevOps engineer or a complex enterprise tool. Just your AI agent, a VPS, and a few hours of focused work.
Step 1: Choose Your CI/CD Trigger Point
First, decide where your pipeline lives. The two most common setups for developers using managed Linux VPS hosting:
Option A: GitHub Actions (Recommended for Most)
GitHub Actions runs on GitHub's infrastructure, free for public repos and generous for private ones. Your workflow file sits in `.github/workflows/` and triggers on push, pull request, or schedule.
Pros: No extra infrastructure, integrated with GitHub, easy to debug.
Cons: Less control over the runner environment; secrets management requires GitHub Secrets.
Option B: Self-Hosted Runner on Your VPS
You run a GitHub Actions runner (or equivalent) directly on your Linux server. Workflows execute there instead of on GitHub's hardware.
Pros: Full control, can access local services, no egress costs.
Cons: You manage the runner; it needs to stay online.
For this post, we'll focus on GitHub Actions because it's the path of least resistance, but the principles apply to any CI/CD system.
Step 2: Define Your Workflow File
Create `.github/workflows/deploy.yml` in your repo. Here's a skeleton for a Node.js app:
name: Build and Deploy
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '18'
- run: npm ci
- run: npm run lint
- run: npm run test
- run: npm run build
- name: Deploy
run: |
mkdir -p ~/.ssh
echo "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
chmod 600 ~/.ssh/id_ed25519
ssh-keyscan -H ${{ secrets.SERVER_HOST }} >> ~/.ssh/known_hosts
scp -r ./dist/ deploy@${{ secrets.SERVER_HOST }}:/tmp/app-new/
ssh deploy@${{ secrets.SERVER_HOST }} 'cd /tmp/app-new && ./deploy.sh'
This workflow:
- Checks out your code
- Sets up Node.js
- Installs dependencies, lints, tests, and builds
- Copies the build output to your server via SCP
- Runs a deploy script on the server
The tricky part is the SSH key and server details — we'll handle that next.
Step 3: Set Up Secrets and SSH Access
Your GitHub Actions workflow needs to SSH into your VPS without you pasting credentials into the config file. Use GitHub Secrets:
- Go to your repo → Settings → Secrets and Variables → Actions
- Click "New repository secret"
- Add three secrets:
SERVER_HOST— your VPS domain or IP (e.g.,api.example.com)DEPLOY_KEY— a private SSH key (ed25519, no passphrase)DEPLOY_USER— the SSH user (e.g.,deploy)
On your VPS, create a deploy user and add the corresponding public key to ~deploy/.ssh/authorized_keys:
sudo useradd -m -s /bin/bash deploy
sudo mkdir -p /home/deploy/.ssh
sudo echo "ssh-ed25519 AAAA..." >> /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
Now GitHub Actions can SSH into your server without storing plaintext passwords.
Step 4: Write Your Deploy Script
On your VPS, create `/home/deploy/deploy.sh` (or wherever you want it):
#!/bin/bash
set -e
APP_DIR="/var/www/myapp"
BACKUP_DIR="/var/www/myapp-backup-$(date +%s)"
echo "[$(date)] Starting deployment..."
# Backup current version
if [ -d "$APP_DIR" ]; then
cp -r "$APP_DIR" "$BACKUP_DIR"
echo "[$(date)] Backed up to $BACKUP_DIR"
fi
# Move new code into place
mv /tmp/app-new/dist/* "$APP_DIR/"
echo "[$(date)] Code deployed."
# Restart app (systemd, PM2, Docker, etc.)
sudo systemctl restart myapp
echo "[$(date)] App restarted."
# Health check
sleep 2
if curl -f http://localhost:3000/health > /dev/null; then
echo "[$(date)] Health check passed. Deployment successful."
# Clean up old backups
find /var/www -name "myapp-backup-*" -mtime +7 -exec rm -rf {} \;
else
echo "[$(date)] Health check failed. Rolling back..."
cp -r "$BACKUP_DIR/" "$APP_DIR/"
sudo systemctl restart myapp
exit 1
fi
This script backs up the current version, deploys the new code, restarts your app, and rolls back if the health check fails. Simple but effective.
Step 5: Use Your AI Agent to Refine and Test
This is where Vibesies's approach shines. Instead of debugging shell scripts in production, paste your workflow file and deploy script into Claude Code or Codex running in your VPS. Ask it to:
- "Add better error handling to the deploy script"
- "Add a pre-deployment smoke test that checks the API"
- "Generate a rollback workflow for manual use"
- "Add Slack notifications on success/failure"
Your AI pair programmer can iterate on these scripts in seconds, test them locally in your sandbox, and hand you production-ready code. No guessing, no syntax errors in production.
Step 6: Handle Common Gotchas
Timeouts
If your build takes longer than GitHub's default timeout, add a timeout to your job:
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 30
Secrets in Logs
GitHub automatically masks secrets in logs, but be careful not to echo them or save them to artifacts.
Database Migrations
If your deploy runs migrations, add a pre-flight check:
ssh deploy@${{ secrets.SERVER_HOST }} 'cd /var/www/myapp && npm run migrate:check'
Only proceed if migrations are safe.
Environment Variables
Store app secrets (database passwords, API keys) in a `.env` file on your VPS, not in GitHub. Your deploy script can source it before starting the app.
Step 7: Monitor and Iterate
Once your pipeline is live, watch it run a few times. Check:
- Do tests pass consistently?
- Does the deploy take longer than expected?
- Are there any flaky tests?
- Do you need to add logging or notifications?
Ask your AI agent to add Slack or email notifications to your workflow. It takes two minutes, and you'll never miss a failed deployment again.
Why This Matters for Website Development Hosting
A lot of developers choose website hosting for developers based on features alone — SSH access, root control, Linux VPS support. But the real win is automation. When your hosting lets you run arbitrary code (like a deploy script or a CI/CD runner), you're no longer manually shipping features. You're shipping infrastructure that ships features for you.
Managed Linux VPS hosting like Vibesies pairs well with CI/CD because your AI agent can live in the same environment where your code runs. No context switching, no separate runner infrastructure. Your agent writes the pipeline, tests it locally, and hands you a working setup.
Next Steps
Start small: get a basic GitHub Actions workflow running that just builds and tests your code. Once that's solid, add the deploy step. Then add notifications, rollbacks, and health checks.
If you're managing this alone, let your AI pair programmer do the heavy lifting. It's faster than reading docs, and you'll learn more by seeing the code work than by copying examples from tutorials.
The goal isn't perfection on day one. It's shipping faster and sleeping better, knowing your deployments are automated, tested, and reversible.
