Instalación de Fider en un VPS: recopilación de comentarios self-hosted, SSL y SMTP

Qué configuramos y por qué

Fider es una aplicación open-source para gestionar las propuestas de los usuarios. Permite crear un portal público o privado de comentarios: los visitantes publican ideas, otros usuarios votan y dejan comentarios, mientras el equipo cambia el estado de las propuestas e informa sobre el progreso.

Un escenario típico es un producto SaaS, una tienda online, una comunidad de videojuegos, un servicio corporativo interno o un proyecto open-source. En lugar de recopilar ideas por correo, Telegram, Discord, Google Forms y tareas de Jira, ofreces a los usuarios un único punto de entrada claro.

Al finalizar la configuración tendrás un subdominio independiente, por ejemplo feedback.example.com, con un certificado HTTPS válido, una base de datos PostgreSQL, envío de correos mediante SMTP y copias de seguridad automatizadas. La arquitectura constará de cuatro componentes:

• Fider — aplicación web accesible para los usuarios mediante el navegador.
• PostgreSQL — base de datos con usuarios, votos, publicaciones, comentarios y configuraciones.
• Caddy — reverse proxy que recibe el tráfico HTTPS, obtiene los certificados y reenvía las solicitudes a Fider.
• Docker Compose — herramienta que describe los contenedores, las redes, los volúmenes persistentes y las variables de entorno.

Qué puede hacer Fider

En su configuración básica, Fider permite crear espacios de comentarios, moderar publicaciones, votar ideas, comentar propuestas, asignar estados a las publicaciones y enviar notificaciones. El administrador puede gestionar el acceso, configurar el dominio, la apariencia y los métodos de autenticación.

Para un producto pequeño, esto suele ser más sencillo que implementar un sistema pesado de gestión de tareas y permitir el acceso de los clientes. El usuario solo ve una interfaz clara con propuestas, mientras que el equipo recibe una señal de lo que realmente importa a la audiencia: las ideas con más votos suben automáticamente de posición.

Servicio en la nube o Fider self-hosted

Los servicios de comentarios en la nube son prácticos porque no requieren administración. Sin embargo, normalmente limitan el número de usuarios, paneles públicos e integraciones, o exigen una suscripción mensual. Además, la plataforma externa almacena los datos de los usuarios, nombres, direcciones de email y textos de las propuestas en manos de terceros.

Instalar Fider self-hosted en un VPS está justificado si valoras el control sobre los datos, tu propio dominio, un coste predecible, la posibilidad de crear un panel interno privado o el cumplimiento de los requisitos sobre la ubicación de los datos. Tú te encargas de las actualizaciones y las copias de seguridad, pero obtienes un control total sobre la infraestructura.

Qué necesitarás antes de empezar

• Un VPS o servidor dedicado con una dirección IPv4 pública.
• Un dominio o subdominio, por ejemplo feedback.example.com.
• La posibilidad de crear un registro DNS de tipo A.
• Acceso a un proveedor SMTP o a tu propio servidor de correo.
• Un cliente SSH local: OpenSSH, Windows Terminal, PuTTY o equivalente.
• El sistema operativo Ubuntu Server 24.04 LTS o Debian 12/13. En los ejemplos se utiliza Ubuntu 24.04 LTS.

No publiques Fider directamente en el puerto 3000 en Internet. El contenedor de la aplicación debe estar disponible únicamente para el reverse proxy dentro de la red de Docker, y desde el exterior solo deben quedar abiertos SSH, HTTP y HTTPS.

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

Fider no es una aplicación que consuma muchos recursos cuando se trata de varios cientos o miles de usuarios registrados y una actividad moderada. El mayor consumo de memoria procede de PostgreSQL, los contenedores Docker y la caché de archivos del sistema operativo. Por eso, aunque 1 GB de RAM puede iniciar formalmente el servicio, para un funcionamiento estable es mejor no utilizar una configuración tan mínima.

Una opción inicial práctica es 2 vCPU, 4 GB de RAM, 40 GB de NVMe y un canal de al menos 100 Mbit/s. Es suficiente para Fider, PostgreSQL, Caddy, las copias de seguridad automáticas y un pequeño margen de crecimiento. Por ejemplo, puedes contratar un VPS con las características indicadas, instalar Ubuntu 24.04 LTS y seguir los comandos de esta guía.

