The Solo Coder Workflow: Local Coding, External Repos, and Simple Server Deployments

For years, the default workflow for hobbyists was FTP: drag a file from left to right, refresh the browser, hope nothing broke.

FTP is blind.
It doesn’t know who changed what, it doesn’t remember previous versions, and if your connection drops mid-upload, your site can be left half-updated and broken.

The Solo Coder Workflow replaces that chaos with a simple, professional pipeline:

Your computer → a Git repository → the live server

This workflow works for static sites, web apps, APIs, and everything in between—and it scales cleanly from hobby projects to serious production systems.

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

WSL makes your Windows PC behave like a Linux development machine.

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

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

Step 2: The Central Repository (What Git and GitLab Actually Are)

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

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
• A black box flight recorder for your code

FTP has none of this.

What Is GitLab?

GitLab is a place where your Git repository lives online.

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 is what gives you freedom:

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

Create a free GitLab account and create a new project before continuing.

Step 3: Installing Git (One-Time Setup)

Now that Git and GitLab make sense, install Git on your local machine.

In your Linux or WSL terminal:

sudo apt update && sudo apt install git -y

Step 4: Secure Access (SSH Keys Explained)

Typing passwords every time you push code gets old fast.

An SSH key is a secure digital identity for your machine:

• It proves “this is really you”
• Removes password prompts
• Is standard practice everywhere

Create one:

ssh-keygen -t ed25519 -C "your-email@example.com"

Press Enter through the prompts.

Copy the public key:

cat ~/.ssh/id_ed25519.pub

Paste it into:
GitLab → Preferences → SSH Keys

Your computer is now trusted.

Step 5: Clone the Project (One Time Only)

Copy your project’s SSH clone URL from GitLab.

In your terminal:

git clone git@gitlab.com:your-username/your-project.git

This downloads the project to your computer.

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

Step 6: VS Code (Your Daily Control Panel)

What Is VS Code?

Visual Studio Code is a free, professional code editor by Microsoft.

Why it matters:

• Clean editor
• Excellent PHP, HTML, CSS, JS support
• Git is built in
• No command line required for daily work

Open Your Project

1. Open VS Code
2. Click File → Open Folder
3. Select the folder you just cloned

From now on:

• Edit files in VS Code
• See changes visually
• Commit with buttons
• Push and pull with one click

Git becomes a UI, not a chore.

Step 7: The Live Server (Where Code Actually Runs)

This is the machine that serves your website or app to the world. It can be:

• A cloud VM
• A VPS
• A dedicated server
• A Raspberry Pi
• A home server
• Anything running Linux that hosts your live code

The key rule:

The server runs code. It does not write code.

Give the Server Read-Only Repo Access

SSH into your server and create a key:

ssh-keygen -t ed25519

Copy the public key:

cat ~/.ssh/id_ed25519.pub

Add it to:
GitLab → Settings → Repository → Deploy Keys
Enable Read-Only.

This prevents accidents and enforces discipline.

Step 8: Create a Staging Folder (Not the Live Directory)

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

mkdir ~/app-source
cd ~/app-source
git clone git@gitlab.com:your-username/your-project.git .

This folder (e.g., app-source) holds your clean, versioned source code.

Step 9: The Deployment Script (One Command Publishing)

This script is the bridge between your source code and your live site.
You’ll run it whenever you want to deploy updates.

1. Create the script

nano ~/deploy.sh

2. Paste this script

#!/bin/bash

# ----------------------------
# CONFIG: 
# ----------------------------

# Where your Git repository is cloned on the server
SOURCE_DIR="/home/user/app-source"

# Where your live site is served from
WEB_DIR="/var/www/html"

# Git branch to deploy
BRANCH="main"

# ----------------------------
# DEPLOY
# ----------------------------

echo "Deploying from $SOURCE_DIR to $WEB_DIR"

cd "$SOURCE_DIR" || exit 1

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

# Sync code to the live web directory
# --delete    : remove files deleted from the repo
# --exclude   : protect server-owned files and folders
rsync -av --delete \
    --exclude 'uploads/' \
    "$SOURCE_DIR/" "$WEB_DIR/"

echo "Deployment Complete!"

3. What to edit

• SOURCE_DIR="/home/user/app-source" → The folder where you cloned your Git repo on the server.
• WEB_DIR="/var/www/html" → The folder where your live site is served.
• BRANCH="main" → The branch you want to deploy (e.g., main or master)

4. Protect important files / folders

Some files and folders should never be overwritten during deployment.
Examples:

• uploads/ → user uploads
• .env → environment secrets
• cache/ or storage/ → runtime data or logs

These can be protected by the --exclude option.

5. How to add more exclusions

Simply add extra --exclude lines in the rsync command. Example:

rsync -av --delete \
    --exclude 'uploads/' \
    --exclude 'cache/' \
    --exclude 'storage/' \
    "$SOURCE_DIR/" "$WEB_DIR/"

Rules of thumb:

• Exclude anything created on the server (uploads, cache, logs)
• Exclude folders not in Git that the server owns

You can add as many as needed as your project grows.

6. Make the script executable

chmod +x ~/deploy.sh

7. Deploy

Run the script whenever you want to publish:

./deploy.sh

Key points to remember:

• --delete is safe: anything deleted in Git is removed on the server, but excluded files remain untouched.
• You can edit the exclude list anytime as your app grows.
• Think of the script as a repeatable, safe pipeline: Git manages code, the server keeps data.

The Daily Workflow (The Coder’s Routine)

1. Sync
   In VS Code, click Pull / Sync before starting work.
2. Save
   • Write code
   • Review changes
   • Commit
   • Push
     All from the VS Code UI.
3. Deploy

ssh root@your-server-ip
./deploy.sh

Why This Beats FTP

No Ghost Files: The server mirrors the repo exactly.
No Fear: Every change has history.
Total Freedom: Any computer can be your workstation.
Boring Deployments: Which is exactly what you want.

This is how solo developers work like professionals—without complexity, without panic, and without FTP.