DEV Community: Marek

The Right Way to Deploy Private GitHub Repos to Your VPS

Marek — Fri, 23 Jan 2026 18:20:00 +0000

Deploying code from a private repository to a VPS is something a lot of developers sort of know how to do — but most tutorials either rely on personal SSH keys or Personal Access Tokens. That works, but it gives your server much more access than it actually needs.

In this guide you’ll learn how to set up a repository-specific SSH deploy key for your VPS so you can:

Clone your private repository securely
Pull updates without storing personal credentials on the server
Keep production access scoped narrowly and safely

This method is slightly more advanced than a basic SSH clone, but it’s well worth it if you care about security and clean operations.

What you'll learn:

How to create repository-specific SSH deploy keys,
Why deploy keys are more secure than personal credentials,
How to configure SSH for multiple GitHub identities,
The right way to structure your deployment directory,
How to maintain and rotate deploy keys safely

Time required: ~10–20 minutes
Skill level: Beginner to intermediate (comfortable with SSH and basic Linux)
What you'll need: SSH access to your VPS with sudo privileges and administrator access to your GitHub repository
Prerequisites note: This tutorial assumes you have SSH access to your server. If you haven't set up your firewall yet, I recommend checking out my guide on securing SSH with UFW first.

Why This Matters
There are several ways to authenticate to GitHub from a server:

Using your personal SSH key (this is risky, because it ties the server to your personal account )
Using a Personal Access Token (it works, but provides overly broad access )
Using a Repository-Specific Deploy Key (it’s ideal because it provides scoped access)

Deploy keys follow the principle of least privilege: the server gets just enough access to pull the code it needs, no more.

Step 1 — Prepare Your Deployment Environment
First create a dedicated deployment user.
Rather than cloning as root or your own account, it’s better to use a dedicated user and by dedicated user, I mean a Linux system user created specifically to run and deploy a single application or repository — not a human login account. From my experience it is a good idea to use a name of the app/repository you’re going to deploy.

sudo adduser --system --group yourappname
sudo mkdir -p /opt/yourappname
sudo chown yourappname:www-data /opt/yourappname

This ensures:

Deployment files are owned by a service user
Permissions stay clear and restricted

Why /opt and not /home, /srv, or somewhere else?
TL;DR: /opt makes it immediately obvious what is system-owned and what you deployed yourself.

In Linux, different top-level directories have different intentions. Using the right one is about keeping your server understandable six months from now.

What /opt actually is
/opt stands for optional software.

Historically (and still today), it’s meant for:

software not managed by the OS package manager
applications you deploy yourself
self-contained services that live outside the base system That describes a manually deployed web application perfectly.

Why /opt is a good fit for deployed applications
Putting your application in /opt/yourappname has several advantages:

a. Clear separation from the operating system
Your app is not part of the OS.

/bin, /usr, /lib → operating system
/opt → things you added

That means:

OS upgrades won’t touch your app
you won’t accidentally overwrite system files
backups and restores are simpler

b. Clear separation from user home directories
Using /home for production apps is tempting, but misleading.
Home directories are meant for:

human users
shell config
personal files A deployment user is not a human.

By using /opt:

there’s no expectation of interactive usage
no confusion about “who owns what”
no accidental exposure via home-directory defaults

c. Predictable layout for multi-app servers
If you later deploy more applications, /opt scales cleanly:
/opt/
├── yourappname/
├── anotherapp-1/
├── anotherapp-2/

Each app:

has its own directory
has its own system user
can have its own service, ports, and permissions

This makes:

audits easier
troubleshooting faster
future automation simpler

d. Works well with permissions and service users
The combination /opt/yourappname owned by yourappname:www-data means:

the deploy user controls the code
the web server can read what it needs
root is not involved in daily operations

That’s exactly what you want on a production server.

Why not /srv?
You could use /srv, and some people do.
However:

/srv is traditionally used for data served directly (FTP, NFS, static web roots)
many distros barely use it in practice
fewer people recognize it instantly and /opt is more universally understood for application installs.

The key idea
The goal is to make it obvious what is system, what is application, and who owns it.
Using /opt helps you do exactly that.

Step 2 — Generate a Repository-Specific SSH Deploy Key

Switch to the deployment user:
sudo su - yourappname
Generate a new SSH key specifically for this repo:
ssh-keygen -t ed25519 -C "github-deploy-key-yourappname" -f ~/.ssh/id_ed25519_deploy_yourappname

