Stop Using FTP: The Battle-Tested Guide to Git-Driven Infrastructure
If you are still dragging and dropping files via FileZilla to your production server in 2014, we need to have a serious talk. I have seen production servers implode because a junior dev overwrote config.php with a local version that had debug mode enabled. I have seen database connections hang because someone manually edited a firewall rule and forgot to reload the service.
The era of "works on my machine" is over. We need consistency. We need Infrastructure as Code (IaC).
While Silicon Valley startups are buzzing about "Continuous Deployment," the reality in Europe—and specifically here in the Nordic hosting landscape—is that too many agencies rely on fragile manual workflows. In this guide, I’m going to show you how to build a robust deployment pipeline using Git, Puppet, and reliable KVM virtualization. No magic, just shell scripts and logic.
The Core Philosophy: If It's Not in Git, It Doesn't Exist
The concept is simple: Your Git repository is the single source of truth. You do not log into the server to tweak an Nginx config. You tweak the config in your local editor, commit, and push. The server updates itself.
Why is this critical for Norwegian businesses? Compliance and Stability. With the Data Protection Directive (and the strict enforcement by Datatilsynet), knowing exactly who changed what and when is mandatory. Git provides that audit trail automatically.
Level 1: The "Poor Man's" Deploy (Git Hooks)
For smaller projects hosted on a VPS, you don't need a heavy Jenkins server. You just need a bare Git repository and a post-receive hook.
First, on your CoolVDS instance, initialize a bare repo:
root@oslo-node-04:~# mkdir -p /var/git/project.git
root@oslo-node-04:~# cd /var/git/project.git
root@oslo-node-04:/var/git/project.git# git init --bareNow, create the hook that deploys the code to your web root whenever you push. This uses a checkout -f strategy.
#!/bin/sh
# /var/git/project.git/hooks/post-receive
GIT_WORK_TREE=/var/www/html git checkout -f
echo "DEPLOY: Code updated at $(date)"
# Restart PHP-FPM if needed (be careful with restarts!)
service php5-fpm reloadMake it executable: chmod +x hooks/post-receive.
Why this matters: This operation is I/O intensive. Git has to write thousands of small files instantly. On standard spinning rust (HDD) hosting, this can lock up your web server for seconds. On CoolVDS, we use pure Enterprise SSD arrays. The checkout happens in milliseconds, meaning zero perceived downtime for your users hitting the site from Oslo or Bergen.
Level 2: Configuration Management with Puppet
Copying code is easy. Managing server configuration is hard. What happens if your nginx.conf drifts?
In 2014, Puppet is the industry standard for defining server state. Instead of running apt-get install nginx manually, you define it. Here is a battle-hardened manifest snippet for an optimized Nginx setup suitable for high-traffic sites:
# /etc/puppet/manifests/site.pp
node 'web01.coolvds.no' {
package { 'nginx':
ensure => installed,
}
service { 'nginx':
ensure => running,
enable => true,
require => Package['nginx'],
}
file { '/etc/nginx/nginx.conf':
ensure => present,
content => template('nginx/nginx.conf.erb'),
notify => Service['nginx'],
}
# Tuning for High Load
sysctl { 'net.ipv4.tcp_tw_reuse':
value => '1',
}
}This ensures that if a sysadmin accidentally stops Nginx, Puppet will bring it back up on the next run. It ensures consistency across dev, staging, and production.
The Infrastructure Reality Check: KVM vs. OpenVZ
Here is where many DevOps engineers fail. They try to run these heavy automation tools on cheap OpenVZ containers.
Pro Tip: Avoid OpenVZ for heavy automation. Puppet and Chef often require low-level kernel access to manage packages, users, and firewall tables (iptables) correctly. OpenVZ shares the host kernel, leading to "noisy neighbor" issues and permission errors when trying to modify sysctl params like tcp_tw_reuse.This is why CoolVDS exclusively uses KVM (Kernel-based Virtual Machine). With KVM, your Linux kernel is yours alone. You can tune the TCP stack for the specific latency conditions of the Norwegian network backbone without asking permission from the host node. You get guaranteed RAM, not "burstable" RAM that vanishes when you need it most (like during a `git clone`).
Optimizing for Latency in Northern Europe
When you automate deployments, speed is addictive. If a push takes 5 minutes, developers stop pushing often. If it takes 10 seconds, they push small, safe changes.
To achieve that 10-second window, network latency is paramount. If your git repository is hosted in the US (Github) but your server is in Norway, you are adding round-trip time (RTT) to every object handshake.
| Server Location | Ping to Oslo (Avg) | Git Pull Time (100MB) |
|---|---|---|
| US East | ~110ms | 45s |
| Germany | ~35ms | 12s |
| CoolVDS (Oslo/local) | <5ms | 2.5s |
Hosting your Git (GitLab Community Edition is great for this) and your staging servers on the same local network segment minimizes transfer time. It keeps data within Norwegian borders, satisfying the strictest interpretations of the Personal Data Act.
Final Thoughts
Moving from FTP to Git-driven deployment is scary the first time you do it. You feel like you've lost control because you aren't clicking "Upload." But the stability you gain is worth it. You eliminate human error. You create a history of every change.
Don't let legacy hosting infrastructure bottleneck your modern workflow. Automation requires fast I/O and kernel-level control.
Ready to modernize? Spin up a KVM instance on CoolVDS today. Our templates come with Git and Puppet pre-installed, and with our SSD storage, your deploys will finish before you can switch tabs.