Por qué es importante disponer de memoria adicional

Cuando falta RAM, Linux empieza a utilizar activamente el swap. Esto no siempre provoca la caída de Fider, pero aumenta notablemente el tiempo de respuesta de PostgreSQL y de la aplicación web. Con 2 GB de memoria, el servicio normalmente funciona bien; sin embargo, 4 GB ofrecen un margen más cómodo para las actualizaciones, las copias de seguridad y los picos breves de actividad.

Controla el espacio libre en el disco. PostgreSQL crece no solo por los datos, sino también debido a los registros de transacciones, los índices y los archivos temporales. Docker también almacena imágenes y capas de contenedores. No llenes el sistema de archivos por encima del 80–85 %: en un disco lleno, la base de datos puede dejar de aceptar registros.

Cuándo se necesita un servidor dedicado en lugar de un VPS

Para uno o varios paneles Fider normales no se necesita un servidor dedicado. Un VPS es más fácil de escalar, más barato de respaldar y más rápido de migrar. Un servidor dedicado tiene sentido ante una comunidad pública muy activa, decenas de miles de visitantes diarios, requisitos estrictos de aislamiento de recursos o el alojamiento de varios sistemas pesados junto a Fider.

Si la base de datos crece hasta ocupar decenas de gigabytes y los usuarios crean publicaciones y comentarios constantemente, primero separa las funciones: deja Fider y Caddy en un VPS, y traslada PostgreSQL a otro servidor o a un PostgreSQL gestionado. Normalmente esto es más eficaz que cambiar directamente a un servidor dedicado grande.

Elección de la ubicación

La ubicación del servidor influye en la latencia, los requisitos para el tratamiento de datos personales y la velocidad de envío de correos. Elige la región más cercana a tu audiencia principal. Para equipos y clientes de Europa, normalmente tiene sentido un centro de datos europeo; para una audiencia de Asia, una ubicación asiática.

Si Fider se utiliza dentro de una empresa, comprueba si es posible almacenar los datos de empleados y clientes en la jurisdicción elegida. Además, asegúrate de que el proveedor SMTP permita enviar correos desde la dirección IP de la región seleccionada y de que el puerto 25 no sea la única opción disponible: es preferible utilizar el 587 con STARTTLS o el 465 con TLS.

Preparación del servidor

A continuación se supone que ha recibido la dirección IP del servidor y una contraseña temporal para el usuario root. Conéctese al servidor mediante SSH, realice la actualización inicial, cree un usuario independiente para la administración y desactive los métodos peligrosos de acceso remoto.

En el equipo local, cree primero una clave si aún no dispone de ella. No envíe la clave privada al servidor ni la comparta con otras personas. Puede ver la clave pública con el comando cat ~/.ssh/id_ed25519.pub.

# Создайте современную пару SSH-ключей на локальном компьютере
ssh-keygen -t ed25519 -a 100 -C "admin@feedback-server"

Conéctese al servidor como root. Sustituya SERVER_IP por la dirección IPv4 real. En el primer acceso, SSH le pedirá confirmar la huella digital del servidor; compárela con los datos del panel de hosting, si dicha información está disponible.

# Подключитесь к новому серверу
ssh root@SERVER_IP

Actualice los paquetes del sistema operativo. Es mejor ejecutar el comando inmediatamente después de crear el VPS y repetirlo periódicamente. Si se actualizó el kernel, reinicie el servidor en un momento conveniente.

# Обновите индекс пакетов и установите все доступные обновления безопасности
apt update && apt upgrade -y

Cree una cuenta independiente, añádala al grupo sudo e instale las herramientas básicas. En el ejemplo se utiliza el usuario deploy; puede elegir otro nombre sin espacios ni caracteres especiales.

# Создайте пользователя для администрирования и выдайте ему права sudo
adduser deploy
usermod -aG sudo deploy
apt install -y curl wget git nano vim ufw fail2ban ca-certificates gnupg unzip

Copie la clave SSH pública para el nuevo usuario. Este comando debe ejecutarse en su equipo local, no en el servidor. Después, abra otra ventana de terminal y asegúrese de que el acceso con el nuevo usuario funciona antes de desactivar el acceso root.

# С локального компьютера установите публичный ключ для пользователя deploy
ssh-copy-id deploy@SERVER_IP
ssh deploy@SERVER_IP

Protección de SSH

