bolt Valebyte VPS desde $4/mes — NVMe, despliegue en 60s.

Obtener VPS arrow_forward
eco Principiante Tutorial/Cómo hacer

Despliegue de Wiki.js

calendar_month Jun 12, 2026 schedule 21 min de lectura visibility 23 vistas
Развёртывание Wiki.js на VPS: установка с Docker Compose, PostgreSQL и Nginx Proxy
info

¿Necesitas un servidor para esta guía? Ofrecemos servidores dedicados y VPS en más de 50 países con configuración instantánea.

¿Necesitas un VPS para esta guía?

Explore otras opciones de servidores dedicados en

Despliegue de Wiki.js en un VPS: instalación con Docker Compose, PostgreSQL y Nginx Proxy

TL;DR

En esta guía detallada, configuraremos paso a paso el moderno y potente sistema wiki Wiki.js en su propio VPS. Aprenderá a usar Docker Compose para orquestar servicios, incluyendo la base de datos PostgreSQL y el proxy inverso Nginx Proxy Manager con emisión automática de certificados SSL Let's Encrypt, asegurando un acceso seguro y escalable a su documentación o conocimiento.

  • Configuración de un VPS seguro y optimizado con Ubuntu 24.04 LTS.
  • Instalación de Docker y Docker Compose para la contenerización de aplicaciones.
  • Despliegue de Wiki.js, PostgreSQL y Nginx Proxy Manager usando un único archivo docker-compose.yml.
  • Configuración automática de HTTPS a través de Let's Encrypt para Wiki.js.
  • Creación de una estrategia de copia de seguridad eficiente para los datos de Wiki.js y PostgreSQL.
  • Resolución de problemas comunes y optimización del rendimiento.

Qué configuramos y por qué

Схема: Что мы настраиваем и зачем
Esquema: Qué configuramos y por qué

En esta guía, desplegaremos Wiki.js, un sistema wiki moderno, potente y flexible, diseñado para el trabajo en equipo, la documentación de proyectos, la creación de bases de conocimiento o notas personales. Wiki.js ofrece una interfaz de usuario intuitiva, soporte para varios editores (Markdown, AsciiDoc, WYSIWYG), integración con servicios de autenticación externos (LDAP, OAuth, SAML) y amplias opciones de configuración. Es una solución ideal para desarrolladores, startups y cualquiera que necesite un repositorio de información centralizado y de fácil acceso.

Al final, obtendrá un sistema wiki completamente funcional, accesible a través de su nombre de dominio mediante HTTPS, ejecutándose en contenedores aislados en su VPS. Esto garantizará alta estabilidad, seguridad y facilidad de mantenimiento. Todos los componentes —Wiki.js, la base de datos PostgreSQL y el proxy inverso Nginx Proxy Manager— serán gestionados con Docker Compose, lo que simplifica enormemente su despliegue y escalado.

Existen varios enfoques para crear bases de conocimiento. Se pueden utilizar servicios en la nube como Notion, Confluence Cloud, GitBook o incluso Google Docs. Estas soluciones ofrecen la comodidad de una solución "llave en mano" con un esfuerzo mínimo de administración. Sin embargo, a menudo implican un modelo de suscripción, limitaciones de funcionalidad o volumen de datos, así como problemas de privacidad, ya que sus datos se almacenan en servidores de terceros. Para equipos pequeños o proyectos personales, las tarifas mensuales pueden ser prohibitivamente altas y el control sobre los datos insuficiente.

El alojamiento propio (self-hosted) de Wiki.js en un VPS proporciona control total sobre los datos, la seguridad y la configuración. No depende de los planes de precios de terceros proveedores, puede personalizar el sistema según sus necesidades únicas y tener confianza en la confidencialidad de la información. Además, es una excelente oportunidad para profundizar sus conocimientos en administración de servidores y contenerización, una habilidad valiosa para cualquier especialista técnico.

Qué configuración de VPS se necesita para esta tarea

Схема: Какой VPS-конфиг нужен под эту задачу
Esquema: Qué configuración de VPS se necesita para esta tarea

La elección de una configuración de VPS adecuada es crucial para el funcionamiento estable y rápido de Wiki.js. Aunque Wiki.js es bastante ligero, la base de datos y el proxy inverso también consumen recursos. Nos basaremos en los requisitos actuales para 2026, considerando el aumento de la complejidad de las aplicaciones web y los sistemas operativos.

