Your side-project lab, inside a Docker container

Maybe you have a work laptop that mostly sits on your desk. Maybe it is a university machine, a co-working PC, or just a computer where you are not the admin and sudo is not happening. You still want a proper place to tinker — personal repos, side experiments, that thing you are building on evenings and weekends.

The trick is not to fight the machine. It is to build a little room inside it.

Docker gives you that room: a Ubuntu environment that is yours, portable, and nicely separated from whatever the host already has configured. No mixing up work Git credentials with personal ones. No accidentally pushing to the wrong remote. No wondering whether your SSH key ended up in the wrong ~/.ssh folder.

This guide walks through the whole setup — container, Git, Cursor CLI — with the kind of boundaries that keep work and personal life from bumping into each other.

The idea: two desks, one laptop

Picture two desks in the same room. The host OS is the work desk — Outlook open, company VPN, whatever your employer installed. Your container is the personal desk — your repos, your editor config, your commits.

Good habits that make this pleasant rather than stressful:

Personal Git only inside the container. Work remotes stay on the host; your repos live in /workspace.
Use your own network for personal sync. Phone hotspot, home Wi-Fi, a café — not the office network when you are pushing personal code. Simple rule, zero ambiguity.
A separate browser profile for personal accounts (GitHub, email, docs). Keeps cookies, logins, and bookmarks out of your work browser and vice versa.
Offline by default inside the container. Write code, run tests locally, commit — all without the internet. Go online only when you actually need to pull or push.

None of this is dramatic. It is just being tidy.

Step 1: Make sure Docker is available

On many Linux machines your user can already run Docker:

docker info >/dev/null 2>&1 && echo "docker ok" || echo "no docker access"

If you see docker ok, great. If not, ask whoever manages the machine to add you to the docker group, or check whether rootless Docker is an option. Without Docker (or Podman with a similar workflow), this guide will not get far — but on a lot of dev laptops it already works.

Grab a base image while you have internet (your phone hotspot counts):

docker pull ubuntu:24.04

Step 2: Give yourself a persistent workspace

Containers come and go. Your code should not.

# Named volume — lives in Docker's storage, separate from the host home folder
docker volume create mydev-workspace

# Or a folder on a USB stick if you like something you can unplug and carry
mkdir -p /media/you/usb/mydev

We will use the volume below. USB works the same way — just swap the mount path.

Step 3: Spin up your Ubuntu nook

Start an interactive container with no network by default. This is your quiet writing room:

docker run -it --rm \
  --name mydev \
  --network none \
  -v mydev-workspace:/workspace \
  -w /workspace \
  ubuntu:24.04 \
  bash

You are now inside Ubuntu. The host's Git config, SSH keys, and dotfiles are not in play. --network none means even if the laptop reconnects to Wi-Fi, this shell stays offline until you decide otherwise.

Install the essentials:

apt-get update && apt-get install -y \
  git \
  curl \
  ca-certificates \
  openssh-client \
  build-essential \
  vim \
  less

Pro tip: bake an image at home

