FTP isn’t a workflow.

It doesn’t know who changed what. It has no memory of previous versions. It’s blind, manual, and prone to breaking mid-upload. If you’re still dragging files into a folder to “deploy”—or worse, manually creating site-backup-v2-final-actual-FINAL.zip before every change—you’re working harder than you need to.

Enter The Solo Developer Workflow.

In this guide, we’re building a professional pipeline: Local → Git → Server. No more “ghost files,” no more zip-file hoarding, and no more deployment anxiety. Just a clean, versioned, and automated path to production.

Step 1: Your Local System (Where Code Is Written)

This is where all development happens.

If You’re on Linux

If your computer already runs Linux (Ubuntu, Fedora, Arch, etc.), you’re set. Your terminal is already a professional-grade tool.

If You’re on Windows: What Is WSL?

WSL (Windows Subsystem for Linux) is a free, built-in Windows feature created by Microsoft. It lets you run a real Linux environment inside Windows, without virtual machines or dual booting.

Why this matters:

  • Web servers run on Linux
  • Deployment tools expect Linux
  • Tutorials assume Linux paths and commands

Install WSL

  1. Search for PowerShell.
  2. Right-click → Run as Administrator.
  3. Run: wsl --install
  4. Reboot.
  5. Open the new Ubuntu app from the Start menu.

Note: From now on, when this guide says “terminal,” it means this Ubuntu window.

Step 2: The Central Repository (Git & GitLab)

Before installing anything, it’s important to understand the concept.

What Is Git?

Git is a version control system. In plain English:

  • It records snapshots of your project over time.
  • Each snapshot has a name (“commit message”).
  • You can see history, undo mistakes, and compare changes.

Think of Git as a save system, a timeline, and a black box flight recorder for your code. FTP has none of this.

What Is GitLab?

GitLab is the online home for your Git repository. It acts as:

  • The single source of truth.
  • The meeting point between all your computers.
  • The place your server pulls code from.

Your laptop, desktop, and server never talk directly to each other; they all talk to GitLab. This gives you freedom:

  • New computer? Clone the repo.
  • Multiple machines? Stay in sync.
  • Deployment? Pull from one trusted place.

Action: Create a free GitLab account and a new project before continuing.

Step 3: Installing Git (One-Time Setup)

In your Linux or WSL terminal, run:

sudo apt update && sudo apt install git -y

Step 4: Secure Access (SSH Keys)

Typing passwords every time you push code gets old fast. An SSH key is a secure digital identity:

  1. Create one: ssh-keygen -t ed25519 -C "[email protected]" (Press Enter through the prompts).
  2. Copy the public key: cat ~/.ssh/id_ed25519.pub
  3. Paste it into: GitLab → Preferences → SSH Keys.

Step 5: Clone the Project (One Time Only)

Copy your project’s SSH clone URL from GitLab. In your terminal:

git clone [email protected]:your-username/your-project.git

For most beginners, this is the last Git command you ever need to type manually.

Step 6: VS Code (Your Daily Control Panel)

Visual Studio Code is a free code editor where Git is built-in.

  1. Open VS Code.
  2. Click File → Open Folder and select your cloned folder.
  3. The Benefit: Edit files, see changes visually, and commit/push/pull using buttons instead of the command line.

Step 7: The Live Server

The server runs code; it does not write code. To give it access:

  1. SSH into your server and run: ssh-keygen -t ed25519
  2. Copy the key: cat ~/.ssh/id_ed25519.pub
  3. Add it to: GitLab → Settings → Repository → Deploy Keys (Enable Read-Only).

Step 8: Create a Staging Folder

Never deploy directly into your web directory (e.g., /var/www/html).

mkdir ~/app-source
cd ~/app-source
git clone [email protected]:your-username/your-project.git .

Step 9: The Deployment Script

This script is the bridge between your source code and your live site.

1. Create the script

nano ~/deploy.sh

2. Paste the configuration

#!/bin/bash

# CONFIG
SOURCE_DIR="/home/user/app-source"
WEB_DIR="/var/www/html"
BRANCH="main"

echo "Deploying from $SOURCE_DIR to $WEB_DIR"
cd "$SOURCE_DIR" || exit 1

# Pull the latest code
git pull origin "$BRANCH"

# Sync code to the live web directory
# --delete  : remove files deleted from the repo
# --exclude : protect server-owned files (uploads, .env, etc)
rsync -av --delete \
    --exclude 'uploads/' \
    --exclude '.env' \
    --exclude 'cache/' \
    "$SOURCE_DIR/" "$WEB_DIR/"

echo "Deployment Complete!"

3. Make it executable and run

chmod +x ~/deploy.sh
./deploy.sh

The Daily Workflow

  1. Sync: In VS Code, click Pull/Sync before starting.
  2. Save: Write code and review changes.
  3. Commit/Push: Use the VS Code UI to save your progress to GitLab.
  4. Deploy: SSH into your server and run ./deploy.sh.

Why This Beats FTP

  • No Ghost Files: The server mirrors the repo exactly.
  • No Fear: Every change has a history.
  • Boring Deployments: Which is exactly what you want.
  • Are you still using FTP/SCP or manually ZIP’ing up backups?
  • If you’ve moved to Git, do you do anything differently?