Después de comprobar correctamente el acceso mediante clave, desactive el acceso root y la autenticación mediante contraseña. Esto reduce el riesgo de ataques de fuerza bruta por parte de bots. No cierre la sesión SSH actual hasta asegurarse de que una nueva sesión con el usuario deploy se abre sin contraseña.

# Создайте отдельный конфигурационный файл для усиления SSH
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3
AllowUsers deploy
EOF

# Проверьте конфигурацию и перезапустите SSH-службу
sudo sshd -t && sudo systemctl restart ssh

Firewall y Fail2ban

Abra únicamente los puertos SSH, HTTP y HTTPS. Si ya ha cambiado el puerto SSH, sustituya el número 22 en el ejemplo. UFW no cierra inmediatamente la conexión existente, pero una configuración incorrecta del firewall puede dejar el servidor inaccesible; por ello, vuelva a comprobar la regla para SSH antes de activarlo.

# Разрешите только SSH, HTTP и HTTPS, затем включите firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Fail2ban analiza los registros de SSH y bloquea temporalmente las direcciones IP después de varios intentos fallidos de acceso. Incluso con la autenticación mediante contraseña desactivada, resulta útil como nivel adicional de protección.

# Включите Fail2ban и настройте базовую защиту SSH
sudo tee /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Compruebe la carga actual y el estado del disco. En un servidor limpio, el espacio libre debería ocupar la mayor parte de la partición. Más adelante, estos comandos serán útiles para diagnosticar problemas de rendimiento.

# Проверьте память, диск, нагрузку и активные сетевые порты
free -h
df -h
uptime
sudo ss -tulpn

Instalación del software — paso a paso

Para Fider, resulta práctico utilizar Docker Engine y Docker Compose Plugin. En Ubuntu 24.04 LTS no conviene depender del paquete antiguo docker.io del repositorio estándar si se necesita una versión actualizada de Docker. Es mejor añadir el repositorio oficial de Docker e instalar Docker Engine 28.x o una rama estable más reciente disponible en el momento de la instalación.

A continuación se utilizan los siguientes componentes: Ubuntu Server 24.04 LTS, Docker Engine 28+, Docker Compose v2, PostgreSQL 17 en un contenedor y Caddy 2.x. La imagen de Fider utilizará la etiqueta stable; antes de actualizar, consulte siempre el changelog del proyecto y pruebe la nueva versión en una copia de seguridad.

# Добавьте официальный GPG-ключ и репозиторий Docker для Ubuntu
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

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

# Установите Docker Engine, CLI, Buildx и современный Docker Compose Plugin
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
docker version
docker compose version

Añada el usuario deploy al grupo docker. Esto permitirá gestionar contenedores sin sudo. Los miembros de este grupo obtienen, en la práctica, privilegios de nivel root, por lo que solo deben añadirse administradores de confianza.

# Разрешите пользователю deploy выполнять docker-команды без sudo
sudo usermod -aG docker deploy
newgrp docker
docker run --rm hello-world

Cree el directorio del proyecto. Todos los archivos importantes de Fider se almacenarán en /opt/fider: el manifiesto de Compose, el archivo de secretos, el Caddyfile y el directorio para las copias de seguridad. Este enfoque simplifica la migración a otro servidor.

# Создайте структуру каталогов для приложения, proxy и резервных копий
sudo mkdir -p /opt/fider/{caddy,backups,scripts}
sudo chown -R deploy:deploy /opt/fider
cd /opt/fider

Genere secretos criptográficamente seguros para PostgreSQL y JWT. No utilice contraseñas simples, no copie los valores de ejemplo del artículo ni almacene el archivo .env en un repositorio Git público. La contraseña de la base de datos y el JWT-secret serán necesarios en el siguiente paso.

# Сгенерируйте отдельные секреты для PostgreSQL и подписи пользовательских сессий
openssl rand -base64 32
openssl rand -hex 48

Antes de iniciar los contenedores, cree un registro DNS. En el panel del registrador o del proveedor DNS, añada un registro de tipo A: nombre feedback, valor: la IPv4 de su VPS. Si necesita el dominio raíz, utilice @ en lugar del nombre del subdominio.

# Проверьте с сервера, что DNS-запись указывает на нужный IP-адрес
getent hosts feedback.example.com