What this does: Creates a modern ed25519 key (more secure than RSA) with a descriptive comment and a specific filename so it doesn't conflict with other keys.

When prompted for a passphrase, you can leave it empty for automated deployments — security comes from strict file permissions and the key being limited to a single repository.

Display the public key:
cat ~/.ssh/id_ed25519_deploy_yourappname.pub
Expected output: You should see something starting with ssh-ed25519 AAAA... followed by your comment.

Copy this entire output — you'll paste it into GitHub next.

Step 3 — Register the Deploy Key on GitHub

Open your repository on GitHub
Go to Settings → Deploy keys
Click Add deploy key
Paste the public key you generated
Give it a sensible title, e.g., “VPS Deploy Key”
Do NOT enable write access — this key should be read-only

This gives your VPS the ability to read (clone/pull) this repository only.

Step 4 — Configure SSH on the Server
On the yourappname user, create or edit the SSH config:

nano ~/.ssh/config
Add:

Host github-deploy
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_deploy_yourappname
    IdentitiesOnly yes

This tells SSH to use the correct key just for this host alias.
Test it:
ssh -T github-deploy
If it says you’ve successfully authenticated (but can’t shell), you’re good.

Step 5 — Clone the Repository
If you’re not logged in as the deployment user, switch to it first using sudo su - yourappname.
As the deployment user:

cd /opt/yourappname
git clone git@github-deploy:yourusername/yourappname.git

That command uses the custom github-deploy host alias — so Git uses the specific deploy key.

Step 6 — Verify Permissions and Security
Make sure the .ssh directory is locked down:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_deploy_yourappname
chmod 644 ~/.ssh/id_ed25519_deploy_yourappname.pub
chmod 600 ~/.ssh/config

Now:
ls -la ~/.ssh/
You should see just the expected key, config, and correct permissions.

Step 7 — Pulling Updates Later
When you need to update the app:

sudo su - yourappname
cd /opt/yourappname
git pull origin main

No passwords, no tokens — just the deploy key doing its job.

If you have a systemd service (e.g., Gunicorn – I’ll cover it in the next blog article), restart it after the pull:
sudo systemctl restart yourappname

Step 8 — Key Rotation and Maintenance
Over time, you may want to:

Rotate the deploy key (generate a new one and update GitHub)
Revoke older deploy keys from GitHub
Monitor your repository’s key list for unused entries Because this key is repo-specific, revoking it only affects this deployment — not your entire GitHub account.

Common Pitfalls & Quick Checks
Wrong remote URL?
Make sure the Git remote uses your custom host:
git remote -v
It should show:

origin git@github-deploy:yourusername/yourappname.git (fetch) 
origin git@github-deploy:yourusername/yourappname.git (push)

Should NOT show: git@github.com (this would use the wrong key)

SSH connection issues?
Run verbose SSH to debug:
ssh -vT github-deploy
What this command does:
-v → Verbose output — Shows what SSH is doing step by step: which key it tries, which config entry it uses, where authentication fails
-T → Disable pseudo-terminal allocation — Tells SSH "Don't try to open a shell, just test authentication"
This is important for GitHub because GitHub does not provide shell access. A successful connection will still exit immediately, but with a clear authentication message.

Successful output looks like:
Hi yourusername/yourappname! You've successfully authenticated, but GitHub does not provide shell access.

When to use this command:

SSH works locally but fails on the server
Git can't clone or pull
You suspect the wrong SSH key is being used
You want to confirm which identity file is selected

Common error messages and fixes
Permission denied (publickey) — The deploy key isn't registered on GitHub, or SSH is using the wrong key
Could not resolve hostname github-deploy — The SSH config file has a typo or wasn't saved properly
Host key verification failed — You need to accept GitHub's host key: run ssh-keyscan github.com >> ~/.ssh/known_hosts

Permission problems?
If you see "Permission denied" when trying to clone check file permissions:
ls -la ~/.ssh/

It should show:

drwx------  (700) for .ssh directory
-rw-------  (600) for private keys
-rw-r--r--  (644) for public keys
-rw-------  (600) for config file

If permissions are wrong, fix them:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_deploy_yourappname
chmod 644 ~/.ssh/id_ed25519_deploy_yourappname.pub
chmod 600 ~/.ssh/config

Wrapping Up
Using a repository-specific deploy key gives you a clean, secure way to pull private code onto a server without exposing broad access credentials. It's the professional default for small VPS deployments before you add CI/CD or automation.
The principle is simple: give each server exactly the access it needs, nothing more. If this deploy key is ever compromised, you can revoke it on GitHub without affecting your other repositories or your personal access.

