{"id":51,"date":"2026-08-09T19:48:52","date_gmt":"2026-08-09T17:48:52","guid":{"rendered":"https:\/\/homelab.nvsd.ch\/?p=51"},"modified":"2026-08-18T21:36:00","modified_gmt":"2026-08-18T19:36:00","slug":"migrer-mon-site-homelab-wordpress-du-local-vers-un-vps","status":"publish","type":"post","link":"https:\/\/homelab.nvsd.ch\/?p=51","title":{"rendered":"Migrer mon site Homelab WordPress du local vers un VPS"},"content":{"rendered":"\n

Apr\u00e8s avoir construit et valid\u00e9 mon site Homelab en local, l\u2019\u00e9tape suivante \u00e9tait logique : le mettre r\u00e9ellement en production sur mon VPS<\/strong>.<\/p>\n\n\n\n

Je ne voulais pas simplement copier quelques fichiers sur un serveur. L\u2019objectif \u00e9tait de conserver une architecture claire, reproductible et coh\u00e9rente avec le reste de mon Homelab : Docker, Nginx Proxy Manager, r\u00e9seaux s\u00e9par\u00e9s, volumes persistants, sauvegardes et possibilit\u00e9 de revenir en arri\u00e8re en cas de probl\u00e8me.<\/p>\n\n\n\n

Cette migration a donc \u00e9t\u00e9 r\u00e9alis\u00e9e comme une vraie petite op\u00e9ration de production : sauvegarder, transf\u00e9rer, restaurer, tester, basculer le domaine, s\u00e9curiser puis nettoyer<\/strong>.<\/p>\n\n\n\n

\"Migration<\/figure>\n\n\n\n

Le point de d\u00e9part : un WordPress valid\u00e9 en local<\/h2>\n\n\n\n

Mon environnement local comportait d\u00e9j\u00e0 une version fonctionnelle du site avec :<\/p>\n\n\n\n

    \n
  • WordPress ;<\/li>\n\n\n\n
  • MariaDB ;<\/li>\n\n\n\n
  • mon th\u00e8me personnalis\u00e9 NVSD Homelab 2.1.2<\/strong> ;<\/li>\n\n\n\n
  • les articles et m\u00e9dias ;<\/li>\n\n\n\n
  • une mise en page align\u00e9e sur le builder ;<\/li>\n\n\n\n
  • une stack Docker reproductible.<\/li>\n<\/ul>\n\n\n\n

    Je voulais conserver cette installation locale comme environnement de d\u00e9veloppement et de test.<\/p>\n\n\n\n

    Le principe retenu est donc simple :<\/p>\n\n\n\n

    LOCAL\nD\u00e9veloppement \/ tests \/ \u00e9volution du th\u00e8me\n\n        \u2193 migration contr\u00f4l\u00e9e\n\nVPS\nVersion de production publique<\/code><\/pre>\n\n\n\n
    Cette s\u00e9paration me permet de continuer \u00e0 faire \u00e9voluer le th\u00e8me ou les contenus sans exp\u00e9rimenter directement sur la version publique.<\/p>\n\n\n\n
    \u00c9tape 1 \u2014 Sauvegarder avant de migrer<\/h2>\n\n\n\n
    Avant de modifier quoi que ce soit sur le VPS, j\u2019ai cr\u00e9\u00e9 une sauvegarde compl\u00e8te de la version locale.<\/p>\n\n\n\n
    Elle contenait notamment :<\/p>\n\n\n\n
    database.sql\nwordpress-files.tar.gz\ntheme-nvsd-homelab.tar.gz\ncompose.yaml\ntheme-version.txt\nSHA256SUMS<\/code><\/pre>\n\n\n\n
    La base MariaDB a \u00e9t\u00e9 export\u00e9e avec mariadb-dump<\/code>. Les fichiers WordPress ont \u00e9t\u00e9 archiv\u00e9s s\u00e9par\u00e9ment et le th\u00e8me a \u00e9galement re\u00e7u sa propre archive.<\/p>\n\n\n\n
    J\u2019ai ensuite g\u00e9n\u00e9r\u00e9 des sommes SHA256 pour pouvoir v\u00e9rifier que les fichiers transf\u00e9r\u00e9s n\u2019avaient pas \u00e9t\u00e9 alt\u00e9r\u00e9s.<\/p>\n\n\n\n
    sha256sum database.sql \\\n  wordpress-files.tar.gz \\\n  theme-nvsd-homelab.tar.gz \\\n  > SHA256SUMS<\/code><\/pre>\n\n\n\n
    Ce contr\u00f4le peut sembler excessif pour un simple site WordPress, mais il devient vite utile d\u00e8s qu\u2019un Homelab h\u00e9berge plusieurs services. Une migration doit pouvoir \u00eatre interrompue et recommenc\u00e9e sans perdre l\u2019\u00e9tat de d\u00e9part.<\/p>\n\n\n\n
    \"Sauvegarde<\/figure>\n\n\n\n
    \"Sauvegarde<\/figure>\n\n\n\n
    \u00c9tape 2 \u2014 Organiser la stack sur le VPS<\/h2>\n\n\n\n
    J\u2019ai profit\u00e9 de la migration pour uniformiser l\u2019organisation de mon serveur.<\/p>\n\n\n\n
    Toutes les stacks sont d\u00e9sormais regroup\u00e9es sous :<\/p>\n\n\n\n
    \/opt\/homelab\/stacks\/<\/code><\/pre>\n\n\n\n
    La nouvelle stack WordPress se trouve dans :<\/p>\n\n\n\n
    \/opt\/homelab\/stacks\/nvsd-homelab-wordpress\/<\/code><\/pre>\n\n\n\n
    avec une structure volontairement simple :<\/p>\n\n\n\n
    nvsd-homelab-wordpress\/\n\u251c\u2500\u2500 compose.yaml\n\u251c\u2500\u2500 .env\n\u251c\u2500\u2500 theme\/\n\u2502   \u2514\u2500\u2500 nvsd-homelab\/\n\u251c\u2500\u2500 restore\/\n\u2514\u2500\u2500 backup\/<\/code><\/pre>\n\n\n\n
    Cette convention est importante pour moi : chaque projet poss\u00e8de un dossier identifiable, son Compose, ses ressources et ses sauvegardes.<\/p>\n\n\n\n
    \u00c9tape 3 \u2014 S\u00e9parer les r\u00e9seaux Docker<\/h2>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Je ne voulais surtout pas publier MariaDB directement sur le VPS.<\/p>\n\n\n\n
    La stack utilise donc deux r\u00e9seaux Docker.<\/p>\n\n\n\n
    Le premier est priv\u00e9 :<\/p>\n\n\n\n
    nvsd_homelab_internal<\/code><\/pre>\n\n\n\n
    Il relie uniquement WordPress \u00e0 MariaDB.<\/p>\n\n\n\n
    Le second est le r\u00e9seau partag\u00e9 :<\/p>\n\n\n\n
    proxy<\/code><\/pre>\n\n\n\n
    Il permet \u00e0 Nginx Proxy Manager d\u2019atteindre WordPress.<\/p>\n\n\n\n
    L\u2019architecture finale est donc :<\/p>\n\n\n\n
    Internet\n   \u2193\nHTTPS\n   \u2193\nNginx Proxy Manager\n   \u2193\nr\u00e9seau Docker proxy\n   \u2193\nWordPress :80\n   \u2193\nr\u00e9seau Docker priv\u00e9\n   \u2193\nMariaDB :3306<\/code><\/pre>\n\n\n\n
    MariaDB n\u2019est jamais expos\u00e9e directement \u00e0 Internet, et WordPress ne poss\u00e8de pas non plus de port public une fois la migration termin\u00e9e.<\/p>\n\n\n\n
    \"Architecture<\/figure>\n\n\n\n
    \u00c9tape 4 \u2014 Restaurer MariaDB avant WordPress<\/h2>\n\n\n\n
    J\u2019ai commenc\u00e9 par d\u00e9marrer uniquement la base de donn\u00e9es.<\/p>\n\n\n\n
    Une fois MariaDB en \u00e9tat healthy<\/code>, j\u2019ai import\u00e9 le dump SQL provenant de l\u2019environnement local.<\/p>\n\n\n\n
    Pour v\u00e9rifier rapidement que la restauration \u00e9tait correcte, j\u2019ai interrog\u00e9 WordPress directement dans la base :<\/p>\n\n\n\n
    SELECT COUNT(*) AS articles\nFROM wp_posts\nWHERE post_type='post';<\/code><\/pre>\n\n\n\n
    Le r\u00e9sultat retournait bien mes 7 articles<\/strong>.<\/p>\n\n\n\n
    \u00c0 ce stade, les donn\u00e9es \u00e9taient restaur\u00e9es, mais il restait encore \u00e0 remettre les m\u00e9dias, plugins et fichiers sp\u00e9cifiques au site.<\/p>\n\n\n\n
    \u00c9tape 5 \u2014 Restaurer wp-content<\/code> sans \u00e9craser inutilement le c\u0153ur WordPress<\/h2>\n\n\n\n
    Plut\u00f4t que de remplacer aveugl\u00e9ment tout \/var\/www\/html<\/code>, j\u2019ai laiss\u00e9 l\u2019image officielle WordPress initialiser son propre c\u0153ur applicatif.<\/p>\n\n\n\n
    J\u2019ai ensuite restaur\u00e9 le contenu sp\u00e9cifique du site, principalement :<\/p>\n\n\n\n
    wp-content\/<\/code><\/pre>\n\n\n\n
    Ce dossier contient notamment :<\/p>\n\n\n\n
      \n
    • les m\u00e9dias ;<\/li>\n\n\n\n
    • les plugins ;<\/li>\n\n\n\n
    • les donn\u00e9es propres au site.<\/li>\n<\/ul>\n\n\n\n
      Le th\u00e8me NVSD est mont\u00e9 s\u00e9par\u00e9ment depuis l\u2019h\u00f4te en lecture seule :<\/p>\n\n\n\n
      .\/theme\/nvsd-homelab\n        \u2193\n\/var\/www\/html\/wp-content\/themes\/nvsd-homelab<\/code><\/pre>\n\n\n\n
      Ainsi, le th\u00e8me stock\u00e9 dans la stack reste ma source de r\u00e9f\u00e9rence.<\/p>\n\n\n\n
      Apr\u00e8s restauration, le dossier uploads<\/code> repr\u00e9sentait environ 18 Mo<\/strong>, ce qui confirmait que les m\u00e9dias avaient bien \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9s.<\/p>\n\n\n\n
      \u00c9tape 6 \u2014 Comprendre le premier 301<\/code><\/h2>\n\n\n\n
      Le premier test HTTP sur le VPS a retourn\u00e9 :<\/p>\n\n\n\n
      HTTP\/1.1 301 Moved Permanently\nLocation: http:\/\/127.0.0.1:8086\/<\/code><\/pre>\n\n\n\n
      Ce n\u2019\u00e9tait pas une erreur de Docker, Apache ou Nginx Proxy Manager.<\/p>\n\n\n\n
      La base WordPress contenait encore les valeurs de l\u2019environnement local :<\/p>\n\n\n\n
      home    = http:\/\/127.0.0.1:8086\nsiteurl = http:\/\/127.0.0.1:8086<\/code><\/pre>\n\n\n\n
      WordPress faisait donc exactement ce qu\u2019on lui demandait.<\/p>\n\n\n\n
      Avant de changer ces URL, j\u2019ai utilis\u00e9 un tunnel SSH pour v\u00e9rifier visuellement le WordPress restaur\u00e9 sur le VPS tout en conservant l\u2019adresse locale attendue par la base.<\/p>\n\n\n\n
      Cette \u00e9tape m\u2019a permis de contr\u00f4ler le th\u00e8me, les images et les articles avant la bascule publique<\/strong>.<\/p>\n\n\n\n
      \u00c9tape 7 \u2014 Remplacer les URL avec WP-CLI<\/h2>\n\n\n\n
      Une fois le rendu du VPS valid\u00e9, j\u2019ai remplac\u00e9 l\u2019ancienne URL locale par :<\/p>\n\n\n\n
      https://homelab.nvsd.ch<\/code><\/pre>\n\n\n\n
      Pour cette op\u00e9ration, j\u2019ai utilis\u00e9 WP-CLI<\/strong> plut\u00f4t qu\u2019un REPLACE()<\/code> SQL brut.<\/p>\n\n\n\n
      WordPress peut stocker certaines donn\u00e9es PHP sous forme s\u00e9rialis\u00e9e. Une modification SQL trop simple peut casser ces structures.<\/p>\n\n\n\n
      J\u2019ai donc commenc\u00e9 par un test sans modification :<\/p>\n\n\n\n
      wp search-replace \\\n  'http:\/\/127.0.0.1:8086' \\\n  'https:\/\/homelab.nvsd.ch' \\\n  --all-tables-with-prefix \\\n  --precise \\\n  --recurse-objects \\\n  --skip-columns=guid \\\n  --dry-run<\/code><\/pre>\n\n\n\n
      R\u00e9sultat :<\/p>\n\n\n\n
      Success: 23 replacements to be made.<\/code><\/pre>\n\n\n\n
      Les remplacements concernaient notamment :<\/p>\n\n\n\n
      wp_options\nwp_postmeta\nwp_posts\nwp_users<\/code><\/pre>\n\n\n\n
      Le dry-run \u00e9tant coh\u00e9rent, j\u2019ai ex\u00e9cut\u00e9 le remplacement r\u00e9el.<\/p>\n\n\n\n
      Les options principales sont alors devenues :<\/p>\n\n\n\n
      home    = https:\/\/homelab.nvsd.ch\nsiteurl = https:\/\/homelab.nvsd.ch<\/code><\/pre>\n\n\n\n
      \u00c9tape 8 \u2014 Basculer Nginx Proxy Manager<\/h2>\n\n\n\n
      Le domaine homelab.nvsd.ch<\/code> existait d\u00e9j\u00e0 dans Nginx Proxy Manager.<\/p>\n\n\n\n
      Je n\u2019ai pas cr\u00e9\u00e9 un nouveau Proxy Host. J\u2019ai simplement modifi\u00e9 la cible du host existant :<\/p>\n\n\n\n
      Scheme           : http\nForward Hostname : nvsd-homelab-wordpress\nForward Port     : 80<\/code><\/pre>\n\n\n\n
      Nginx Proxy Manager et WordPress sont tous deux connect\u00e9s au r\u00e9seau Docker proxy<\/code>.<\/p>\n\n\n\n
      Ils communiquent donc directement par leur nom de conteneur, sans devoir publier un port WordPress sur l\u2019h\u00f4te.<\/p>\n\n\n\n
      Le premier test public a retourn\u00e9 :<\/p>\n\n\n\n
      HTTP\/1.1 200 OK\nServer: openresty\nX-Powered-By: PHP\/8.3.31\nX-Served-By: homelab.nvsd.ch<\/code><\/pre>\n\n\n\n
      \u00c0 ce moment, le WordPress du VPS \u00e9tait r\u00e9ellement devenu la version de production.<\/p>\n\n\n\n
      \u00c9tape 9 \u2014 Supprimer le port WordPress temporaire<\/h2>\n\n\n\n
      Pendant les tests, WordPress utilisait encore temporairement un port publi\u00e9 sur le VPS.<\/p>\n\n\n\n
      Une fois Nginx Proxy Manager valid\u00e9, ce port n\u2019\u00e9tait plus n\u00e9cessaire.<\/p>\n\n\n\n
      Apr\u00e8s suppression du bloc ports:<\/code> dans le Compose, WordPress n\u2019affichait plus que :<\/p>\n\n\n\n
      80\/tcp<\/code><\/pre>\n\n\n\n
      et la commande :<\/p>\n\n\n\n
      docker port nvsd-homelab-wordpress<\/code><\/pre>\n\n\n\n
      ne retournait plus rien.<\/p>\n\n\n\n
      C\u2019est un point important : WordPress n\u2019est plus directement expos\u00e9 sur l\u2019h\u00f4te<\/strong>. Le trafic public passe obligatoirement par le reverse proxy.<\/p>\n\n\n\n
      \u00c9tape 10 \u2014 V\u00e9rifier la cha\u00eene compl\u00e8te<\/h2>\n\n\n\n
      J\u2019ai d\u2019abord test\u00e9 l\u2019acc\u00e8s depuis le r\u00e9seau Docker proxy<\/code> :<\/p>\n\n\n\n
      docker run --rm \\\n  --network proxy \\\n  curlimages\/curl:latest \\\n  -I \\\n  -H 'Host: homelab.nvsd.ch' \\\n  -H 'X-Forwarded-Proto: https' \\\n  http://nvsd-homelab-wordpress\/<\/code><\/pre>\n\n\n\n
      R\u00e9sultat :<\/p>\n\n\n\n
      HTTP\/1.1 200 OK<\/code><\/pre>\n\n\n\n
      Puis depuis l\u2019ext\u00e9rieur :<\/p>\n\n\n\n
      curl -IL https:\/\/homelab.nvsd.ch<\/code><\/pre>\n\n\n\n
      R\u00e9sultat :<\/p>\n\n\n\n
      HTTP\/1.1 200 OK<\/code><\/pre>\n\n\n\n
      La cha\u00eene compl\u00e8te \u00e9tait donc valid\u00e9e :<\/p>\n\n\n\n
      Internet\n   \u2193\nNginx Proxy Manager\n   \u2193\nWordPress\n   \u2193\nMariaDB<\/code><\/pre>\n\n\n\n
      \u00c9tape 11 \u2014 Cr\u00e9er une sauvegarde de la premi\u00e8re version de production<\/h2>\n\n\n\n
      Avant de commencer le nettoyage, j\u2019ai cr\u00e9\u00e9 une nouvelle sauvegarde de la version r\u00e9ellement mise en production.<\/p>\n\n\n\n
      Cette sauvegarde constitue maintenant un point de restauration clair comprenant :<\/p>\n\n\n\n
        \n
      • la base MariaDB ;<\/li>\n\n\n\n
      • les fichiers WordPress ;<\/li>\n\n\n\n
      • le th\u00e8me NVSD Homelab 2.1.2 ;<\/li>\n\n\n\n
      • le compose.yaml<\/code> ;<\/li>\n\n\n\n
      • le .env<\/code> prot\u00e9g\u00e9 ;<\/li>\n\n\n\n
      • les sommes SHA256 ;<\/li>\n\n\n\n
      • l\u2019\u00e9tat des conteneurs, r\u00e9seaux, volumes et images.<\/li>\n<\/ul>\n\n\n\n
        Je pr\u00e9f\u00e8re toujours sauvegarder l\u2019\u00e9tat valid\u00e9 avant de supprimer les ressources devenues inutiles<\/strong>.<\/p>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        \u00c9tape 12 \u2014 Nettoyer les anciens volumes Docker<\/h2>\n\n\n\n
        Apr\u00e8s la migration, quatre volumes WordPress existaient encore :<\/p>\n\n\n\n
        nvsd-homelab-wordpress_db_data\nnvsd-homelab-wordpress_wordpress_data\nnvsd_homelab_db_data\nnvsd_homelab_wordpress_data<\/code><\/pre>\n\n\n\n
        L\u2019inspection des montages des conteneurs a confirm\u00e9 que seuls :<\/p>\n\n\n\n
        nvsd_homelab_db_data\nnvsd_homelab_wordpress_data<\/code><\/pre>\n\n\n\n
        \u00e9taient r\u00e9ellement utilis\u00e9s.<\/p>\n\n\n\n
        Les anciens volumes ont alors \u00e9t\u00e9 supprim\u00e9s.<\/p>\n\n\n\n
        \u00c9tat final :<\/p>\n\n\n\n
        Local Volumes : 2\nActive        : 2\nReclaimable   : 0 B<\/code><\/pre>\n\n\n\n
        \u00c9tape 13 \u2014 Nettoyer les r\u00e9seaux devenus inutiles<\/h2>\n\n\n\n
        Le VPS contenait \u00e9galement plusieurs r\u00e9seaux cr\u00e9\u00e9s par d\u2019anciennes versions de stacks :<\/p>\n\n\n\n
        concerto-infini-phase9_default\ndockge_default\nnvsd_nvsd-net\nvilla_default\nvilla_nvsd-net\nvilla_proxy<\/code><\/pre>\n\n\n\n
        Avant toute suppression, j\u2019ai v\u00e9rifi\u00e9 qu\u2019aucun conteneur ne leur \u00e9tait encore attach\u00e9.<\/p>\n\n\n\n
        Ils ont ensuite \u00e9t\u00e9 supprim\u00e9s individuellement.<\/p>\n\n\n\n
        Les r\u00e9seaux restant correspondent maintenant aux services r\u00e9ellement actifs :<\/p>\n\n\n\n
        proxy\nnpm_default\nnvsd_homelab_internal\nfractal-studio\nconcerto-infini_default\nbridge\nhost\nnone<\/code><\/pre>\n\n\n\n
        \u00c9tape 14 \u2014 Supprimer les anciennes images<\/h2>\n\n\n\n
        La derni\u00e8re partie du nettoyage concernait les anciennes images Docker :<\/p>\n\n\n\n
        nvsd-homelab:latest\nconcerto-infini-phase9-web:latest\nconcerto-infini-phase9-api:latest\nportainer\/portainer-ce:lts\nhello-world:latest<\/code><\/pre>\n\n\n\n
        Elles n\u2019\u00e9taient plus utilis\u00e9es par aucun conteneur actif.<\/p>\n\n\n\n
        Je les ai donc supprim\u00e9es, puis j\u2019ai lanc\u00e9 :<\/p>\n\n\n\n
        docker image prune -f\ndocker builder prune -f<\/code><\/pre>\n\n\n\n
        Les images utilitaires comme :<\/p>\n\n\n\n
        wordpress:cli\ncurlimages\/curl\nalpine<\/code><\/pre>\n\n\n\n
        ont \u00e9t\u00e9 conserv\u00e9es, car elles restent pratiques pour la maintenance et les diagnostics.<\/p>\n\n\n\n
        \"Nettoyage<\/figure>\n\n\n\n
        L\u2019\u00e9tat final du VPS<\/h2>\n\n\n\n
        Apr\u00e8s migration et nettoyage, le VPS pr\u00e9sentait l\u2019\u00e9tat suivant :<\/p>\n\n\n\n
        Conteneurs       : 13 \/ 13 actifs\nVolumes          : 2 \/ 2 actifs\nWordPress        : op\u00e9rationnel\nMariaDB          : healthy\nHTTPS            : op\u00e9rationnel\nPort WordPress   : aucun port h\u00f4te publi\u00e9<\/code><\/pre>\n\n\n\n
        L\u2019organisation des principales stacks est d\u00e9sormais :<\/p>\n\n\n\n
        \/opt\/homelab\/stacks\/\n\u251c\u2500\u2500 concerto-infini\/\n\u251c\u2500\u2500 dockge\/\n\u251c\u2500\u2500 fractal-studio\/\n\u251c\u2500\u2500 npm\/\n\u251c\u2500\u2500 nvsd-homelab-wordpress\/\n\u251c\u2500\u2500 nvsd-villa\/\n\u2514\u2500\u2500 nvsd-web\/<\/code><\/pre>\n\n\n\n
        Cette structure est beaucoup plus lisible qu\u2019une accumulation de conteneurs, r\u00e9seaux et volumes cr\u00e9\u00e9s au fil des exp\u00e9rimentations.<\/p>\n\n\n\n
        Ce que cette migration m\u2019a appris<\/h2>\n\n\n\n
        Cette migration m\u2019a surtout rappel\u00e9 qu\u2019un d\u00e9placement WordPress ne se r\u00e9sume pas \u00e0 copier un dossier.<\/p>\n\n\n\n
        Il faut penser en m\u00eame temps \u00e0 :<\/p>\n\n\n\n
          \n
        • la base de donn\u00e9es ;<\/li>\n\n\n\n
        • les fichiers ;<\/li>\n\n\n\n
        • les m\u00e9dias ;<\/li>\n\n\n\n
        • les URL enregistr\u00e9es par WordPress ;<\/li>\n\n\n\n
        • les donn\u00e9es s\u00e9rialis\u00e9es ;<\/li>\n\n\n\n
        • les volumes Docker ;<\/li>\n\n\n\n
        • les r\u00e9seaux ;<\/li>\n\n\n\n
        • le reverse proxy ;<\/li>\n\n\n\n
        • HTTPS ;<\/li>\n\n\n\n
        • les sauvegardes ;<\/li>\n\n\n\n
        • le nettoyage des anciennes ressources.<\/li>\n<\/ul>\n\n\n\n
          Le plus important a \u00e9t\u00e9 de proc\u00e9der par petites \u00e9tapes et de valider chaque couche avant de continuer :<\/p>\n\n\n\n
          Sauvegarder\n    \u2193\nRestaurer\n    \u2193\nTester\n    \u2193\nChanger les URL\n    \u2193\nBasculer le proxy\n    \u2193\nValider HTTPS\n    \u2193\nFermer les ports inutiles\n    \u2193\nSauvegarder la production\n    \u2193\nNettoyer<\/code><\/pre>\n\n\n\n
          Cette m\u00e9thode m\u2019a permis de migrer le site sans perturber les autres services d\u00e9j\u00e0 pr\u00e9sents sur le VPS.<\/p>\n\n\n\n
          Conclusion<\/h2>\n\n\n\n
          Le site Homelab a maintenant franchi une \u00e9tape importante.<\/p>\n\n\n\n
          Il n\u2019est plus uniquement un projet d\u00e9velopp\u00e9 en local : il fait d\u00e9sormais lui-m\u00eame partie de l\u2019infrastructure qu\u2019il documente<\/strong>.<\/p>\n\n\n\n
          Le site d\u00e9crit mon Homelab, mais il est \u00e9galement h\u00e9berg\u00e9 par ce Homelab.<\/p>\n\n\n\n
          C\u2019est finalement assez repr\u00e9sentatif de la philosophie du projet : apprendre en construisant, documenter ce qui fonctionne, conserver les erreurs utiles et am\u00e9liorer progressivement l\u2019infrastructure.<\/p>\n\n\n\n
          La suite pourra maintenant se concentrer davantage sur les contenus et les r\u00e9alisations h\u00e9berg\u00e9es : Concerto \u00e0 l\u2019Infini, Fractal Studio et les prochains services du Homelab<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"
          Apr\u00e8s avoir construit et valid\u00e9 mon site Homelab en local, l\u2019\u00e9tape suivante \u00e9tait logique : le mettre r\u00e9ellement en production sur mon VPS. Je […]<\/p>\n","protected":false},"author":1,"featured_media":56,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32,45,31],"tags":[],"class_list":["post-51","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-docker-vps-securite","category-homelab","category-vps-securite"],"_links":{"self":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/51","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=51"}],"version-history":[{"count":2,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/51\/revisions"}],"predecessor-version":[{"id":57,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/posts\/51\/revisions\/57"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=\/wp\/v2\/media\/56"}],"wp:attachment":[{"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=51"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=51"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/homelab.nvsd.ch\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=51"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}