Requisitos mínimos

  • CPU: 2 núcleos. Los procesadores modernos con una frecuencia de reloj de 2.5 GHz o superior garantizarán una buena capacidad de respuesta. Un solo núcleo puede ser suficiente para instalaciones muy pequeñas (1-2 usuarios), pero para un funcionamiento estable y el procesamiento de tareas en segundo plano (búsqueda, indexación), es mejor tener dos.
  • RAM: 2 GB. Esto será suficiente para Wiki.js, PostgreSQL y Nginx Proxy Manager. Wiki.js por sí mismo puede consumir 300-500 MB, PostgreSQL — 200-400 MB, además del SO y el demonio Docker. Si se planea un uso activo o un gran número de artículos, es mejor considerar 4 GB.
  • Disco: 40 GB SSD. El SSD es críticamente importante para el rendimiento de la base de datos y la velocidad de carga de las páginas. 40 GB proporcionarán espacio para el sistema operativo, las imágenes de Docker, los datos de Wiki.js y posibles copias de seguridad. Si planea almacenar muchas imágenes o archivos en el wiki, considere 80-100 GB.
  • Red: Canal simétrico de 100 Mbps. Para la mayoría de los casos, esto es más que suficiente. Más importante es la estabilidad del canal y un ping bajo.

Plan de VPS específico para la tarea

Para el despliegue de Wiki.js con Docker Compose, PostgreSQL y Nginx Proxy Manager, la configuración óptima será la siguiente:

  • CPU: 2-4 vCPU (núcleos virtuales)
  • RAM: 4 GB
  • Disco: 80 GB NVMe SSD (preferible) o un SATA SSD de alto rendimiento
  • Red: Canal garantizado de 200-500 Mbps

Esta configuración será suficiente para un equipo de 10-30 usuarios activos, con la capacidad de almacenar miles de páginas y cientos de archivos multimedia. Para un funcionamiento estable, se puede considerar un VPS con las características indicadas.

Cuándo se necesita un servidor dedicado y no un VPS

Un servidor dedicado se vuelve necesario en los siguientes casos:

  • Carga muy alta: Si su Wiki.js va a atender a cientos o miles de usuarios simultáneos, procesar enormes volúmenes de datos, o si planea alojar otras aplicaciones que consumen muchos recursos en el mismo servidor.
  • Requisitos estrictos de rendimiento: Para aplicaciones críticas en cuanto a latencia o que requieren el máximo rendimiento del subsistema de disco (por ejemplo, grandes bases de datos con alta frecuencia de escritura/lectura).
  • Hardware especializado: Si necesita componentes de hardware específicos, como GPU para aprendizaje automático, controladores RAID para una mayor tolerancia a fallos de disco, o grandes volúmenes de memoria RAM (a partir de 64 GB).
  • Control total sobre el hardware: Un servidor dedicado ofrece control físico total sobre el hardware, lo que puede ser importante para ciertas tareas específicas o políticas de seguridad.

Para la mayoría de las instalaciones de Wiki.js, un VPS será más que suficiente y económicamente ventajoso. Si tiene dudas, comience con un VPS y escale a un dedicado cuando surja una necesidad real. Para proyectos muy grandes, se puede considerar un servidor dedicado adecuado.

Ubicación: en qué influye

La elección de la ubicación del VPS influye en varios factores clave:

  • Latencia (Latency/Ping): Cuanto más cerca esté el servidor de sus usuarios principales, menor será el ping y más rápida la carga de las páginas. Para un equipo que trabaja en una misma ciudad/región, elija un servidor en esa misma región. Para equipos distribuidos, elija una ubicación central o utilice una CDN (Content Delivery Network).
  • Legislación: Las leyes sobre almacenamiento de datos y privacidad pueden variar mucho según el país. Asegúrese de que la ubicación elegida cumpla con los requisitos de su negocio o sus preferencias personales.
  • Costo: Los precios de los VPS pueden variar según la ubicación debido a las diferencias en el costo de la electricidad, la infraestructura y los impuestos.

Elija siempre la ubicación que esté lo más cerca posible de la mayoría de sus usuarios para garantizar la mejor experiencia de usuario.

Preparación del servidor

Схема: Подготовка сервера
Esquema: Preparación del servidor

Antes de proceder con la instalación de Wiki.js, es necesario realizar la configuración básica y fortalecer la seguridad de su VPS. Utilizaremos Ubuntu 24.04 LTS (Noble Numbat), actual para 2026, como base para nuestro servidor.

1. Conexión al servidor y actualización del sistema

Conéctese a su servidor por SSH, utilizando los datos proporcionados por su proveedor de VPS. Normalmente, esto incluye la dirección IP, el nombre de usuario (root) y la contraseña.


ssh root@ВАШ_IP_АДРЕС_VPS

Después de iniciar sesión con éxito, actualice la lista de paquetes y los paquetes instalados a las últimas versiones.


sudo apt update && sudo apt upgrade -y

Esto asegurará que todos los componentes del sistema estén actualizados y contengan las últimas correcciones de seguridad.

2. Creación de un nuevo usuario con permisos sudo

Trabajar como usuario root no es seguro. Crearemos un nuevo usuario y le otorgaremos permisos sudo.