If you set this up once on your personal machine, you can skip repeated apt install on the shared laptop. Save a Dockerfile:

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y \
    git curl ca-certificates openssh-client build-essential vim less \
  && rm -rf /var/lib/apt/lists/*
WORKDIR /workspace

# At home
docker build -t mydev:ubuntu .
docker save mydev:ubuntu | gzip > mydev-ubuntu.tar.gz

# On the other machine
docker load < mydev-ubuntu.tar.gz
docker run -it --rm --network none -v mydev-workspace:/workspace -w /workspace mydev:ubuntu bash

Copy the tarball over USB, AirDrop, whatever. Feels very hacker-movie. Is actually just sensible.

Step 4: Git — yours, inside the box

This is the important part. All personal Git identity and credentials live inside the container, full stop.

Who are you (on personal projects)?

git config --global user.name "Your Name"
git config --global user.email "you@personal-email.com"
git config --global init.defaultBranch main

SSH keys

Generate a fresh key inside the container — do not copy your work key in:

ssh-keygen -t ed25519 -C "you@personal-email.com" -f ~/.ssh/id_ed25519 -N ""
cat ~/.ssh/id_ed25519.pub

Add that public key to your personal GitHub from your phone or home laptop. Then wire up SSH:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
cat >> ~/.ssh/config <<'EOF'
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
EOF
chmod 600 ~/.ssh/config
ssh-keyscan github.com >> ~/.ssh/known_hosts 2>/dev/null

Now git clone git@github.com:you/side-project.git uses your identity, stored in the container. The host never needed to know.

Keep config across sessions

Container restarts wipe /root unless you persist it. Mount a home volume:

docker volume create mydev-home

docker run -it --rm \
  --network none \
  -v mydev-workspace:/workspace \
  -v mydev-home:/home/dev \
  -w /workspace \
  mydev:ubuntu \
  bash

Create a non-root user while you are at it — tidier permissions, feels more like a real machine:

useradd -m -s /bin/bash dev
chown -R dev:dev /workspace /home/dev
su - dev

Re-run the Git and SSH setup as dev. Next time you start the container with mydev-home mounted, your keys and config are still there.

Step 5: Network — your hotspot, your rules

When you need to git pull, npm install, or grab a dependency, you go online on purpose.

Practical routine:

Disconnect from office Wi-Fi and VPN on the host. Not because you are doing anything shady — because personal sync should not ride the work network. Use your phone hotspot instead.
Start a container with network for that session only:

docker run -it --rm \
  --name mydev-online \
  -v mydev-workspace:/workspace \
  -v mydev-home:/home/dev \
  -w /workspace \
  mydev:ubuntu \
  su - dev

Do your git push, install packages, whatever you came for.
Exit. Go back to --network none for everyday coding.

Quick sanity check before you sync:

ping -c 2 github.com   # should work on your hotspot
git remote -v          # should show *your* repos, not work ones

When you are done, turn the hotspot off and get back to offline container mode. The laptop goes quiet again. Most of your coding never needed the network anyway — local commits, running tests, refactoring. Sync is a short, deliberate pit stop.

Step 6: Cursor CLI without admin rights

You do not need root to install the Cursor CLI. It lands in your user directory — ~/.local/bin — which is exactly the kind of thing guest access on a shared machine usually allows.

On the host

curl https://cursor.com/install -fsS | bash
export PATH="$HOME/.local/bin:$PATH"

Point it at your workspace volume, or use it to drive agents against repos that live inside Docker. The CLI runs as your normal user; no sudo, no system directories touched.

Or entirely inside the container

Prefer keeping everything in the box?

curl https://cursor.com/install -fsS | bash
export PATH="$HOME/.local/bin:$PATH"

Persist ~/.local on the mydev-home volume and you install once.

"Guest" here just means you are not the machine's admin — you cannot apt install globally, but you can write to your home folder, run Docker, and use user-space tools. That is plenty for a fully functional personal dev setup. Cursor CLI fits right in.

Step 7: The browser situation

Git and code stay in the container. Browsing is separate.

Set up a dedicated browser profile (Firefox containers, Chrome profiles, Brave — pick your fighter) for personal accounts only. Bookmarks, GitHub login, email — all in that profile. Work stuff stays in the work profile.

When you need to copy an SSH key to GitHub, your phone works too. No need to log into personal GitHub in the work browser at all.

Small habit, big clarity.

Step 8: A typical evening session

# Host: office Wi-Fi off, phone hotspot ready (but not connected yet)
# Host: start your offline sandbox
docker start mydev 2>/dev/null || docker run -d --name mydev \
  --network none \
  -v mydev-workspace:/workspace \
  -v mydev-home:/home/dev \
  -w /workspace \
  mydev:ubuntu sleep infinity

docker exec -it mydev su - dev

# Inside: code, commit, no network needed
cd /workspace/side-project
git status
git commit -am "finally fixed the thing"

# When ready to push: exit, hotspot on, start online container, push, done

That is the whole rhythm. Most sessions are offline container time. Network is a five-minute errand.

What you end up with

A portable lab that works the same on any machine with Docker.
Clean separation — work Git on the host, personal Git in the container, personal browsing in its own profile.
No admin required — user-space installs, Docker volumes, container apt.
Sync on your terms — your network, your repos, your schedule.

The point

You are not "hacking" a work laptop. You are being a grown-up about boundaries. The container is just a tidy way to say: this folder, this Git identity, this network — that is mine.

Build your side project. Commit locally over coffee. Push when you are on your hotspot. Close the container. Tomorrow the work desktop looks exactly like you left it, and your personal work is sitting safely in a volume, waiting for the next session.

That is the whole game. Have fun in your little room.