La salida debe contener la dirección IP de su VPS. Si el DNS aún no se ha propagado, espere: normalmente tarda unos minutos, pero depende del TTL y del proveedor DNS. Caddy no podrá obtener un certificado de Let's Encrypt mientras el dominio no apunte al servidor y los puertos 80/443 no estén accesibles desde el exterior.

Comprobación de las imágenes antes del inicio

Las imágenes se descargarán automáticamente mediante el comando docker compose up, pero descargarlas previamente ayuda a detectar más rápido problemas de red o DNS. Para la base de datos se utiliza PostgreSQL 17 Alpine: la rama 17 es estable, compacta y adecuada para este escenario. Fider debe funcionar con una versión compatible de PostgreSQL, indicada en la documentación oficial del proyecto.

# Загрузите образы приложения и базы данных до запуска стека
docker pull getfider/fider:stable
docker pull postgres:17-alpine
docker image ls | grep -E 'getfider|postgres'

La etiqueta stable resulta práctica para el primer despliegue, pero en producción es mejor fijar la versión o el digest de la imagen después de comprobarla. De este modo, la recreación automática del contenedor no provocará una actualización inesperada de la aplicación.

Configuración de Fider, SSL y SMTP

En esta sección se crean tres archivos: .env con los secretos, docker-compose.yml con la descripción de los contenedores y Caddyfile para HTTPS. Sustituya el dominio, la dirección de email del remitente y las credenciales SMTP reales. No deje en la configuración los valores del ejemplo.

Archivo de variables de entorno

Cree /opt/fider/.env. Compose cargará automáticamente las variables desde este archivo. Establezca los permisos 600 para que otros usuarios del sistema no puedan leer la contraseña de la base de datos ni la de SMTP.

# Создайте файл секретов и измените значения перед первым запуском
cd /opt/fider
cat > .env <<'EOF'
FIDER_DOMAIN=feedback.example.com

POSTGRES_DB=fider
POSTGRES_USER=fider
POSTGRES_PASSWORD=CHANGE_TO_A_LONG_RANDOM_DATABASE_PASSWORD

JWT_SECRET=CHANGE_TO_A_LONG_RANDOM_JWT_SECRET

SMTP_HOST=smtp.example-mail-provider.com
SMTP_PORT=587
SMTP_USERNAME=SMTP_LOGIN_OR_API_KEY
SMTP_PASSWORD=SMTP_PASSWORD_OR_API_KEY
SMTP_FROM=Feedback Team <[email protected]>
EOF

chmod 600 .env

Para SMTP, utilice credenciales independientes para los correos transaccionales. No indique la contraseña principal del buzón corporativo. La mayoría de los proveedores de correo admiten claves de API o app password. Para el puerto 587 se utiliza STARTTLS; para el 465 a menudo se requiere implicit TLS, y las variables pueden variar según la versión de Fider y el proveedor SMTP.

Docker Compose para Fider y PostgreSQL

A continuación, PostgreSQL no publica ningún puerto hacia el exterior: solo está disponible para el contenedor de Fider en la red interna de Docker. Fider tampoco tiene un puerto del host abierto; solo se podrá acceder a él mediante Caddy. Esto reduce la superficie de ataque.

services:
  db:
    image: postgres:17-alpine
    container_name: fider-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks:
      - fider_internal

  fider:
    image: getfider/fider:stable
    container_name: fider-app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      BASE_URL: https://${FIDER_DOMAIN}
      DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}?sslmode=disable
      JWT_SECRET: ${JWT_SECRET}
      EMAIL_NOREPLY: ${SMTP_FROM}
      EMAIL_SMTP_HOST: ${SMTP_HOST}
      EMAIL_SMTP_PORT: ${SMTP_PORT}
      EMAIL_SMTP_USERNAME: ${SMTP_USERNAME}
      EMAIL_SMTP_PASSWORD: ${SMTP_PASSWORD}
      EMAIL_SMTP_ENABLE_STARTTLS: "true"
    networks:
      - fider_internal
      - proxy
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost:3000/ > /dev/null || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5

  caddy:
    image: caddy:2-alpine
    container_name: fider-caddy
    restart: unless-stopped
    depends_on:
      - fider
    ports:
      - "80:80"
      - "443:443"
    environment:
      FIDER_DOMAIN: ${FIDER_DOMAIN}
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy

volumes:
  postgres_data:
  caddy_data:
  caddy_config:

networks:
  fider_internal:
    internal: true
  proxy:

Guarde este archivo como /opt/fider/docker-compose.yml. Antes de iniciar, compruebe que Compose detecta correctamente las variables. El comando no debe imprimir la contraseña en un registro compartido ni en capturas de pantalla; si trabaja en un sistema compartido, no utilice docker compose config sin necesidad, ya que revela los valores sustituidos.

# Проверьте синтаксис Compose-файла и подготовьте конфигурацию контейнеров
cd /opt/fider
docker compose config --quiet

Configuración de Caddy y HTTPS automático

Caddy solicita automáticamente un certificado de Let's Encrypt, redirige HTTP a HTTPS y renueva el certificado. Para ello, el dominio ya debe apuntar al servidor, y el firewall y el filtro de red externo deben permitir los puertos TCP 80 y 443.

{
    email [email protected]
    acme_ca https://acme-v02.api.letsencrypt.org/directory
}

{$FIDER_DOMAIN} {
    encode zstd gzip

    reverse_proxy fider:3000 {
        header_up Host {host}
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }

    log {
        output stdout
        format console
    }
}

Guarde la configuración en el archivo /opt/fider/caddy/Caddyfile. En la directiva email, indique una dirección de administrador activa: podría recibir notificaciones de la autoridad certificadora. El almacenamiento de Caddy caddy_data contiene los certificados y la cuenta ACME, por lo que también debe incluirse en las copias de seguridad.

Inicie el stack en segundo plano y revise inmediatamente los registros. Durante el primer inicio, Fider crea las tablas necesarias en PostgreSQL y Caddy obtiene el certificado. Dependiendo de la velocidad del DNS y de la red, esto suele tardar desde unos segundos hasta un par de minutos.

# Запустите PostgreSQL, Fider и Caddy в фоновом режиме
cd /opt/fider
docker compose up -d
docker compose ps
docker compose logs --tail=100 -f

Salga del modo de visualización de registros con la combinación Ctrl+C. En la tabla de estado, los contenedores deben aparecer como running o healthy. Si Caddy no obtiene el certificado, no genere decenas de solicitudes repetidas: compruebe primero el DNS, el firewall y la accesibilidad de los puertos desde la red externa.

Configuración inicial de Fider

Abra https://feedback.example.com en el navegador. En la primera visita, Fider le ofrecerá crear un espacio y el primer administrador. Utilice una dirección capaz de recibir correos mediante el SMTP configurado. Si los correos no llegan, corrija primero SMTP en lugar de crear nuevos espacios y usuarios.

Después del primer inicio de sesión, configure el nombre del portal, la descripción, el logotipo, los estados de las publicaciones y las reglas de moderación. Es útil crear de inmediato los estados Planificado, En curso, Implementado y No está previsto. Esto hace que los comentarios sean transparentes: los usuarios ven que las ideas no desaparecen sin respuesta.

Comprobación del funcionamiento

Compruebe los encabezados HTTPS y la redirección HTTP desde el propio servidor. Normalmente, una solicitud HTTP debe devolver una redirección 308 o 301, mientras que HTTPS debe devolver el código 200, 302 o 303, según el estado de la configuración inicial.

# Проверьте HTTP-перенаправление, HTTPS и состояние контейнеров
curl -I http://feedback.example.com
curl -I https://feedback.example.com
docker compose ps
docker inspect --format='{{.State.Health.Status}}' fider-db

Compruebe los registros de envío de correos después de registrar un usuario de prueba o enviar una invitación. Una conexión SMTP correcta no siempre significa que el correo se haya entregado: revise también la bandeja de entrada, la carpeta de spam y los registros del proveedor SMTP.

# Отфильтруйте журналы приложения по почтовым и SMTP-сообщениям
cd /opt/fider
docker compose logs --since=15m fider | grep -iE 'smtp|mail|email|error'

Para lograr una buena entregabilidad, configure los registros DNS del dominio de correo: SPF, DKIM y DMARC. Si el remitente es [email protected], el dominio example.com debe estar verificado con el proveedor SMTP. De lo contrario, los correos pueden terminar en la carpeta de spam, incluso si Fider se conecta al SMTP sin errores.

Copias de seguridad y mantenimiento