sudo adduser wikiuser

Siga las instrucciones en pantalla para establecer la contraseña y la información del usuario. Luego, añada el usuario al grupo sudo.


sudo usermod -aG sudo wikiuser

Ahora puede cambiar al nuevo usuario y continuar trabajando.


su - wikiuser

O abrir una nueva sesión SSH con este usuario.


ssh wikiuser@ВАШ_IP_АДРЕС_VPS

3. Configuración de autenticación por claves SSH (recomendado)

Para mejorar la seguridad, se recomienda usar claves SSH en lugar de contraseñas. Genere un par de claves en su máquina local, si aún no las tiene.


# En su máquina local
ssh-keygen -t rsa -b 4096

Luego, copie la clave pública al servidor para el usuario wikiuser.


# En su máquina local
ssh-copy-id wikiuser@ВАШ_IP_АДРЕС_VPS

Después de esto, desactive la autenticación por contraseña para SSH. Edite el archivo /etc/ssh/sshd_config.


sudo nano /etc/ssh/sshd_config

Encuentre y modifique las siguientes líneas (o añádalas si no existen):


PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no

Reinicie el servicio SSH.


sudo systemctl restart sshd

Ahora podrá conectarse solo con claves SSH, y el usuario root no podrá iniciar sesión directamente.

4. Configuración del firewall (UFW)

UFW (Uncomplicated Firewall) es una interfaz fácil de usar para configurar reglas de iptables. Permitiremos solo los puertos necesarios.


sudo apt install ufw -y # Instalación de UFW, si aún no está instalado
sudo ufw default deny incoming # Denegar todas las conexiones entrantes por defecto
sudo ufw default allow outgoing # Permitir todas las conexiones salientes por defecto
sudo ufw allow ssh # Permitir SSH (puerto 22)
sudo ufw allow http # Permitir HTTP (puerto 80)
sudo ufw allow https # Permitir HTTPS (puerto 443)
sudo ufw enable # Habilitar el firewall
sudo ufw status verbose # Verificar el estado del firewall

Ahora su servidor está protegido contra conexiones entrantes no deseadas.

5. Instalación de Fail2Ban

Fail2Ban escanea los registros en busca de actividad sospechosa (por ejemplo, múltiples intentos fallidos de inicio de sesión SSH) y bloquea automáticamente las direcciones IP de los atacantes. Esto es una capa adicional de protección.


sudo apt install fail2ban -y
sudo systemctl enable fail2ban # Habilitar el inicio automático de Fail2Ban al arrancar el sistema
sudo systemctl start fail2ban # Iniciar Fail2Ban

Fail2Ban está configurado por defecto para proteger SSH. Puede verificar su estado:


sudo fail2ban-client status
sudo fail2ban-client status sshd

Con esto, la preparación básica del servidor ha finalizado. Ahora se puede proceder con la instalación del software.

Instalación de software — paso a paso

Diagrama: Instalación de software — paso a paso
Diagrama: Instalación de software — paso a paso

Usaremos Docker y Docker Compose para desplegar Wiki.js, PostgreSQL y Nginx Proxy Manager. Esto proporciona aislamiento de aplicaciones, simplifica la gestión de dependencias y facilita la escalabilidad.

1. Instalación de Docker Engine

Primero, instalaremos los paquetes necesarios para Docker.


sudo apt update # Actualizar la lista de paquetes
sudo apt install ca-certificates curl gnupg lsb-release -y # Instalar dependencias

Añadiremos la clave GPG oficial de Docker.


sudo install -m 0755 -d /etc/apt/keyrings # Crear directorio para las claves, si no existe
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # Descargar y añadir la clave GPG
sudo chmod a+r /etc/apt/keyrings/docker.gpg # Establecer los permisos correctos

Añadiremos el repositorio de Docker a las fuentes de APT.


echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Actualizaremos la lista de paquetes de nuevo e instalaremos Docker Engine, Docker CLI y containerd.


sudo apt update # Actualizar la lista de paquetes después de añadir el repositorio
sudo apt install docker-ce docker-ce-cli containerd.io -y # Instalar Docker Engine (la versión será la actual para 2026, por ejemplo, 25.0.x o 26.0.x)

Verificaremos el estado del servicio Docker.


sudo systemctl status docker # Asegurarse de que Docker está en ejecución y activo

Añadiremos su usuario al grupo docker para no tener que usar sudo con cada comando de Docker.


sudo usermod -aG docker ${USER} # Añadir el usuario actual al grupo docker
newgrp docker # Aplicar los cambios de grupo sin cerrar sesión (o simplemente reinicie la sesión SSH)

Verificaremos la instalación de Docker ejecutando un contenedor de prueba.


docker run hello-world # Ejecutar un contenedor de prueba para verificar la instalación de Docker

2. Instalación de Docker Compose