Have you ever accidentally exposed credentials on a server? What's your preferred method for managing deploy access? Do you use deploy keys, CI/CD pipelines, or something else? Let me know in the comments!

If you found this helpful, you might also want to check out the other articles in this series:

Part 1: Don't Lock Yourself Out - Enabling UFW

Don’t Lock Yourself Out: Enabling UFW on a Linux Server Without Breaking SSH

Marek — Wed, 21 Jan 2026 20:27:57 +0000

Setting up a firewall on your Linux server is essential for security — but one wrong move can lock you out of your own server via SSH. It happens more often than you'd think, and recovering from it can be frustrating (or expensive if you need to contact support).

If you do get locked out, most VPS providers offer a web console or rescue mode — but relying on that is slower and avoidable.

This tutorial walks you through enabling UFW (Uncomplicated Firewall) the safe way, with verification steps at every stage to ensure you maintain SSH access. Whether you're securing a new VPS, hardening an existing server, or just learning Linux system administration, this guide will help you set up your firewall with confidence.

What you'll learn:

How to check your current SSH configuration
The correct order to add firewall rules (SSH first!)
How to verify everything is working before and after enabling the firewall
A critical safety test that prevents lockouts

Time required: 5-10 minutes
Skill level: Beginner to intermediate (comfortable with SSH)
What you'll need: SSH access to your Linux server with sudo privileges

Step 1: Check Current SSH Connection
First, confirm you are connected via SSH and have sudo privileges. Use whoami command to see your username.
Check what port SSH is using (usually 22)
sudo netstat -tlnp | grep ssh
On newer systems, ss has replaced netstat
sudo ss -tlnp | grep ssh
It should show something like: tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
Note: Your SSH port might be different (like 2222). Remember this number!

Step 2: Allow SSH BEFORE Enabling Firewall
Method 1: If using default SSH port (22)
sudo ufw allow ssh

This rule allows the port associated with the SSH service - usually 22, as defined in /etc/services.

Method 2: If using custom SSH port (replace 2222 with your port)
sudo ufw allow 2222

Method 3: Be extra specific (replace YOUR_PORT with actual port)
sudo ufw allow YOUR_PORT/tcp

Verify the rule was added:
sudo ufw status verbose
Should show your SSH rule as "ALLOW IN"

Step 3: Add Other Required Rules
Allow web traffic (HTTP and HTTPS)
sudo ufw allow 'Nginx Full'

OR manually allow ports 80 and 443:

sudo ufw allow 80
sudo ufw allow 443

Set default policies (block everything except what we allow)

sudo ufw default deny incoming
sudo ufw default allow outgoing

Please note that these default policies won’t take effect until UFW is enabled (Step 5 of this tutorial).
By adding allow rules first, you ensure existing SSH traffic is permitted the moment the firewall activates.

Step 4: Test SSH Rule (Before Enabling)
Check UFW status (should still be inactive)
sudo ufw status
Should show: Status: inactive

Double-check SSH is allowed:
sudo ufw show added
Should show your SSH allow rule (from Step 2)

Step 5: Enable Firewall (The Moment of Truth)
Enable UFW with confirmation
sudo ufw enable
You'll see a warning like:"Command may disrupt existing ssh connections. Proceed with operation (y|n)?". Type: y.
If everything is correct, you should still be connected!

Step 6: Verify Everything Works
Check firewall status
sudo ufw status verbose
You should see something like:

Status: active
To                              Action          From
--                              ------          ----
22/tcp                               ALLOW IN    Anywhere
80,443/tcp (Nginx Full)              ALLOW IN    Anywhere

Check rule priority, which can help with troubleshooting.
sudo ufw status numbered
You should see something like:

Status: active
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere                  
[ 2] 80/tcp                     ALLOW IN    Anywhere                  
[ 3] 443/tcp                    ALLOW IN    Anywhere                  
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)             
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)             
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

Note: By default, UFW mirrors rules for IPv6 if IPv6 is enabled. The (v6) rules are for IPv6 connections and are normal - UFW creates these automatically.

Key Differences from Regular status command.

Numbered rules: Each rule gets a bracketed number [1], [2], etc.
Why this matters:

You can delete specific rules by number: sudo ufw delete 3
Easier to see rule order (UFW processes rules top to bottom)
More compact than status verbose

With More Complex Rules

If you have more specific rules (like allowing from certain IPs), it looks like:

To                          Action              From
     --                          ------             ----
