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é
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
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
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
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.