Docker volume no es una copia de seguridad. Si el disco del VPS falla, se elimina accidentalmente el volumen o la base de datos se daña, será imposible recuperar los datos sin una copia de seguridad externa. La estrategia mínima para Fider consiste en realizar un volcado lógico diario de PostgreSQL, copiar la configuración y enviar el archivo fuera del servidor principal.

Qué se debe guardar

• Volcado de PostgreSQL: todos los usuarios, propuestas, votos, comentarios y configuraciones del sistema.
• /opt/fider/docker-compose.yml — descripción de la infraestructura.
• /opt/fider/.env — secretos, credenciales SMTP y nombre de dominio.
• /opt/fider/caddy/Caddyfile — configuración del reverse proxy.
• Docker volume de Caddy — certificados y datos de ACME. Se pueden volver a emitir, pero conservarlos acelera la recuperación.
• Documentación con los registros DNS, el método de acceso a SMTP y el procedimiento de recuperación.

No conviene depender únicamente del snapshot del VPS. Las instantáneas son útiles para realizar una reversión rápida, pero normalmente se encuentran en la misma infraestructura que el servidor. La regla 3-2-1 sigue siendo válida: como mínimo tres copias de los datos, en dos soportes diferentes, y una copia fuera del servidor principal.

Script de copia de seguridad diaria

El siguiente script crea un volcado comprimido de la base de datos, archiva la configuración y envía el directorio a un almacenamiento compatible con S3 mediante Restic. Restic cifra los datos en el lado del servidor antes de enviarlos. Se puede utilizar Backblaze B2 S3, Wasabi, MinIO en un servidor independiente u otro almacenamiento de objetos compatible.

# Instale Restic y las herramientas de archivado
sudo apt install -y restic tar

Cree un archivo con los parámetros de Restic. Los valores de acceso a S3 deben tener permisos únicamente para escribir y leer el bucket necesario, sin acceso a otros proyectos. El archivo también contiene la contraseña de cifrado del repositorio: perder esta contraseña hace que las copias de seguridad sean ilegibles de forma irreversible.

# Cree un archivo de entorno protegido para Restic y el almacenamiento S3
sudo tee /etc/fider-restic.env <<'EOF'
export RESTIC_REPOSITORY="s3:https://s3.example-storage.net/fider-backups"
export RESTIC_PASSWORD="CHANGE_TO_A_LONG_RESTIC_REPOSITORY_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"
EOF

sudo chmod 600 /etc/fider-restic.env

Inicialice el repositorio remoto solo una vez. Después, Restic creará la estructura para los snapshots cifrados. Ejecute el comando con el usuario que vaya a iniciar la copia de seguridad; en el ejemplo es root mediante cron, porque el archivo de entorno se encuentra en /etc.

# Cree un nuevo repositorio Restic cifrado en el bucket S3 remoto
sudo bash -c 'source /etc/fider-restic.env && restic init'

Cree el script. Utiliza pg_dump dentro del contenedor de PostgreSQL, por lo que no requiere instalar el cliente de PostgreSQL en el host. El script conserva los volcados locales durante siete días, mientras que Restic aplica reglas independientes de retención para los snapshots remotos.

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/fider"
BACKUP_DIR="${APP_DIR}/backups"
DATE="$(date +%F_%H-%M-%S)"
DUMP_FILE="${BACKUP_DIR}/fider_${DATE}.sql.gz"
CONFIG_FILE="${BACKUP_DIR}/fider_config_${DATE}.tar.gz"

mkdir -p "${BACKUP_DIR}"

cd "${APP_DIR}"

docker compose exec -T db sh -c \
  'pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" --format=plain' \
  | gzip -9 > "${DUMP_FILE}"

tar -czf "${CONFIG_FILE}" \
  "${APP_DIR}/docker-compose.yml" \
  "${APP_DIR}/.env" \
  "${APP_DIR}/caddy/Caddyfile"

source /etc/fider-restic.env

restic backup "${DUMP_FILE}" "${CONFIG_FILE}" --tag fider
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

find "${BACKUP_DIR}" -type f -mtime +7 -delete

Guarde el código como /opt/fider/scripts/backup.sh, dele permisos de ejecución y ejecútelo manualmente. La primera ejecución es importante: muestra si hay acceso a Docker y al bucket S3, y si hay suficiente espacio en el disco.

# Establezca los permisos del script y ejecute manualmente una copia de seguridad de prueba
sudo chmod 700 /opt/fider/scripts/backup.sh
sudo /opt/fider/scripts/backup.sh
sudo bash -c 'source /etc/fider-restic.env && restic snapshots'

