Lesson 1/9 10 min

What is a VPS?

Hotel, empty flat or Airbnb? Shared hosting, VPS, PaaS: pick the right level of control, the right provider, the right size — and your first SSH login.

Le jour où ton hébergeur dit non

Ton projet a grandi. Au début, un hébergement mutualisé à 3 € par mois suffisait : tu déposes tes fichiers PHP, ça s'affiche, parfait. Et puis un soir, tu veux ajouter un vrai plus : une tâche qui tourne toutes les minutes, un petit service Node en arrière-plan, une base PostgreSQL, un WebSocket pour du temps réel. Réponse de l'hébergeur : non. Pas prévu dans l'offre. Pas la bonne version de PHP non plus, d'ailleurs. Et impossible d'installer quoi que ce soit.

Normal : sur un mutualisé, tu es à l'hôtel. La chambre est faite, le petit-déjeuner est servi, mais tu ne choisis ni les meubles ni les horaires, et tu ne perces pas les murs. Pour aller plus loin, il te faut tes propres murs. C'est exactement ce qu'on loue avec un VPS : un Virtual Private Server, une machine Linux complète, à toi, avec sa propre adresse IP publique. Tu y installes ce que tu veux, comme tu veux.

Définition : un VPS est une machine virtuelle découpée dans un gros serveur physique d'un datacenter. De ton point de vue, c'est un ordinateur Linux entier : un processeur, de la RAM, un disque, une IP publique, et le droit de tout administrer (l'accès root). Chez OVH, Hetzner, DigitalOcean ou ailleurs, le principe est rigoureusement le même. C'est pour ça que ce cours vaut pour tous les hébergeurs.

Hôtel, appartement vide, ou Airbnb ?

Trois grandes façons d'héberger un projet, trois niveaux de contrôle :

  • Mutualisé = l'hôtel. Tout est géré pour toi, mais tu vis selon les règles de la maison. Parfait pour un site vitrine PHP simple. Bloquant dès que tu sors du cadre.
  • VPS = l'appartement vide. Les murs, les compteurs, une adresse. Tout le reste (la serrure, les meubles, l'entretien), c'est toi. Liberté totale, responsabilité totale. C'est le sujet de ce cours.
  • PaaS (Heroku, Vercel, Railway…) = l'Airbnb clé en main. Tu pousses ton code, la plateforme s'occupe de tout. Confortable et rapide, mais tu paies la commodité, et tu n'apprends pas ce qui se passe sous le capot. Le jour où ça casse, tu es démuni.

Pour un projet perso que tu veux bien gérer, le VPS est le meilleur rapport apprentissage/liberté/prix : quelques euros par mois pour une vraie machine. Côté choix concrets, pas besoin de se torturer :

Les choix raisonnables : un VPS d'entrée de gamme (1-2 vCPU, 2 Go de RAM) suffit largement pour démarrer un projet perso. Comme système : Debian ou Ubuntu LTS. Les deux sont stables, ultra-documentés, et tout ce cours s'applique aux deux. Évite les distributions exotiques : quand tu cherches de l'aide à 23h, c'est la documentation Debian/Ubuntu que tu trouveras.

La plupart des hébergeurs facturent à l'heure. Tu peux louer un VPS pour quelques centimes, suivre ce cours en grandeur réelle, tout casser, le détruire, et recommencer. Et avant chaque manœuvre risquée : fais un snapshot (une photo du disque) depuis le panneau de l'hébergeur. C'est ta machine à remonter le temps.

Tu as commandé : voilà ce qui t'attend

Tu choisis une offre, tu paies, et la machine est prête en quelques minutes. La suite dépend de l'hébergeur. Il existe deux écoles.

  • École « mail de livraison ». Tu reçois un mail avec l'adresse IP de ta machine, un nom d'utilisateur et un mot de passe temporaire (souvent derrière un lien sécurisé). C'est le cas chez OVHcloud : à la première connexion, le système te force à changer ce mot de passe. Hetzner fait pareil si tu n'as pas fourni de clé SSH.
  • École « clé SSH d'abord ». Aucun mot de passe ne circule. Tu colles ta clé publique SSH dans le panneau de l'hébergeur, avant ou pendant la création de la machine. Elle est injectée au premier démarrage, et seul ton ordinateur peut se connecter. Scaleway l'exige ; Infomaniak la génère ou l'importe à la commande. C'est la méthode la plus sûre. Pas de panique si tu n'as jamais créé de clé : on le fait ensemble à la leçon 2.

