Concept · DevOps basics

Deploying code from your laptop
to the server.

One line. One command. The whole "DevOps" of a small trading setup, explained the slow way.

What you'll learn: how one SSH command deploys code

Pre-req: you know what git push does

The mental model

Imagine you write recipes at home.

You want a restaurant in another city to cook the same dishes. You don't fly there every time you tweak a recipe — you drop the updated recipe at the post office, and the restaurant picks up its mail.

🧑‍🍳

YOU (Laptop)

You write and edit the recipes here.

→git push

📮

POST OFFICE (GitHub)

Holds the latest version. Both sides can reach it.

→git pull

🍽️

RESTAURANT (Server)

Cooks the dish using whatever recipe it last picked up.

The whole one-line command — ssh lightsail 'cd ~/ExecutionProject && git pull --ff-only' — in plain English:
"Hey restaurant, go check your mailbox for new recipes."

You're not sending the recipe through this command. You're telling the restaurant to fetch it.

Anatomy

Four pieces, one line.

ssh lightsail 'cd ~/ExecutionProject && git pull --ff-only'

1ssh

"Open a phone line to another computer."

2lightsail

Whose computer. Not the address — just a nickname your laptop remembers. Like saving "Mom" in your phone instead of memorising her number.

3'cd ~/ExecutionProject'

The first thing to do once connected: walk into the project folder. Like the restaurant manager walking to the kitchen.

4'git pull --ff-only'

The actual job: download new code from GitHub.

The && between #3 and #4 just means "do this, and if it works, do that next."

In one breath: "Phone the restaurant, walk to the kitchen, check the mailbox for new recipes."

The safety flag

Why `--ff-only`? (the "no surprises" flag)

Picture this: you have a recipe book at home, the restaurant has the same recipe book. You both add page 50. Different page 50s. Now what?

Without `--ff-only`

Git tries to glue both versions together. Usually messy, sometimes silently wrong. You don't notice until someone cooks the wrong dish — i.e., a trade goes wrong three days later.

With `--ff-only`

Git refuses. It says "wait — the books don't match, I'm not going to guess." You see the error immediately and decide what to do.

Rule of thumb: loud failure is a feature, not a bug. You always want to know now if something's weird — not three days later, when real money is on the line.

Setup · do this once

Three things had to be true — each is one-time.

1

Save the server as a contact

On your laptop, file ~/.ssh/config stores the nickname → address mapping. This is your phone's contact list.

Host lightsail HostName 13.202.219.68 User ubuntu IdentityFile ~/.ssh/lightsail-trading

Without this: every command is ssh -i ~/.ssh/lightsail-trading ubuntu@13.202.219.68 '...'. Like dialling the full number every time.

2

Give the restaurant the recipe book

On the server, day one only:

git clone https://github.com/.git ~/ExecutionProject

After this, the server folder knows which GitHub repo it belongs to. Every future git pull just refreshes from that same source.

3

Give the restaurant a mailbox key

The server needs permission to read from GitHub — either the repo is public, or a "deploy key" / token is set up.

If git pull ever asks for a password — this step is missing.

Set up once. Reuse forever. That's the whole bargain of "infrastructure" — pay an hour now to save five minutes every day.

Setup deep-dive · #1 of 2

The lock and the key.

SSH security works like a fancy lock-and-key set. The private key stays on your laptop — never share it. The public key is the lock — paste it on as many servers as you want. Stolen public key = harmless. Leaked private key = disaster.

🔑

PRIVATE KEY

~/.ssh/lightsail-trading
stays on your laptop. Never share.

↔must match

🔒

PUBLIC KEY (the lock)

lightsail-trading.pub
installed on the server. Safe to share.

on your laptop · one-time

# 1. Make the key pair
$ ssh-keygen -t ed25519 -f ~/.ssh/lightsail-trading
    Creates two files: the private key, and ".pub" — the lock.