Docker Compose es una herramienta para definir y ejecutar aplicaciones Docker multicontenedor. Lo instalaremos como un plugin de Docker CLI.


sudo apt install docker-compose-plugin -y # Instalar Docker Compose como plugin para Docker CLI (la versión será la actual para 2026)

Verificaremos la versión de Docker Compose.


docker compose version # Verificar que Docker Compose está instalado correctamente

3. Preparación de la estructura de directorios

Crearemos un directorio para nuestro proyecto Wiki.js y subdirectorios para los datos.


mkdir -p ~/wiki # Crear el directorio principal para el proyecto
cd ~/wiki # Navegar al directorio creado
mkdir -p data/wiki # Directorio para los datos de Wiki.js (archivos, uploads)
mkdir -p data/db # Directorio para los datos de PostgreSQL

4. Creación del archivo docker-compose.yml

Este archivo definirá nuestros servicios: Wiki.js, PostgreSQL y Nginx Proxy Manager.


nano docker-compose.yml # Abrir el editor para crear el archivo

Pegue el siguiente contenido (las versiones de imagen actuales se seleccionarán para 2026):


version: '3.8'

services:
  wiki:
    image: ghcr.io/requarks/wiki:2.5.300 # Versión estable actual de Wiki.js para 2026
    container_name: wiki-js
    restart: unless-stopped
    environment:
      NODE_ENV: production
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikiuser
      DB_PASS: ${DB_PASSWORD} # Contraseña de .env
      DB_NAME: wiki
      DB_SSL: 'false' # Usar SSL solo si la base de datos está en un servidor separado o en otra red Docker
      # Дополнительные настройки Wiki.js, например, URL
      WIKI_URL: https://wiki.example.com # Reemplace con su dominio
    volumes:
      - ./data/wiki:/var/wiki # Guardamos los datos de Wiki.js en el host
    depends_on:
      - db
    networks:
      - wiki-network
      - npm-network # Сеть для Nginx Proxy Manager

  db:
    image: postgres:16-alpine # Versión estable actual de PostgreSQL para 2026
    container_name: wiki-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikiuser
      POSTGRES_PASSWORD: ${DB_PASSWORD} # Contraseña de .env
    volumes:
      - ./data/db:/var/lib/postgresql/data # Guardamos los datos de la BD en el host
    networks:
      - wiki-network

  npm:
    image: 'jc21/nginx-proxy-manager:latest' # Nginx Proxy Manager (la versión será la actual para 2026)
    container_name: nginx-proxy-manager
    restart: unless-stopped
    ports:
      - '80:80' # Puerto HTTP para Let's Encrypt y redirección
      - '443:443' # Puerto HTTPS
      - '81:81' # Puerto para el panel de administración de Nginx Proxy Manager
    volumes:
      - ./data/npm/data:/data # Datos de Nginx Proxy Manager
      - ./data/npm/letsencrypt:/etc/letsencrypt # Certificados Let's Encrypt
    networks:
      - npm-network

networks:
  wiki-network:
    driver: bridge
  npm-network:
    driver: bridge

Guarde el archivo (Ctrl+O, Enter, Ctrl+X).

5. Creación del archivo .env para secretos

Para almacenar contraseñas y otros datos sensibles, usaremos el archivo .env, que Docker Compose carga automáticamente.


nano .env # Abrir el editor para crear el archivo

Pegue el siguiente contenido, reemplazando YOUR_STRONG_DB_PASSWORD por una contraseña segura.


DB_PASSWORD=YOUR_STRONG_DB_PASSWORD_12345

Guarde el archivo (Ctrl+O, Enter, Ctrl+X). Asegúrese de que el archivo .env no se añada al sistema de control de versiones si utiliza Git.

6. Inicio de los servicios de Docker Compose

Ahora que todos los archivos están listos, podemos iniciar nuestros servicios.


docker compose up -d # Iniciar todos los servicios en segundo plano

Este comando descargará las imágenes Docker necesarias (Wiki.js, PostgreSQL, Nginx Proxy Manager), creará los contenedores y los iniciará. El proceso puede tardar varios minutos dependiendo de la velocidad de su conexión a internet.

Verificaremos el estado de los contenedores en ejecución.


docker compose ps # Mostrar el estado de los contenedores en ejecución

Debería ver que los tres contenedores (wiki-js, wiki-db, nginx-proxy-manager) están en estado running.

En este punto, los componentes principales están instalados y en ejecución. A continuación, pasaremos a su configuración.

Configuración

Diagrama: Configuración
Diagrama: Configuración

Después de instalar los contenedores, es necesario configurar Nginx Proxy Manager para enrutar el tráfico a Wiki.js y obtener un certificado SSL, así como realizar la configuración inicial de Wiki.js.

1. Configuración de Nginx Proxy Manager