[ 1] 22/tcp                     ALLOW IN        192.168.1.100            
[ 2] 22/tcp                     ALLOW IN        Anywhere                  
[ 3] 80/tcp                     ALLOW IN        Anywhere                  
[ 4] 3306/tcp                   ALLOW IN        10.0.0.0/8

Step 7: Critical safety test
After you’ve done all previous steps you should test that you can still connect. Open a NEW terminal window (DON’T CLOSE YOUR OLD WINDOW WHERE YOU CONFIGURED FIREWALL!) and SSH to your server. If this works, you're safe!
If this test fails, fix the issue in your original terminal window!

To finish, before you log out, confirm if:

SSH works in a second terminal,
ufw status shows ALLOW for your SSH port,
Default policy is set to deny incoming.

Have you ever accidentally locked yourself out of a server? What safety steps do you use?

What is Zero Trust, and why is it important?

Marek — Wed, 18 Jun 2025 09:17:24 +0000

For years the way many IT environments operated was if you could get past the firewall or connect to the company VPN, you were trusted.

Today, when remote work is very common, cloud services run critical operations, and cyberattacks have grown significantly in frequency and sophistication, that approach no longer works.

This is where Zero Trust security philosophy comes in. It was built on the idea that you should never trust anything or anyone by default, inside or outside your network. Every request for access must be verified explicitly, every time.

In this post, I’ll explain what Zero Trust is, how it differs from traditional security models, and why it matters for anyone working in technology today.

What is Zero Trust?

It is a cybersecurity strategy based on the principle of “never trust, always verify.”

Zero Trust assumes that a breach is either happening right now or will happen eventually. As a result, it treats every user, device, application, and network connection as untrusted until proven otherwise.

Key Components of Zero Trust

1. Verify explicitly
Always authenticate and authorize based on all available data points — including user identity, location, device health, and app sensitivity.

2. Use least privilege access
Limit access to just what’s needed for each person, system, or application to perform its job. Regularly review and adjust permissions. This component uses just-in-time (JIT) and just-enough access (JEA) principles.

3. Assume breach
Operate as if attackers are already in your environment. Segment access by network, user, devices, and application, monitor continuously, and respond quickly to incidents.

In Microsoft environment there are following services to implement Zero Trust philosophy:

Microsoft Entra ID (formerly Azure Active Directory) for identity and access management.
Microsoft Defender XDR (formerly Microsoft 365 Defender) for extended detection and response.
Microsoft Sentinel for threat detection and hunting.
Microsoft Entra Permissions Management for monitoring cloud entitlements.

Why Zero Trust is important
Zero Trust is no longer optional — it’s the fundamental piece of modern environments protection, especially because remote and hybrid work is here to stay.
The other important factor is that the regulatory standards (like GDPR, NIS2, and HIPAA) demand tighter control over data access.

Benefits of Adopting Zero Trust
Organizations that adopt a Zero Trust strategy experience:

Reduced risk of breaches
Improved compliance and audit readiness
Enhanced visibility over users, devices, and resources
Simplified and secure support for remote work
Faster incident detection and response

How to Start with Zero Trust
Zero Trust can feel overwhelming at first. Start small and build progressively:

Enforce Multi-Factor Authentication (MFA) everywhere.
Implement Conditional Access policies in Entra ID to control access based on risk.
Audit and minimize identity and permission sprawl.
Onboard logs into Microsoft Sentinel for visibility and analytics.
Adopt a Zero Trust mindset: question every access attempt, device, and connection.

Conclusion
Zero Trust is a necessary response to the way we work and operate technology today. By assuming breach, verifying explicitly, and enforcing least privilege, we significantly reduce the risks posed by modern cyber threats.

In upcoming posts, I’ll continue to explore Microsoft security solutions, threat detection, and SC-900/SC-200 study insights.

What is the difference between display:none and visibility:hidden?

Marek — Sat, 07 Nov 2020 20:24:55 +0000

If you are a frontend developer at the beginning of your career I’m sure you wonder how to prepare for your first interview. I’m going to focus on technical questions you may be asked and prepare answers for you.

In this article, I’m going to explain to you a difference between display:none and visibility:hidden properties as this is one of the questions you may hear during an interview for a frontend developer position.

Let’s use the following example to visualize the difference.

Here we have four cards and want to make Card 2 invisible. In general, both properties make it possible.

If we use display:none property the result will be the following:

As you can see Card 2 is not visible anymore and the remaining cards changed their positions so the margin we defined for them can be maintained.