# 2. Put the lock on the server
$ ssh-copy-id -i ~/.ssh/lightsail-trading.pub ubuntu@13.202.219.68
    (Or paste it into the Lightsail console when creating the instance.)

# 3. Save the server as a contact — edit ~/.ssh/config
Host lightsail
    HostName 13.202.219.68
    User ubuntu
    IdentityFile ~/.ssh/lightsail-trading

# 4. Lock down the private key (mandatory)
$ chmod 600 ~/.ssh/lightsail-trading
    SSH refuses to use a private key that others on the laptop can read.

# 5. Test it
$ ssh lightsail
    → If it logs you in without asking for a password, the lock and key are working.

Setup deep-dive · #2 of 2

Connecting the restaurant to the post office.

The server can now let you in. But the server itself still can't read from GitHub. The server needs its own key — a different identity from you — registered with GitHub.

🍽️

SERVER

Generates its own SSH key pair.

→register public key

📮

GITHUB

Repo Settings → Deploy keys → Add.
Read-only is enough.

on the server · one-time

# 1. SSH into the server (everything below runs there, not your laptop)
$ ssh lightsail

# 2. Make a key pair *for the server*
$ ssh-keygen -t ed25519 -C "lightsail-trading"
    Press Enter through prompts to accept defaults.

# 3. Show the server's public key — copy the whole output
$ cat ~/.ssh/id_ed25519.pub
    ssh-ed25519 AAAAC3Nz... lightsail-trading

# 4. In your BROWSER:
    GitHub repo → Settings → Deploy keys → Add deploy key
    Title: "Lightsail trading server"
    Key:   (paste the output from step 3)
    Allow write access: ☐ leave unchecked (server only needs to read)
    → Add key

# 5. Clone the repo (note the git@github.com: prefix — that uses the key)
$ git clone git@github.com:your-user/your-repo.git ~/ExecutionProject

# 6. Test it
$ cd ~/ExecutionProject && git pull
    → "Already up to date." with no password prompt = live connection.

From this point on, every future git pull — including the one-line deploy from your laptop — just works.

The full deploy ritual

Every time you want code on the server.

deploy-flow

# 1. ON YOUR LAPTOP — save the change locally
$ git add .
$ git commit -m "what you changed"

# 2. SEND IT TO THE POST OFFICE (GitHub)
$ git push

# 3. TELL THE RESTAURANT TO CHECK ITS MAIL
$ ssh lightsail 'cd ~/ExecutionProject && git pull --ff-only'

# 4. (Only if you changed requirements.txt — new ingredients)
$ ssh lightsail 'cd ~/ExecutionProject && source venv/bin/activate && pip install -r requirements.txt'

# 5. Restart whatever is running, so it picks up the new code

Skipping step 2 is the most common mistake. The restaurant checks its mail, finds nothing new, and you wonder why nothing changed.

Troubleshooting

Three things that will go wrong.

And what they actually mean.

"Already up to date." …but my change isn't there.

You forgot git push. The server pulls from GitHub, not your laptop. If the post office never got the letter, the restaurant can't pick it up.

Permission denied (publickey).

The key file's permissions are wrong. Run chmod 600 ~/.ssh/lightsail-trading. That tells the OS "this key is private to me." SSH refuses to use keys other people on your computer could read.

fatal: Not possible to fast-forward, aborting.

Someone changed files directly on the server, so the books don't match. Don't force it — SSH in, run git status, look at what's different, decide whether to keep or throw away those changes.

Lesson · takeaway

One line. Code on a server
in Mumbai.

You don't need to log in, look around, and type commands one at a time. Once the plumbing is set up, a single line from your laptop deploys code to a machine running in a data centre on the other side of the city.

The magic isn't in the command. The magic is the one-time setup — the saved contact, the cloned repo, the mailbox key — that turns a long process into a single line.

Most "infrastructure" work is exactly this: spend an hour once, save five minutes a day, forever.