Nginx Proxy Manager (NPM) proporciona una interfaz web conveniente para gestionar el proxy inverso y los certificados SSL de Let's Encrypt. Se accede al panel de administración de NPM a través del puerto 81 de su VPS.

Abra en el navegador: http://SU_DIRECCIÓN_IP_VPS:81

Primer inicio de sesión

Al iniciar sesión por primera vez, se le ofrecerán las credenciales predeterminadas:

Después de iniciar sesión, el sistema le pedirá que cambie estos datos. Asegúrese de establecer una contraseña segura y su correo electrónico real.

Añadir host proxy para Wiki.js

Vaya a la sección "Hosts" -> "Proxy Hosts" y haga clic en "Add Proxy Host".

  • Nombres de dominio: wiki.example.com (reemplace con su dominio real, que haya configurado en los registros DNS, apuntando a la IP de su VPS).
  • Esquema: http
  • Nombre de host / IP de reenvío: wiki-js (este es el nombre del servicio Wiki.js del archivo docker-compose.yml)
  • Puerto de reenvío: 3000 (puerto estándar de Wiki.js)
  • Bloquear exploits comunes: Habilite (recomendado)
  • Soporte para Websockets: Habilite (obligatorio para Wiki.js)

Vaya a la pestaña "SSL".

  • Certificado SSL: Seleccione "Solicitar un nuevo certificado SSL".
  • Forzar SSL: Habilite.
  • Dirección de correo electrónico para Let's Encrypt: Introduzca su correo electrónico.
  • Acepto los Términos de Servicio de Let's Encrypt: Marque.

Haga clic en "Guardar". NPM intentará obtener un certificado SSL para su dominio. Asegúrese de que el registro DNS (tipo A) para wiki.example.com apunte a la dirección IP de su VPS antes de comenzar este paso.

Después de obtener el certificado con éxito, su Wiki.js estará disponible a través de HTTPS.

2. Configuración inicial de Wiki.js

Ahora abra su dominio en el navegador: https://wiki.example.com

Wiki.js le pedirá que complete el proceso de configuración inicial.

  • Tipo de base de datos: PostgreSQL (debería estar seleccionado por defecto)
  • Host de la base de datos: db
  • Puerto de la base de datos: 5432
  • Nombre de la base de datos: wiki
  • Usuario de la base de datos: wikiuser
  • Contraseña de la base de datos: Introduzca la misma contraseña que especificó en el archivo .env (DB_PASSWORD).

Haga clic en "Conectar". Wiki.js verificará la conexión con la base de datos.

A continuación, se le pedirá que cree una cuenta de administrador de Wiki.js:

  • Correo electrónico: Introduzca su correo electrónico.
  • Contraseña: Establezca una contraseña segura para el administrador de Wiki.js.
  • Nombre: Su nombre.

Complete la instalación. Después de esto, será redirigido a la página de inicio de sesión de Wiki.js.

3. Verificación del funcionamiento

Después de todas las configuraciones, nos aseguraremos de que todo funciona correctamente.

Verificación de contenedores

docker compose ps # Asegurarse de que todos los contenedores están en ejecución

Todos los contenedores deben estar en estado running.

Verificación de los logs de Wiki.js

docker compose logs wiki # Ver los logs del contenedor Wiki.js

Asegúrese de que no hay errores críticos y que Wiki.js se ha conectado correctamente a la base de datos.

Verificación de la accesibilidad a través de curl

Realice una solicitud a su dominio desde el servidor para asegurarse de que Nginx Proxy Manager está reenviando el tráfico.


curl -I https://wiki.example.com # Reemplace con su dominio

Debería ver los encabezados HTTP que indican una respuesta exitosa (por ejemplo, HTTP/2 200).

En este punto, su Wiki.js está completamente configurado y accesible a través de HTTPS. Puede empezar a crear páginas e invitar a usuarios.

Copias de seguridad y mantenimiento

Esquema: Copias de seguridad y mantenimiento
Esquema: Copias de seguridad y mantenimiento

Las copias de seguridad regulares y el mantenimiento oportuno son aspectos clave para garantizar la fiabilidad y disponibilidad de su Wiki.js. La pérdida de datos puede ser catastrófica, por lo que es importante tener una estrategia de copias de seguridad probada.

Qué respaldar

Para Wiki.js, es necesario respaldar dos componentes principales:

  1. Base de datos PostgreSQL: Contiene todos los artículos, usuarios, configuraciones y metadatos de Wiki.js. Este es el componente más crítico.
  2. Archivos de Wiki.js: Incluyen imágenes subidas, archivos, y potencialmente temas o plugins personalizados. En nuestro caso, es el directorio ./data/wiki en el host.
  3. Configuración de Nginx Proxy Manager: Aunque NPM se puede configurar de nuevo, una copia de seguridad de sus datos (certificados, configuraciones de proxy) acelerará significativamente la recuperación. Este es el directorio ./data/npm en el host.