Añada la tarea al root-cron, por ejemplo diariamente a las 03:25. Elija una hora fuera de los periodos de mayor actividad. La salida se escribirá en el registro; si el servidor no tiene configurado el correo local, es más conveniente redirigir los mensajes de cron a un sistema de monitorización centralizado.

# Añada la ejecución diaria de la copia de seguridad al root-cron
sudo crontab -e

25 3   * /opt/fider/scripts/backup.sh >> /var/log/fider-backup.log 2>&1

Comprobación de la recuperación

Una copia de seguridad solo se considera funcional después de realizar una recuperación de prueba. Una vez por trimestre, cree un VPS temporal o un proyecto Docker independiente, descargue un snapshot de Restic, levante una base de datos PostgreSQL limpia e importe el volcado. Compruebe que las áreas, las ideas y los usuarios sean visibles.

# Ejemplo de recuperación de un volcado SQL en una base de datos PostgreSQL limpia
gunzip -c fider_YYYY-MM-DD_HH-MM-SS.sql.gz | \
docker compose exec -T db psql -U fider -d fider

En una recuperación real, detenga primero Fider, restaure la base de datos en un contenedor PostgreSQL vacío, devuelva los archivos de configuración y solo después inicie la aplicación. No importe el volcado sobre una base de datos production en funcionamiento sin un plan claro: podría generar datos incoherentes.

Actualizaciones de Fider, PostgreSQL y Docker

Para Fider, normalmente es adecuado un modelo de maintenance window breve. La actualización tarda unos minutos, pero antes de realizarla es obligatorio crear una copia de seguridad y leer las release notes. Preste especial atención a las actualizaciones major de PostgreSQL: no se pueden ejecutar simplemente sustituyendo la etiqueta del contenedor, porque el formato del directorio de datos cambia entre las versiones major.

# Cree una copia de seguridad, descargue las imágenes nuevas y vuelva a crear los contenedores de forma segura
cd /opt/fider
sudo /opt/fider/scripts/backup.sh
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 fider

No ejecute docker system prune -a sin pensar en un servidor production. El comando puede eliminar imágenes necesarias para una reversión rápida. En su lugar, revise periódicamente el uso de Docker y elimine únicamente las capas que no se utilicen después de confirmarlo.

# Compruebe el volumen de los datos de Docker y elimine solo los recursos no utilizados de forma segura
docker system df
docker image prune -f

Instale las actualizaciones de Ubuntu semanal o mensualmente después de revisar la lista de paquetes. Para una instancia pequeña de Fider, es aceptable una ventana de mantenimiento planificada de 15–30 minutos. Si es necesario reiniciar el kernel, asegúrese primero de que la copia de seguridad haya finalizado, luego reinicie el servidor y compruebe los contenedores.

Solución de problemas y FAQ

¿Por qué Caddy no obtiene el certificado SSL y aparece ACME error en los registros?

Primero compruebe el DNS: el comando getent hosts feedback.example.com debe devolver la IP pública de su VPS. Después, asegúrese de que los puertos 80 y 443 estén abiertos en UFW y de que no haya un firewall adicional en el panel del proveedor. Compruebe la disponibilidad desde una red externa, no solo desde el servidor. Asegúrese también de que no haya un registro AAAA conflictivo para el dominio: si se indica IPv6 pero no está configurado en el servidor, la autoridad certificadora puede intentar conectarse mediante IPv6 y finalizar la comprobación con un error.

Fider se abre, pero muestra un error de conexión con la base de datos. ¿Qué se debe comprobar?

Consulte los registros de los contenedores con los comandos docker compose logs db y docker compose logs fider. Con mayor frecuencia, el problema se debe a una discrepancia entre POSTGRES_PASSWORD y la cadena DATABASE_URL, o a que la base de datos ya se creó con otra contraseña. Cambiar la contraseña en .env no modifica automáticamente la contraseña del usuario existente de PostgreSQL. Si la instancia es nueva y no contiene datos, elimine el volume y créelo de nuevo; si ya hay datos, cambie la contraseña mediante un comando SQL dentro de PostgreSQL.

¿Por qué no llegan los correos de Fider después del registro?

