Regresar

Configuración básica de GitHub Actions para proyectos Nuxt

Deploy

24 de agosto de 2025

Subir cada cambio a mi portafolio antes implicaba conectarme al VPS, bajar los cambios, instalar dependencias y compilar el proyecto manualmente. Desde hace tiempo quería aprender a implementar CI/CD con GitHub Actions y hoy me decidí a hacerlo. Pensé que sería más complicado, pero resultó mucho más sencillo de lo esperado. De momento es una configuración básica para desplegar el frontend, pero ya es un hacia la automatización del flujo de trabajo.

Configuración SSH

Antes de crear el archivo del workflow, es necesario generar y registrar las llaves SSH de nuestro servidor. Para esto, me ubiqué en la carpeta ~/.ssh y ejecuté el siguiente comando:

ssh-keygen -t ed25519 -C "github-deploy" -f ./github_deploy_key

Con el fin de simplificar la configuración del workflow, estas llaves SSH no tendrán passphrase.

Una vez generadas, debemos copiar el contenido de la llave pública en el archivo ~/.ssh/authorized_keys.
En caso de que este archivo no exista, podemos crearlo manualmente:

cat github_deploy_key.pub >> ~/.ssh/authorized_keys

En mi caso, el VPS ya contaba con una llave SSH previamente configurada.
Por esta razón, fue necesario agregar la nueva llave al archivo ~/.ssh/config y asignarle un alias para diferenciarla de la anterior.

Un ejemplo de configuración sería:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519


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

De esta manera, podemos conectarnos fácilmente utilizando el alias github-deploy sin tener que especificar toda la ruta de la llave en cada conexión.

Finalmente, actualicé la configuración del remote origin en mi repositorio para que utilice ese alias:

git remote set-url origin git@github-deploy:CarlosMateoM/mateo-martinez-dev.git

Configuración de secretos y llave ssh

El siguiente paso consistió en configurar la llave privada y los secretos en GitHub.

Se copió el contenido de la llave privada y se agregó en la sección de Deploy Keys del repositorio en GitHub, habilitando la opción de Allow write access para que el workflow pudiera hacer push si era necesario.

En la sección de Secrets and variables → Actions de GitHub, se agregaron las siguientes variables:

github-secrets.png

  • VPS_USER → Usuario con el que se realizó la conexión al servidor.

  • VPS_HOST → Dirección IP o dominio del servidor.

  • VPS_KEY → Contenido completo de la llave privada.

Esto permitió que el workflow tuviera acceso seguro al servidor sin necesidad de contraseñas, usando la llave SSH que se configuró previamente.

Creación del flujo de trabajo en GitHub Actions

El siguiente paso fue dirigirnos a Actions → New workflow y escribir el flujo de trabajo encargado del despliegue:

name: Deploy Nuxt App

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to VPS
        uses: appleboy/ssh-action@v0.1.10
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_KEY }}
          script: |
           export PATH=$HOME/.nvm/versions/node/v20.18.0/bin:$PATH
            cd /var/www/mateo/mateo-martinez-dev
            git pull origin main
            npm install 
            npm run build
            pm2 reload mateo-web

Este flujo de trabajo se ejecutó cada vez que se realizaba un push en la rama main, conectándose al servidor por SSH, actualizando el código, instalando dependencias, construyendo la aplicación y recargando el proceso con PM2.

Cabe aclarar que yo ya tenía configurado previamente pm2 con el proceso que ejecutaba mi aplicación. Además, la configuración del PATH fue necesaria debido a que no tenía instalado globalmente npm ni pm2.

Finalmente se guardan los cambios y se verifica que la configuración haya funcionado correctemente:

github-action-deply.png

El animarme a implementar este flujo de despliegue automatizado me permitió agilizar el trabajo al subir nuevos cambios en mi portafolio. Aunque fue un primer paso y algo inicial, me ayudó bastante a ahorrar tiempo y a simplificar el proceso de actualización de la aplicación.