Script sencillo de copia de seguridad automática

Crearemos un script sencillo que realizará una copia de seguridad de la base de datos y los archivos, y luego los archivará. Para el almacenamiento, se puede usar un disco local y luego transferirlo a un almacenamiento remoto.

Cree un directorio para las copias de seguridad en el servidor, por ejemplo, /var/backups/wiki.


sudo mkdir -p /var/backups/wiki
sudo chown wikiuser:wikiuser /var/backups/wiki # Otorgar permisos a su usuario

Cree el archivo de script backup_wiki.sh en el directorio personal del usuario wikiuser:


nano ~/backup_wiki.sh

Pegue el siguiente contenido:


#!/bin/bash

# --- Configuración ---
BACKUP_DIR="/var/backups/wiki"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
COMPOSE_PROJECT_DIR="/home/wikiuser/wiki" # Ruta a su directorio docker-compose.yml
DB_CONTAINER_NAME="wiki-db"
DB_USER="wikiuser"
DB_NAME="wiki"
WIKI_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/wiki"
NPM_DATA_DIR="${COMPOSE_PROJECT_DIR}/data/npm"
RETENTION_DAYS=7 # Cuántos días conservar las copias de seguridad

# --- Verificación del directorio de copias de seguridad ---
if [ ! -d "$BACKUP_DIR" ]; then
  echo "El directorio de copias de seguridad $BACKUP_DIR no existe. Creando..."
  sudo mkdir -p "$BACKUP_DIR"
  sudo chown wikiuser:wikiuser "$BACKUP_DIR"
fi

echo "Iniciando el proceso de copia de seguridad de Wiki.js en $TIMESTAMP"

# --- 1. Copia de seguridad de la base de datos PostgreSQL ---
echo "Copia de seguridad de la base de datos PostgreSQL..."
docker exec $DB_CONTAINER_NAME pg_dump -U $DB_USER -d $DB_NAME > "$BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
if [ $? -eq 0 ]; then
  echo "Copia de seguridad de la BD creada con éxito: $BACKUP_DIR/wiki_db_$TIMESTAMP.sql"
else
  echo "ERROR: No se pudo crear la copia de seguridad de la BD."
  exit 1
fi

# --- 2. Copia de seguridad de los archivos de Wiki.js y Nginx Proxy Manager ---
echo "Archivando datos de Wiki.js y NPM..."
tar -czf "$BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz" -C "$WIKI_DATA_DIR" .
if [ $? -eq 0 ]; then
  echo "Archivo de datos de Wiki.js creado con éxito: $BACKUP_DIR/wiki_data_$TIMESTAMP.tar.gz"
else
  echo "ERROR: No se pudo crear el archivo de datos de Wiki.js."
  exit 1
fi

tar -czf "$BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz" -C "$NPM_DATA_DIR" .
if [ $? -eq 0 ]; then
  echo "Archivo de datos de NPM creado con éxito: $BACKUP_DIR/npm_data_$TIMESTAMP.tar.gz"
else
  echo "ERROR: No se pudo crear el archivo de datos de NPM."
  exit 1
fi

# --- 3. Eliminación de copias de seguridad antiguas ---
echo "Eliminando copias de seguridad antiguas (más de $RETENTION_DAYS días)..."
find "$BACKUP_DIR" -type f -name "wiki_db_*.sql" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "wiki_data_*.tar.gz" -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR" -type f -name "npm_data_*.tar.gz" -mtime +$RETENTION_DAYS -delete
echo "Limpieza de copias de seguridad antiguas completada."

echo "Proceso de copia de seguridad completado."

Haga el script ejecutable:


chmod +x ~/backup_wiki.sh

Puede probar el script manualmente:


~/backup_wiki.sh

Automatización de copias de seguridad con Cron

Para iniciar automáticamente el script de copia de seguridad, configuraremos Cron. Por ejemplo, para una copia de seguridad diaria a las 03:00 de la madrugada:


crontab -e

Añada la siguiente línea al final del archivo:


0 3 * * * /home/wikiuser/backup_wiki.sh >> /var/log/wiki_backup.log 2>&1

Esta línea ejecuta el script cada día a las 03:00 y redirige la salida al archivo de registro /var/log/wiki_backup.log.

Dónde almacenar las copias de seguridad (almacenamiento externo)