Compruebe los parámetros EMAIL_SMTP_HOST, el puerto, el usuario, la contraseña y la dirección EMAIL_NOREPLY. Para la mayoría de los proveedores, el puerto 587 requiere STARTTLS, que está habilitado en el ejemplo de configuración. Consulte los registros de la aplicación buscando las palabras smtp y email. Si la conexión SMTP es correcta, pero el correo no se entrega, compruebe el spam, los registros del proveedor, SPF, DKIM y DMARC. La dirección del remitente debe pertenecer a un dominio confirmado o a una sender identity.

El contenedor Fider se reinicia constantemente. ¿Cómo encontrar la causa?

Ejecute docker compose ps y, después, docker compose logs --tail=200 fider. Busque el primer error antes del reinicio: normalmente se trata de una cadena de conexión incorrecta a PostgreSQL, una variable de entorno obligatoria ausente, un error de migración o falta de memoria. Compruebe free -h y dmesg -T | grep -i oom. Si el kernel finalizó el proceso por falta de memoria, aumente la RAM del VPS a 2–4 GB y añada swap temporalmente.

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

Para un panel de pruebas o pequeño y cerrado, bastan como mínimo 1 vCPU, 2 GB de RAM y 20–25 GB de SSD. Una configuración con 1 GB de memoria solo es posible como entorno temporal: PostgreSQL, Docker y el sistema funcionarán prácticamente sin margen. Para production con SMTP, HTTPS, copias de seguridad y varios cientos de usuarios, es más razonable empezar con 2 vCPU, 4 GB de RAM y 40 GB de NVMe. Tenga en cuenta el crecimiento de la base de datos y mantenga libre al menos entre el 15 y el 20 % del disco.

¿Qué elegir: VPS o dedicated para esta tarea?

Para Fider, casi siempre basta con un VPS. El servicio genera una carga relativamente pequeña, y un VPS es más fácil de escalar, respaldar y migrar. Un dedicated se justifica cuando hay un gran número de usuarios activos, decenas de servicios asociados, una infraestructura de correo propia o requisitos de recursos físicos garantizados. En la práctica, cuando Fider crece, suele ser más útil trasladar PostgreSQL a un servidor independiente o a una base de datos gestionada que comprar una máquina dedicada solo para la aplicación web.

¿Se puede abrir PostgreSQL en el puerto 5432 para conectarse desde el ordenador doméstico?

Técnicamente es posible, pero es una mala práctica para un uso permanente. En el archivo Compose actual, la base de datos está aislada en la red interna de Docker y no es accesible desde el exterior. Para realizar diagnósticos, utilice docker compose exec db psql en el servidor o un túnel SSH. Si la conexión externa es realmente necesaria, limite el acceso a una dirección IP concreta en el firewall, utilice un usuario independiente con permisos mínimos y TLS. Nunca abra PostgreSQL a todo Internet sin restricciones.

¿Cómo migrar Fider a otro VPS sin perder datos?

Prepare el nuevo servidor, instale Docker y cree el mismo directorio /opt/fider. Copie el archivo Compose, Caddyfile y .env mediante un canal seguro, restaure el último volcado SQL en una base de datos PostgreSQL limpia y, después, inicie los contenedores. Tras comprobarlo, cambie el registro DNS del dominio a la nueva IP. Antes del cambio, reduzca el TTL de DNS a 300 segundos. No elimine el servidor antiguo durante varios días: déjelo apagado o protegido por el firewall hasta confirmar el funcionamiento estable de la nueva instancia.

Conclusiones y próximos pasos

Ahora dispone de un Fider self-hosted en un VPS: la aplicación funciona mediante HTTPS, almacena los datos en PostgreSQL, envía notificaciones por SMTP y crea periódicamente copias de seguridad cifradas. Esta instalación es adecuada para un panel de ideas público, un portal corporativo cerrado o un canal de comentarios para un producto SaaS.

1. Cree el primer espacio, configure los estados de las propuestas y describa las reglas de publicación de ideas.
2. Compruebe el registro, la votación, los comentarios y la entrega de correos desde una cuenta de usuario de prueba.
3. Añada monitorización de la disponibilidad de HTTPS, el espacio en disco, el estado de los contenedores Docker y el resultado de la copia de seguridad nocturna.
4. Cuando aumente la carga, traslade PostgreSQL a un servidor independiente, añada la recopilación centralizada de registros y fije las versiones de las imágenes Docker.