Dans les deux cas, tu obtiens la même chose : une IP publique et un accès administrateur. Et à ta toute première connexion SSH, le terminal affiche l'empreinte (fingerprint) de la machine et te demande de confirmer. Tape yes : c'est normal, il mémorise le serveur pour les fois suivantes. Tu vas le vivre dans le labo juste en dessous.

Quel hébergeur pour commencer ? Un petit VPS coûte entre 2 et 7 € par mois selon l'offre. Les choix les plus courants côté francophone : OVHcloud et Scaleway (français, datacenters en France), Hetzner (allemand, très populaire pour ses prix, pas de datacenter en France), Infomaniak (suisse, données sous droit suisse). Tous te remettent la même chose : une machine Debian/Ubuntu avec une IP. Peu importe ton choix, la suite du cours est identique partout.

Repère tout de suite, dans le panneau de ton hébergeur, la console de secours (parfois appelée KVM ou VNC). C'est un écran branché directement sur la machine, sans passer par SSH. Le jour où tu te retrouves enfermé dehors (mauvaise règle de firewall, clé perdue), c'est elle qui te sauve.

Prédis avant de lire

Tu viens de louer ton VPS. L'hébergeur t'envoie un mail : une adresse IP publique et un mot de passe root. À ton avis : combien de temps avant que des robots, quelque part sur internet, commencent à tester des mots de passe SSH sur cette IP toute neuve ?

Voir la réponse

Quelques minutes. Des botnets scannent en permanence l'intégralité des adresses IP publiques à la recherche de ports SSH ouverts, et enchaînent les tentatives de connexion automatiques (root/root, admin/123456…). Ce n'est pas personnel : ton IP fait juste partie de la liste, comme toutes les autres. C'est exactement pour ça que la leçon 2, fermer la porte, vient avant d'installer quoi que ce soit.

À toi : ta première connexion

Voici un terminal simulé, branché sur un faux VPS tout neuf (IP : 51.210.34.12). Il réagit comme un vrai : tape les commandes demandées dans la mission, observe les réponses. Tu vas faire ta toute première connexion SSH : le protocole qui te donne un terminal sur la machine distante, chiffré de bout en bout.

🖥️ Terminal simulé · ton premier VPS
$