Almacenar las copias de seguridad en el mismo servidor que los datos de producción no proporciona una protección completa. En caso de fallo del VPS, perderá tanto los datos como las copias de seguridad. Se recomienda utilizar almacenamiento externo:

  • Almacenamiento compatible con S3: Servicios en la nube como AWS S3, Backblaze B2, DigitalOcean Spaces, proporcionan almacenamiento fiable y económico. Puede usar utilidades como s3cmd, rclone o aws cli para sincronizar automáticamente las copias de seguridad locales con S3.
  • VPS separado: Puede configurar un segundo VPS, menos potente, y usar rsync o scp para copiar las copias de seguridad a él. Esto proporciona una separación geográfica.
  • Almacenamiento en red (NAS): Si tiene su propio almacenamiento en red, puede configurar el montaje a través de NFS/SMB y copiar las copias de seguridad allí.

Extienda el script backup_wiki.sh para cargar automáticamente las copias de seguridad al almacenamiento externo seleccionado después de su creación.

Actualizaciones: continuas vs. ventana de mantenimiento

Mantener el software actualizado es crucial para la seguridad y para obtener nuevas funcionalidades.

  • Actualización de imágenes Docker (Wiki.js, PostgreSQL, Nginx Proxy Manager):
    • Ventana de mantenimiento: Este es el enfoque recomendado. Asigne un tiempo específico (por ejemplo, una vez al mes) para detener los servicios, actualizar las imágenes y realizar pruebas.
      
      cd ~/wiki # Vaya al directorio con docker-compose.yml
      docker compose pull # Descargar las últimas versiones de las imágenes
      docker compose down # Detener y eliminar los contenedores actuales
      docker compose up -d # Iniciar nuevos contenedores con las imágenes actualizadas
      
    • Pruebas: Siempre verifique la funcionalidad de Wiki.js después de una actualización. Las nuevas versiones pueden contener cambios que requieran adaptación manual, aunque esto es raro para versiones menores.
  • Actualización del SO (Ubuntu):
    • Cada pocos meses, realice una actualización completa del sistema: sudo apt update && sudo apt upgrade -y. Esto también es mejor hacerlo en una "ventana de mantenimiento", ya que puede requerir un reinicio del servidor.

Evite las "actualizaciones continuas" para sistemas de producción sin la automatización y pruebas adecuadas, ya que esto puede llevar a tiempos de inactividad inesperados.

Solución de problemas + Preguntas frecuentes

En esta sección, abordaremos problemas comunes que pueden surgir al implementar Wiki.js y proporcionaremos respuestas a preguntas frecuentes.

No se puede conectar a Wiki.js por nombre de dominio (error 502 Bad Gateway o Connection Refused)

Qué verificar:

  1. Registro DNS: Asegúrese de que su registro A para wiki.example.com (o su dominio) apunte correctamente a la dirección IP de su VPS. Use dig wiki.example.com o nslookup wiki.example.com.
  2. Contenedores Docker: Verifique que todos los contenedores (wiki-js, wiki-db, nginx-proxy-manager) estén iniciados y en estado "running".
    
    docker compose ps
                
  3. Registros de Nginx Proxy Manager: Revise los registros de NPM en busca de errores.
    
    docker compose logs npm
                
    Los errores relacionados con Let's Encrypt a menudo indican problemas con el DNS o el firewall.
  4. Configuración de Proxy Host en NPM: Asegúrese de que "Forward Hostname / IP" esté configurado como wiki-js y "Forward Port" como 3000. También verifique si la opción "Websockets Support" está habilitada.
  5. Firewall (UFW): Asegúrese de que los puertos 80 y 443 estén abiertos.
    
    sudo ufw status verbose
                

Cómo solucionar: Corrija el registro DNS, reinicie los contenedores si se han caído, o ajuste la configuración en NPM y el firewall.

Wiki.js no puede conectarse a la base de datos (error "Database connection failed")

Qué verificar:

  1. Registros de Wiki.js: Revise los registros del contenedor Wiki.js.
    
    docker compose logs wiki
                
    Busque mensajes de error de conexión a la BD.
  2. Contenedor de la base de datos: Asegúrese de que el contenedor wiki-db esté iniciado y que no haya errores en sus registros.
    
    docker compose logs db
                
  3. Variables de entorno: Revise el archivo .env y la sección environment para el servicio wiki en docker-compose.yml. Asegúrese de que DB_HOST esté configurado como db, y que DB_USER, DB_PASS y DB_NAME coincidan con los datos utilizados en PostgreSQL.
  4. Contraseña: Asegúrese de que la contraseña en .env coincida exactamente con la que introdujo durante la configuración inicial de Wiki.js.

Cómo solucionar: Corrija errores tipográficos en las variables de entorno o la contraseña. Si ha modificado .env o docker-compose.yml, deberá reiniciar los servicios: docker compose down && docker compose up -d.

¿Qué configuración mínima de VPS es adecuada?

