Intermédiaire ⏱ 20 min de mise en œuvre Mis à jour le 11 août 2026

Installer PostgreSQL sur un VPS pour ses applications

Une base relationnelle robuste pour vos applications, sous votre contrôle. Voici comment installer PostgreSQL sur un VPS, en Docker ou en natif, et l'exploiter proprement en production.

Installer PostgreSQL sur un VPS permet de disposer d’une base relationnelle robuste pour une application SaaS, web ou IA. PostgreSQL gère notamment les transactions, les contraintes, les index, les données JSON et les accès concurrents.

L’auto-hébergement est pertinent lorsque vous souhaitez maîtriser la version, la configuration, les sauvegardes et la localisation des données. Il implique aussi d’assurer vous-même la sécurité, les mises à jour et la supervision. Les VPS TalCloud sont disponibles à partir de 4,99 € par mois, avec des serveurs en France, un cadre RGPD, du stockage NVMe, une protection Anti-DDoS Netrix et un support humain.

Deux méthodes sont possibles : Docker Compose, recommandé pour isoler et versionner le service, ou une installation native avec les paquets du système.

Prérequis pour installer PostgreSQL sur un VPS

Ce guide suppose que vous disposez :

d’un VPS sous Debian ou Ubuntu ;
d’un accès SSH ;
d’un compte avec les droits sudo ou d’un accès root ;
d’un pare-feu actif ;
de Docker avec le module Compose pour l’option A (voir installer Docker sur un VPS).

Commencez par mettre le système à jour :

sudo apt update
sudo apt upgrade

PostgreSQL écoute sur le port 5432. Ce port ne doit jamais être ouvert publiquement dans le pare-feu.

Option A : PostgreSQL avec Docker Compose

Docker facilite l’isolation de PostgreSQL, le choix précis de sa version et la restauration du service sur une autre machine. Les données doivent toutefois être placées dans un volume persistant.

Créez un répertoire de travail :

sudo mkdir -p /opt/postgresql
sudo chown "$USER":"$USER" /opt/postgresql
cd /opt/postgresql

Générez un mot de passe robuste :

openssl rand -base64 36

Créez ensuite un fichier .env :

POSTGRES_PASSWORD=remplacez_par_le_mot_de_passe_genere

Protégez ce fichier et excluez-le de Git :

chmod 600 .env
printf ".env\n" >> .gitignore

Créez un fichier compose.yml :

services:
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  postgres_data:

L’image est volontairement fixée sur postgres:16. Évitez le tag latest, qui pourrait introduire une nouvelle version majeure sans validation préalable.

La liaison 127.0.0.1:5432:5432 rend PostgreSQL accessible uniquement depuis le VPS. Lancez le service :

docker compose up -d
docker compose ps
docker compose logs -f db

Attendez que l’état du conteneur devienne healthy. Le volume postgres_data conserve la base lorsque le conteneur est recréé. La commande suivante arrête le service sans supprimer ce volume :

docker compose down

N’utilisez pas docker compose down -v sur une base de production, car l’option -v supprime le volume et ses données.

Le mot de passe POSTGRES_PASSWORD initialise le compte postgres uniquement lors de la création d’un volume vide. Le modifier dans .env ne change pas automatiquement le mot de passe d’une base déjà initialisée.

Option B : installer PostgreSQL nativement avec apt

L’installation native convient si vous préférez administrer PostgreSQL comme un service système, sans couche Docker. La version installée dépend alors des dépôts de votre distribution.

Installez les paquets :

sudo apt update
sudo apt install postgresql postgresql-contrib

Vérifiez le service et la version :

sudo systemctl status postgresql
sudo -u postgres psql -c "SELECT version();"

Identifiez les fichiers de configuration utilisés :

sudo -u postgres psql -tAc "SHOW config_file;"
sudo -u postgres psql -tAc "SHOW hba_file;"

Dans postgresql.conf, conservez une écoute locale :

listen_addresses = 'localhost'
port = 5432

Dans pg_hba.conf, autorisez l’authentification locale par mot de passe avec SCRAM :

local   all   postgres                         peer
host    all   all        127.0.0.1/32          scram-sha-256
host    all   all        ::1/128               scram-sha-256

Rechargez ensuite la configuration :

sudo systemctl reload postgresql
sudo ss -ltnp | grep 5432

Le résultat doit montrer une écoute sur 127.0.0.1:5432 et éventuellement [::1]:5432, jamais sur 0.0.0.0:5432.

Créer une base et un utilisateur applicatif

Une application ne doit jamais utiliser le superutilisateur postgres. Créez un rôle distinct pour limiter l’impact d’une fuite d’identifiants ou d’une injection SQL.

Avec Docker :

docker compose exec db createuser -U postgres --pwprompt app_user
docker compose exec db createdb -U postgres --owner=app_user app_db
docker compose exec db psql -U postgres -d app_db

Avec l’installation native :