À ce stade, ton vrai VPS serait dans son état le plus vulnérable : connexion root autorisée, par mot de passe, firewall absent, et des robots qui frappent déjà à la porte (tu l'as prédit plus haut). On n'installe rien tant que ce n'est pas réglé. C'est tout l'objet de la prochaine leçon.

La carte : ce qu'on va construire

Voilà le système complet vers lequel ce cours t'emmène, leçon après leçon. Garde cette carte en tête : chaque brique a sa leçon, et à la fin, un simple git push mettra ton projet en ligne, testé, en HTTPS, avec retour arrière possible.

Le visiteur atteint ton domaine en HTTPS via Caddy, qui transmet à ton application gérée par systemd ou Docker, avec sa base de données. GitHub Actions déploie automatiquement via SSH à chaque git push, et les sauvegardes partent vers un stockage externe. 🌍 Visiteur ton-projet.fr HTTPS TON VPS · Debian/Ubuntu (durci, leçon 2) Caddy :443 certifs auto · leçon 5 Ton app systemd/Docker · 3-4 🗄️ BDD locale, jamais exposée GitHub Actions tests → deploy · 6-8 git push → SSH 💾 Sauvegardes leçon 9 ☁️ Hors-site rclone, chaque nuit 🔔 Alerte uptime si ça tombe · leçon 9
L'architecture cible : chaque brique a sa leçon. À la fin, git push = projet testé, déployé, en HTTPS.

Et l'IA dans tout ça ? Elle est excellente pour générer les commandes et les fichiers de config de ce cours, et c'est précisément pour ça qu'il faut comprendre chaque brique : une commande système copiée sans comprendre s'exécute avec tous les droits sur ta machine. Ici, tu apprends ce que chaque pièce fait, pour pouvoir relire ce que l'IA te propose avant de l'exécuter.

Et pour un projet Symfony ? C'est le cas d'école. Le mutualisé bloque vite : version PHP imposée, pas de workers Messenger, pas de processus longs. Sur ton VPS, tu choisis tout. La version PHP, Composer, les workers, les crons. Un VPS à 2 Go suffit pour une app Symfony et sa base. Et bonne nouvelle : c'est le fil rouge de ce cours. À partir de la leçon 3, l'app qu'on déploie est une app Symfony, de bout en bout.

The day your host says no

Your project has grown. At first, €3-a-month shared hosting was enough: you drop your PHP files, they show up, perfect. Then one evening you want a real upgrade: a task running every minute, a small background Node service, a PostgreSQL database, a WebSocket for real-time. The host's answer: no. Not in the plan. Wrong PHP version too, by the way. And you can't install anything.

Normal: on shared hosting, you're in a hotel. The room is cleaned, breakfast is served, but you don't pick the furniture or the schedule, and you don't drill into walls. To go further, you need your own walls. That's exactly what a VPS rents you: a Virtual Private Server, a complete Linux machine of your own, with its own public IP address. You install whatever you want, however you want.

Definition: a VPS is a virtual machine carved out of a big physical server in a datacenter. From your point of view, it's a full Linux computer: a processor, RAM, a disk, a public IP, and full admin rights (root access). At OVH, Hetzner, DigitalOcean or anywhere else: the principle is rigorously the same — which is why this course works for every provider.

Hotel, empty flat, or Airbnb?

Three main ways to host a project, three levels of control:

  • Shared hosting = the hotel. Everything is managed for you, but you live by the house rules. Perfect for a simple PHP brochure site. Blocking as soon as you step outside the frame.
  • VPS = the empty flat. Walls, meters, an address. Everything else — the lock, the furniture, the upkeep — is on you. Total freedom, total responsibility. That's this course.
  • PaaS (Heroku, Vercel, Railway…) = the turnkey Airbnb. You push your code, the platform handles everything. Comfortable and fast, but you pay for the convenience, and you don't learn what happens under the hood — the day it breaks, you're stuck.

For a personal project you want to run well, the VPS is the best learning/freedom/price ratio: a few euros a month for a real machine. As for the concrete choices, no need to agonize:

The reasonable choices: an entry-level VPS (1-2 vCPU, 2 GB RAM) is plenty to start a personal project. As the OS: Debian or Ubuntu LTS — both are stable, hugely documented, and this whole course applies to both. Avoid exotic distributions: when you're looking for help at 11 p.m., it's Debian/Ubuntu documentation you'll find.

Most providers bill by the hour. You can rent a VPS for a few cents, follow this course for real, break everything, destroy it, and start again. And before any risky manoeuvre: take a snapshot (a picture of the disk) from the provider's panel — it's your time machine.

You've ordered: here's what happens next

You pick a plan, you pay, and the machine is ready within minutes. What comes next depends on the provider. There are two schools.

  • The "delivery email" school. You get an email with your machine's IP address, a username and a temporary password (often behind a secure link). That's how OVHcloud does it: on your first login, the system forces you to change that password. Hetzner does the same if you didn't provide an SSH key.
  • The "SSH key first" school. No password travels at all. You paste your public SSH key into the provider's panel, before or while creating the machine. It gets injected at first boot, and only your computer can connect. Scaleway requires it; Infomaniak generates or imports one at checkout. It's the safest method. No worries if you've never created a key: we do it together in lesson 2.

Either way, you end up with the same thing: a public IP and admin access. And on your very first SSH connection, the terminal shows the machine's fingerprint and asks you to confirm. Type yes: that's normal, it memorizes the server for next time. You're about to experience it in the lab just below.

Which provider to start with? A small VPS costs between €2 and €7 a month depending on the plan. The usual picks for French speakers: OVHcloud and Scaleway (French, datacenters in France), Hetzner (German, hugely popular for its prices, no datacenter in France), Infomaniak (Swiss, data under Swiss law). They all hand you the same thing: a Debian/Ubuntu machine with an IP. Whatever you choose, the rest of this course is identical everywhere.

Right away, locate the rescue console in your provider's panel (sometimes called KVM or VNC). It's a screen plugged straight into the machine, no SSH involved. The day you lock yourself out (bad firewall rule, lost key), it's what saves you.

Predict before reading on

You just rented your VPS. The provider emails you a public IP address and a root password. Your guess: how long before robots, somewhere on the internet, start testing SSH passwords on that brand-new IP?

Show the answer

A few minutes. Botnets permanently scan the entire public IP space looking for open SSH ports, then chain automatic login attempts (root/root, admin/123456…). It's nothing personal: your IP is simply on the list, like every other. That's exactly why lesson 2 — locking the door — comes before installing anything.

Your turn: your first login

Here's a simulated terminal, wired to a fake brand-new VPS (IP: 51.210.34.12). It reacts like the real thing: type the commands the mission asks for, watch the answers. You're about to make your very first SSH connection — the protocol that gives you a terminal on the remote machine, encrypted end to end.

🖥️ Simulated terminal · your first VPS
$

At this point, your real VPS would be at its most vulnerable: root login allowed, by password, no firewall, and robots already knocking (you predicted it above). We install nothing until that's fixed. That's the whole point of the next lesson.

The map: what we're going to build

Here's the complete system this course takes you to, lesson by lesson. Keep this map in mind: every brick has its lesson, and at the end, a simple git push puts your project live, tested, on HTTPS, with a way back.

The visitor reaches your domain over HTTPS through Caddy, which forwards to your app managed by systemd or Docker, with its database. GitHub Actions deploys automatically over SSH on every git push, and backups leave for external storage. 🌍 Visitor your-project.dev HTTPS YOUR VPS · Debian/Ubuntu (hardened, lesson 2) Caddy :443 auto certs · lesson 5 Your app systemd/Docker · 3-4 🗄️ Database local, never exposed GitHub Actions tests → deploy · 6-8 git push → SSH 💾 Backups lesson 9 ☁️ Off-site rclone, every night 🔔 Uptime alert if it goes down · 9
The target architecture: every brick has its lesson. At the end, git push = project tested, deployed, on HTTPS.

And AI in all this? It's excellent at generating the commands and config files of this course — which is precisely why you need to understand every brick: a system command copied without understanding runs with full rights on your machine. Here, you learn what each piece does, so you can review what the AI suggests before executing it.

And for a Symfony project? It's the textbook case. Shared hosting blocks you fast: imposed PHP version, no Messenger workers, no long-running processes. On your VPS, you choose everything. The PHP version, Composer, the workers, the crons. A 2 GB VPS is enough for a Symfony app and its database. Good news: it's this course's main thread. From lesson 3 on, the app we deploy is a Symfony app, end to end.

🎯 Pratique

S'entraîner (clique pour ouvrir) :

💬 Ré-explique sans regarder
Ré-explique sans regarder

Avec tes mots et l'analogie du logement : c'est quoi la différence entre un hébergement mutualisé, un VPS et un PaaS ? Et pour qui chacun est-il fait ?

Une bonne explication dit : le mutualisé = l'hôtel (tout est géré, mais cadre imposé, bien pour un site simple) ; le VPS = l'appartement vide (machine Linux complète, IP publique, root : liberté ET responsabilité totales, idéal pour apprendre et tout contrôler) ; le PaaS = l'Airbnb clé en main (tu pousses le code, la plateforme gère : confortable, payant, opaque). Le principe du VPS est le même chez tous les hébergeurs.
🧠 Rappel libre
Rappel libre

Sans remonter : quand tu loues un VPS, qu'est-ce que tu reçois exactement, et dans quel état est la machine côté sécurité ?

Une machine virtuelle Linux complète (CPU, RAM, disque), une IP publique, et l'accès root (souvent par mot de passe reçu par mail). Côté sécurité, elle est nue et vulnérable : connexion root par mot de passe autorisée, pas de firewall, et des bots testent déjà des mots de passe sur l'IP au bout de quelques minutes. Premier chantier : la durcir (leçon 2), avant d'installer quoi que ce soit.
⚖️ Juge le conseil de l'IA
Accepter ou rejeter le conseil de l'IA

Tu demandes à l'IA un script d'installation pour ton VPS tout neuf. Elle répond : « Voilà, connecte-toi en root avec le mot de passe du mail, garde-le, il est pratique, et installe directement l'app : ssh root@IP puis curl … | bash. La sécurité, on verra après, l'important c'est que ça tourne. » Tu acceptes, ou tu rejettes ?

À rejeter, pour trois raisons. 1) Rester en root par mot de passe, c'est laisser ouvertes les deux portes que les bots testent en boucle dès la première minute. 2) « La sécurité après » est dans le mauvais ordre : durcir prend 10 minutes et doit venir AVANT d'exposer quoi que ce soit. 3) curl … | bash exécute un script téléchargé, avec tous les droits, sans relecture : sur un serveur, on lit ce qu'on exécute. L'IA optimise « ça tourne vite », pas « c'est tenable » : c'est toi qui portes le risque.
Concrètement, qu'est-ce qu'on loue quand on prend un VPS ?
Quelle est LA différence clé entre le mutualisé et le VPS ?
Ton VPS tout neuf vient d'être créé, IP publique active. Que se passe-t-il dans les minutes qui suivent ?
Pour un projet perso que tu veux bien gérer ET comprendre, pourquoi le VPS plutôt que le PaaS ?
Next step

You have the keys to the flat, but the door is wide open and strangers are already trying the handle. In lesson 2, we lock everything down in 5 moves: deploy user, SSH keys, firewall, fail2ban and automatic updates — in the simulated terminal, command by command.

Lesson 2: Hardening your VPS →
Besoin d'un développeur pour votre projet ?

Réponse sous 24h · Sans engagement