Para un equipo pequeño (hasta 5-10 personas) o uso personal, un VPS con 2 vCPU, 2 GB de RAM y 40 GB de SSD será mínimamente suficiente. Esto será suficiente para el funcionamiento estable de Wiki.js, PostgreSQL y Nginx Proxy Manager. Sin embargo, si planea un uso activo, almacenar una gran cantidad de archivos multimedia o el crecimiento del equipo, se recomienda considerar de inmediato una configuración con 4 GB de RAM y 80 GB de SSD. Esto proporcionará una mejor reserva de rendimiento y reducirá la probabilidad de ralentizaciones en el futuro.

¿Qué elegir — VPS o dedicado para esta tarea?

Para la implementación de Wiki.js, un VPS es casi siempre suficiente. Los servidores dedicados se requieren para proyectos muy grandes con cientos o miles de usuarios activos, requisitos extremadamente altos de rendimiento del subsistema de disco, o si necesita un control físico completo sobre el hardware y sus componentes específicos. Para la mayoría de los equipos y empresas, un VPS es una solución más económica y flexible que se escala fácilmente a medida que crecen las necesidades. Comience con un VPS, y si se encuentra con una escasez constante de recursos, entonces considere la transición a un servidor dedicado.

No se puede obtener un certificado SSL de Let's Encrypt en Nginx Proxy Manager

Qué verificar:

  1. Registro DNS: El dominio para el que solicita el certificado debe estar configurado correctamente en el DNS y apuntar a la IP de su VPS. Verifíquelo a través de dig o herramientas en línea.
  2. Firewall: Los puertos 80 y 443 deben estar abiertos para las conexiones entrantes. Let's Encrypt utiliza el puerto 80 para el desafío HTTP-01.
  3. Registros de NPM: Revise los registros del contenedor Nginx Proxy Manager. Los errores de Certbot (utilizado por Let's Encrypt) estarán allí.
  4. Límites de Let's Encrypt: Si ha solicitado certificados con frecuencia para el mismo dominio, es posible que haya alcanzado los límites de Let's Encrypt. Espere un tiempo.

Cómo solucionar: Asegúrese de que el DNS sea correcto y los puertos estén abiertos. Si el problema son los límites, use el servidor de prueba de Let's Encrypt (Staging) en NPM para depurar antes de intentar obtener un certificado real nuevamente.

¿Cómo actualizar Wiki.js a una nueva versión?

Qué verificar:

  1. Disponibilidad de nueva versión: Verifique el repositorio oficial de Wiki.js en GitHub o Docker Hub para versiones actualizadas.
  2. Copia de seguridad: Siempre realice una copia de seguridad completa de la base de datos y los datos de Wiki.js antes de actualizar.

Cómo solucionar: Vaya al directorio ~/wiki en su servidor, cambie el número de versión de la imagen de Wiki.js en el archivo docker-compose.yml (por ejemplo, de 2.5.300 a 2.5.301 o 3.0.0). Luego ejecute:


docker compose pull # Descargar el nuevo imagen
docker compose up -d # Volver a crear el contenedor con la nueva versión

Después de la actualización, revise los registros de Wiki.js y asegúrese de que todo funcione correctamente. A veces pueden ser necesarios pasos de migración adicionales, descritos en las notas de la versión de Wiki.js.

Conclusiones y próximos pasos

Diagrama: Conclusiones y próximos pasos
Diagrama: Conclusiones y próximos pasos

¡Felicidades! Ha desplegado con éxito Wiki.js en su VPS, utilizando Docker Compose para la orquestación de servicios. Ahora tiene un sistema wiki potente, seguro y fácil de gestionar, accesible a través de HTTPS, que está listo para convertirse en el repositorio central de conocimientos para su equipo o proyectos personales. Ha obtenido control total sobre los datos y la infraestructura, lo cual es una ventaja significativa en comparación con las soluciones en la nube.

Aquí hay algunos próximos pasos que puede tomar para seguir desarrollando su Wiki.js:

  • Configuración de autenticación: Integre Wiki.js con su LDAP, Active Directory, GitHub, Google OAuth o cualquier otro proveedor de autenticación existente para una gestión de usuarios conveniente.
  • Monitorización del rendimiento: Instale herramientas de monitorización (por ejemplo, Prometheus + Grafana) para rastrear el estado del servidor, el uso de recursos por los contenedores Docker y el rendimiento de Wiki.js.
  • Escalado del almacenamiento: Si planea almacenar grandes volúmenes de archivos, considere integrar Wiki.js con almacenamientos de objetos externos (compatibles con S3) para archivos multimedia, a fin de no sobrecargar el espacio en disco de su VPS.
  • Exploración de las funciones de Wiki.js: Sumérjase en la rica funcionalidad de Wiki.js, configure temas, plugins, permisos de acceso y flujos de trabajo para una máxima adaptación a sus necesidades.

¿Te fue útil esta guía?

Despliegue de wiki.js en VPS: instalación con Docker Compose, PostgreSQL y N
support_agent
Valebyte Support
Usually replies within minutes
Hi there!
Send us a message and we'll reply as soon as possible.