sudo -u postgres createuser --pwprompt app_user
sudo -u postgres createdb --owner=app_user app_db
sudo -u postgres psql -d app_db

Dans psql, limitez les droits publics et accordez uniquement les permissions nécessaires à l’utilisateur applicatif :

REVOKE ALL ON DATABASE app_db FROM PUBLIC;
GRANT CONNECT, TEMPORARY ON DATABASE app_db TO app_user;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
GRANT USAGE, CREATE ON SCHEMA public TO app_user;
\q

app_user peut ainsi travailler dans sa base sans administrer les autres bases ni les rôles du serveur. Pour une application utilisant plusieurs rôles, séparez également le compte chargé des migrations du compte utilisé pendant l’exécution.

Connecter l’application à PostgreSQL

Une chaîne de connexion classique prend cette forme :

DATABASE_URL=postgresql://app_user:mot_de_passe@127.0.0.1:5432/app_db

Les paramètres correspondent à :

127.0.0.1 : l’hôte PostgreSQL ;
5432 : le port ;
app_user : l’utilisateur dédié ;
app_db : la base de l’application.

Si l’application se trouve dans le même fichier Compose, utilisez le nom du service comme hôte :

DATABASE_URL=postgresql://app_user:mot_de_passe@db:5432/app_db

Placez cette variable dans un gestionnaire de secrets ou un fichier .env protégé et non versionné. Si le mot de passe contient des caractères réservés comme @, / ou :, encodez-les dans l’URL ou fournissez les paramètres séparément avec le pilote PostgreSQL de votre framework.

Testez une connexion locale :

psql -h 127.0.0.1 -U app_user -d app_db

Sécuriser PostgreSQL en production

Ne publiez jamais directement le port 5432 sur Internet, même avec un mot de passe fort. Une base exposée subit rapidement des scans et des tentatives automatisées. Gardez ce port fermé au niveau du pare-feu.

Pour une intervention distante ponctuelle, utilisez un tunnel SSH :

ssh -L 5433:127.0.0.1:5432 utilisateur@adresse_du_vps

Votre client local pourra alors se connecter à 127.0.0.1:5433. Pour des échanges permanents entre plusieurs serveurs, utilisez un réseau privé ou un VPN comme WireGuard.

Employez des mots de passe uniques, activez l’authentification SCRAM et renouvelez les secrets selon votre politique interne. Si PostgreSQL communique sur un réseau distinct de la boucle locale, configurez SSL avec des certificats vérifiés. Préférez alors sslmode=verify-full lorsque le pilote le permet.

La protection Anti-DDoS Netrix protège l’infrastructure réseau, mais elle ne remplace ni le pare-feu, ni les restrictions d’écoute, ni une authentification solide.

Sauvegarder et restaurer PostgreSQL

Pour produire une sauvegarde SQL lisible :

pg_dump -h 127.0.0.1 -U app_user \
  --clean --if-exists --no-owner app_db > app_db.sql

Avec Docker :

docker compose exec -T db \
  pg_dump -U app_user --clean --if-exists --no-owner app_db > app_db.sql

Restaurez cette sauvegarde avec psql :

psql -h 127.0.0.1 -U app_user -d app_db < app_db.sql

Avec Docker :

docker compose exec -T db psql -U app_user -d app_db < app_db.sql

Pour exporter l’ensemble du cluster natif, y compris les rôles :

sudo -u postgres pg_dumpall > cluster.sql

Automatisez les exports avec cron. Pour une installation native :

sudo install -d -o postgres -g postgres -m 700 /var/backups/postgresql
sudo -u postgres crontab -e

Ajoutez une sauvegarde quotidienne à 2 h :

0 2 * * * pg_dump --clean --if-exists --no-owner app_db > /var/backups/postgresql/app_db-$(date +\%F).sql

Stockez au moins une copie hors du VPS, chiffrez-la si elle contient des données personnelles et testez régulièrement une restauration. Notre guide sur la stratégie de sauvegarde d’un serveur détaille l’automatisation et la rotation. Une sauvegarde dont la restauration n’a jamais été vérifiée reste incertaine.

Mises à jour et bonnes pratiques d’exploitation

Avant une mise à jour majeure, réalisez une sauvegarde et consultez les changements incompatibles. Avec Docker, changez explicitement la version de l’image après validation. Une nouvelle version majeure peut nécessiter pg_upgrade ou un export suivi d’une restauration.

Pour les correctifs compatibles de PostgreSQL 16 :

docker compose pull db
docker compose up -d

Avec apt :

sudo apt update
sudo apt upgrade

Surveillez enfin l’espace disque, les journaux, les connexions, la durée des requêtes et le succès des sauvegardes :

df -h
docker compose logs --tail=100 db
sudo journalctl -u postgresql --since today

Configurez des alertes avant saturation du stockage NVMe, documentez la procédure de restauration et exécutez un test de connexion applicative après chaque maintenance.