Let’s check now what happens if we set the visibility:hidden for Card 2.

As you can see it’s also not visible anymore like in the previous case but its spot is empty and other elements didn’t change their positions. The margins of the Card 2 have been maintained and all elements around behave as it was still there.

I hope it explains well the difference between those two properties but if you still have any questions let me know.

The importance of your first app

Marek — Fri, 17 Apr 2020 16:12:48 +0000

So you are looking for a junior frontend developer position, right? Are you sure you know what you need to be successful?

Many times when you start to learn a new skill you need to be familiar with the basics of a theoretical part before you move to the practical one. Learning to code is not different and you probably have heard many times that one can learn to code only by coding. It’s true because only this way you can learn the most important skill you need as a developer which is the ability to create.

You may wonder why it is the most important skill. It is because as a software developer you will be responsible for the creation and it doesn’t matter if you remember all the theoretical parts or not. If you know what you need and where to find it you already have everything to start working and gaining experience. It’s the ability to join all different pieces of code together and create an app that can make you successful.

I can tell you from my experience that it is good to start with some simple apps that you can make by following Youtube tutorials. This way you will get familiar with a structure of an app and the logic used to create it. Choose different kinds of apps to have a wider perspective and learn how to use different parts of the theory, ex. DOM operations, API, operations on arrays, etc.

After you get comfortable with that comes the next step. Create your app. Think of something you would like to use and what features you would expect to have there as a user. Don’t get discouraged if you don’t know how to do something or the way you wanted to do it doesn’t work. This is where you learn the most important ability I have mentioned in the beginning.

The first app I’ve ever created was a simple game written in HTML, CSS and pure JavaScript and the main logic that it used were DOM operations like hiding and showing divs.

It made me very proud because I made it all by myself and as a result I got more courage and motivation to learn and to look for my first Frontend Developer job.
I am convinced that it can be the same for all of you that are at the beginning of the coding journey and if you think you need some extra motivation or don’t know how to improve your skills remember the importance of your first app.

#junior #beginners #motivation #impostersyndrome #career #mindset

Be ready to feel uncomfortable!

Marek — Wed, 15 Jan 2020 22:18:39 +0000

You may think it’s another article about motivation and all other related stuff. You are right!
I would like to share with you my story about how and why I decided to make a career change and join the IT people. I hope some of you will find it inspiring and motivating if you are in a similar situation.
I’m 38 and one year ago I’ve decided to start my career in the IT area. Some people advised me to become a tester as it might be easier but I didn’t want the easy way. I wanted to become a front-end developer so I started learning HTML, CSS and JavaScript. First I bought a book and started watching video tutorials and reading online articles about front-end technologies.
Actually, my first thought was, “If I were a real front-end developer how would my day look like? What Twitter accounts would I follow? What Youtube channels would I watch? What podcasts would I listen to?”. Thanks to this approach I have discovered a lot of valuable resources online available for free and found out that tech people are usually helpful and eager to share their knowledge.
So I’ve decided to become a front-end developer (let’s say I have already become it in my head at that point) and after a few months of self study I started (in Oct 2019) a 1-year front-end course at the local university.
After all this time I’ve spent studying I can tell you that it’s not easy and you need to be ready to feel uncomfortable but at the end all this hard work pays off.
If you are moving into IT from another industry like I am, don’t ever feel discouraged because of your age. If you put enough effort and self-confidence you are able to do it. Don’t stick to one learning method only. Try as many as you can. Watch videos, read articles and books, listen to podcasts and write a code.
Probably you have heard many times that the most important thing is to write a code as much as you can. It’s true but if you become a front-end developer in your head and follow a daily routine of a real front-end dev even before getting a real job it may be actually easier for you. It works for me so it would probably work for you, too.
If you think that if you are moving into IT from another industry you have to start from zero you are actually wrong. You may lack technical skills but don’t forget that some of your experience can be transferable.
I worked more than 10 years with international business development and cooperation issues, lived in 3 countries and speak 6 languages. Based on this experience I know what I bring to the table and even though my IT knowledge is on the basic level I’m convinced that my adaptability, ambition, experience in the international environment and languages I speak can be of a real value for a company with an international presence.
I am still waiting for my first IT job and even though I’ve applied for dozens companies the only feedback I’ve got is that they need a junior developer with experience. Is it going to discourage me? No, it is not, because I know the value I am bringing to the table and I know that there is a company out there that wants to grow and needs my help.

Look at the bigger picture and believe in yourself!

#junior #career #beginners #motivation #impostersyndrome #career #mindset