Instalar y mantener Redmine en producción: requisitos, upgrades y backups

Redmine lleva más de veinte años haciendo una cosa muy concreta y haciéndola bien: gestionar peticiones, proyectos y tiempo sin pedirte una licencia por usuario ni obligarte a sacar tus datos de casa. En una época en la que cada herramienta SaaS sube de precio cada doce meses y cambia de plan cada dieciocho, un gestor de proyectos que se instala en tu propio servidor, que se actualiza cuando tú decides y cuyo coste no crece con el equipo sigue siendo una decisión perfectamente razonable. El problema es que casi toda la documentación que se encuentra por ahí se detiene justo donde empieza lo difícil: después de que la instalación arranque por primera vez.

Porque instalar Redmine es fácil. Mantenerlo en producción durante cinco años, con plugins, con integraciones, con adjuntos que ocupan cientos de gigas, con migraciones de Ruby y de Rails de por medio y con un equipo que ya no sabe trabajar sin él, es otra historia. Ahí es donde aparecen las instancias congeladas en una versión que ya no recibe parches de seguridad, los backups que nadie ha restaurado nunca y los plugins abandonados que bloquean cualquier actualización.

Esta guía cubre el ciclo completo: dimensionar el servidor, elegir versión con criterio, instalar sobre Debian o Ubuntu, ponerlo detrás de Nginx con Puma y systemd, configurar lo que la instalación no configura, asegurarlo, hacer copias de seguridad que de verdad sirvan, y actualizar entre series sin romper nada. Está escrita desde la perspectiva de quien tiene que responder cuando el servicio se cae un martes por la mañana, no desde la de quien monta un contenedor para probarlo un rato.

1. Antes de instalar: dimensionar y decidir

La primera pregunta no es qué versión instalar, sino cuánta gente lo va a usar y para qué. Redmine es una aplicación Rails clásica: el consumo de memoria lo marcan los procesos de aplicación, y el de CPU lo marcan las consultas pesadas (informes de tiempo, listados de peticiones con muchos filtros y campos personalizados) y la indexación de búsquedas.

Como referencia práctica para una instalación autoalojada:

• Hasta 25 usuarios concurrentes: 2 vCPU, 4 GB de RAM, disco SSD de 40 GB más lo que ocupen los adjuntos. Dos workers de Puma sobran.
• 25-100 usuarios: 4 vCPU, 8 GB de RAM, base de datos en el mismo host todavía es aceptable si el disco es rápido. Tres o cuatro workers.
• Más de 100 usuarios o uso intensivo de la API: separa la base de datos en su propio servidor, dedica 8-16 GB al servidor de aplicación y plantea dos instancias detrás de un balanceador con sesiones en base de datos.

El dato que casi siempre se subestima es el disco de adjuntos. Un Redmine que lleva tres años recibiendo capturas de pantalla, PDF de clientes y volcados de logs puede pasar de 200 GB sin que nadie se dé cuenta, y eso condiciona el tiempo de tu backup y el de tu restauración. Decide desde el día uno si los adjuntos van a vivir en un volumen separado (recomendable) o dentro del mismo sistema de ficheros que la aplicación.

La segunda decisión previa es dónde lo pones. Si Redmine va a contener información de clientes, presupuestos o incidencias de seguridad, es un sistema de información con datos personales y con valor de negocio: merece el mismo tratamiento que cualquier otro activo crítico. Si tu organización trabaja con marcos formales, conviene revisar qué exigen los controles técnicos de ISO 27001 en materia de acceso, cifrado y registro antes de decidir la arquitectura, no después.

2. Elegir versión: series soportadas y política de fin de vida

Redmine mantiene varias series en paralelo y las clasifica en stable, legacy y end of life. Esto importa mucho más de lo que parece, porque los parches de seguridad solo se retroportan a las series soportadas. A fecha de este artículo:

• Serie 5.1: fin de vida. No recibe correcciones de seguridad. Si estás aquí, tienes un problema abierto, no una tarea pendiente.
• Serie 6.0: legacy. Recibe correcciones críticas, pero no funcionalidad nueva.
• Series 6.1 y 7.0: estables y soportadas. La 7.0 salió el 30 de junio de 2026 y trae el cambio más grande de los últimos años: webhooks sobre eventos, salto a Rails 8 y soporte de Ruby 4.0, rediseño de la cabecera, soporte RTL, mejoras de rendimiento en las menciones y modo sudo activado por defecto.

Dos matices operativos importantes sobre la 7.0. El primero: si vas a usar Ruby 4.0, usa 4.0.4 o superior, porque las versiones anteriores de esa rama tienen una regresión que afecta al renderizado del wiki. El segundo: el 26 de agosto de 2026 se publicó la 7.0.1, que es una actualización de seguridad, no un simple mantenimiento. Corrige cinco vulnerabilidades: la posibilidad de obtener sesión a través de la API, un XSS en el parser Textile mediante etiquetas malformadas, un bypass de la visibilidad de relaciones entre peticiones, un bypass de inherit_members en subproyectos y la aparición de la API key en los logs. Además sube a Rails 8.1.3.1 y arregla un problema de rendimiento con los adjuntos. Si instalas hoy la serie 7, instala 7.0.1 o posterior, sin excepciones.

2.1 Criterio de elección

Para una instalación nueva sin plugins exóticos, la serie 7 es la opción correcta: soporte largo por delante y las novedades que de verdad cambian el trabajo diario (los webhooks eliminan la necesidad de polling para integrar Redmine con el resto del ecosistema). Para una instalación existente con cinco o seis plugins de terceros, la 6.1 es la elección prudente mientras compruebas la compatibilidad de cada plugin con Rails 8. Lo que no es una opción es quedarse en una serie EOL «hasta que haya tiempo»: en la práctica, ese tiempo nunca llega.

3. Requisitos de servidor: Ruby, Rails y base de datos

Redmine necesita tres cosas del sistema operativo: un intérprete de Ruby compatible con la serie elegida, un servidor de base de datos y un conjunto de librerías de compilación para las gemas nativas. Sobre Debian 12/13 o Ubuntu 24.04 LTS, la lista de paquetes base suele ser:

apt install -y build-essential ruby-full ruby-dev \
  libpq-dev libmariadb-dev libmagickwand-dev \
  imagemagick nginx git curl zlib1g-dev libssl-dev

Un aviso sobre el Ruby del sistema: los repositorios de las distribuciones suelen ir por detrás de lo que Redmine necesita, y cuando la distribución actualice Ruby por su cuenta te romperá las gemas compiladas. En producción es preferible gestionar la versión de Ruby de forma explícita con rbenv o rvm, fijarla en un .ruby-version dentro del directorio de la aplicación y controlar tú cuándo cambia.

3.1 PostgreSQL o MySQL

Redmine soporta ambas. PostgreSQL es la opción que recomendamos para instalaciones nuevas: mejor comportamiento con consultas complejas, búsqueda de texto más sólida y menos sorpresas con collations y juegos de caracteres. Si eliges MySQL o MariaDB, asegúrate de usar utf8mb4 desde el principio; convertir una base de datos de utf8 a utf8mb4 con años de histórico es un trabajo desagradable y con riesgo de truncar índices.

Creación del usuario y la base en PostgreSQL:

sudo -u postgres createuser --pwprompt redmine
sudo -u postgres createdb -O redmine -E UTF8 redmine_production

Y las buenas prácticas de siempre: usuario dedicado, contraseña larga generada aleatoriamente, sin permisos de superusuario y sin escuchar en interfaces públicas. Si la base de datos acaba en otro host, cifra la conexión y limita el acceso por firewall; el artículo sobre cómo asegurar servidores con poco presupuesto cubre bien esa parte del hardening.

4. Instalación paso a paso sobre Debian o Ubuntu

Hay tres formas de instalar Redmine: el paquete de la distribución, el tarball oficial y el repositorio Git. El paquete de la distribución parece cómodo pero te ata a la versión que empaqueten y complica los upgrades; solo tiene sentido para una prueba rápida. Para producción, tarball o Git. El Git es preferible si vas a aplicar parches propios o quieres moverte entre ramas con comodidad.

Con usuario dedicado y tarball:

useradd -r -m -d /opt/redmine -s /bin/bash redmine
cd /opt/redmine
curl -LO https://www.redmine.org/releases/redmine-7.0.1.tar.gz
tar xzf redmine-7.0.1.tar.gz && mv redmine-7.0.1 app
cd app

Configuración de la conexión a base de datos en config/database.yml:

production:
  adapter: postgresql
  database: redmine_production
  host: localhost
  username: redmine
  password: "LA_CONTRASEÑA"
  encoding: utf8

Instalación de dependencias y preparación de la aplicación:

gem install bundler
bundle config set --local without 'development test'
bundle install
bundle exec rake generate_secret_token
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake redmine:load_default_data

Permisos de los directorios que la aplicación necesita escribir:

mkdir -p tmp tmp/pdf public/plugin_assets files log
chown -R redmine:redmine files log tmp public/plugin_assets
chmod -R 755 files log tmp public/plugin_assets

Si bundle install falla, casi siempre es por una librería de desarrollo que falta (típicamente la de la base de datos o la de ImageMagick). El mensaje de error de la gema concreta te dice exactamente qué paquete -dev instalar; resiste la tentación de saltarte gemas con --without para que «compile de una vez».

5. Puesta en producción: Puma, systemd y Nginx

El servidor web que trae Rails para desarrollo no vale para producción. La combinación estándar hoy es Puma como servidor de aplicación, gestionado por systemd, detrás de Nginx como proxy inverso que termina TLS y sirve los ficheros estáticos.

5.1 Unidad de systemd

[Unit]
Description=Redmine (Puma)
After=network.target postgresql.service

[Service]
Type=simple
User=redmine
WorkingDirectory=/opt/redmine/app
Environment=RAILS_ENV=production
ExecStart=/opt/redmine/.rbenv/shims/bundle exec puma -e production \
  -b unix:///opt/redmine/app/tmp/puma.sock -w 3
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Tres workers es un buen punto de partida para 8 GB de RAM. Cada worker de Puma en una instalación con plugins ronda los 300-500 MB residentes; mide el consumo real con ps antes de subir el número, porque quedarse sin memoria y que el OOM killer mate procesos produce caídas mucho peores que ir algo justo de concurrencia.

5.2 Nginx delante

server {
  listen 443 ssl http2;
  server_name redmine.tuempresa.com;

  ssl_certificate     /etc/letsencrypt/live/redmine.tuempresa.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/redmine.tuempresa.com/privkey.pem;

  client_max_body_size 100m;
  root /opt/redmine/app/public;

  location / {
    try_files $uri @app;
  }

  location @app {
    proxy_pass http://unix:/opt/redmine/app/tmp/puma.sock;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 120s;
  }
}

Dos detalles que se olvidan siempre. El primero es client_max_body_size: si lo dejas en el valor por defecto de 1 MB, los usuarios verán un error 413 al subir cualquier adjunto medianamente grande y no entenderán por qué. Ajústalo al mismo límite que configures dentro de Redmine. El segundo es X-Forwarded-Proto: sin él, Redmine genera enlaces en http dentro de los correos de notificación aunque el sitio esté servido por HTTPS.

Si quieres que Nginx sirva los adjuntos directamente en lugar de que pasen por Ruby —lo que reduce mucho el consumo de memoria en instalaciones con ficheros grandes—, activa X-Sendfile en la configuración de Redmine y el módulo correspondiente en Nginx. Es una de las optimizaciones con mejor relación esfuerzo-resultado.

6. Lo que la instalación no configura y tú tienes que configurar

Redmine arranca con una configuración mínima que funciona para probarlo y es insuficiente para trabajar. Estas son las piezas que hay que tocar antes de dar acceso al equipo.

6.1 configuration.yml: correo y adjuntos

El fichero config/configuration.yml controla el envío de correo, el almacenamiento de adjuntos y la entrega de ficheros. El bloque de correo mínimo con un relay SMTP autenticado:

production:
  email_delivery:
    delivery_method: :smtp
    smtp_settings:
      address: "smtp.tuproveedor.com"
      port: 587
      authentication: :login
      user_name: "[email protected]"
      password: "..."
      enable_starttls_auto: true
  attachments_storage_path: /srv/redmine-files
  rmagick_font_path: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf

Sobre el correo, dos advertencias. La primera: si las notificaciones no llegan, el 90 % de las veces no es Redmine, es que el dominio no está autenticado correctamente y el receptor las está descartando. Revisa SPF, DKIM y DMARC antes de tocar nada de la configuración de la aplicación. La segunda: configura attachments_storage_path fuera del árbol de la aplicación desde el principio. Si dejas los adjuntos en files/ dentro del directorio de la aplicación, cada upgrade se convierte en una operación con riesgo de pérdida de datos.

6.2 Tareas periódicas

Redmine no trae planificador propio: las tareas recurrentes se lanzan por cron. Las tres habituales son la recepción de correo entrante por IMAP (si quieres que los clientes creen peticiones respondiendo a un email), el envío de recordatorios de vencimiento y la recogida de cambios de los repositorios asociados a proyectos.

# Recordatorios de peticiones que vencen en 3 días
0 8 * * * cd /opt/redmine/app && RAILS_ENV=production bundle exec rake redmine:send_reminders days=3

# Recepción de correo entrante
*/10 * * * * cd /opt/redmine/app && RAILS_ENV=production bundle exec rake redmine:email:receive_imap \
  host=imap.tuempresa.com [email protected] password=... ssl=1 project=soporte

Un consejo de mantenimiento: redirige la salida de estos cron a un fichero de log y monitorízalo. Un cron de IMAP que lleva tres semanas fallando en silencio significa tres semanas de peticiones de clientes que nunca entraron en el sistema, y nadie se entera hasta que alguien reclama.

6.3 Ajustes de administración

Dentro de la interfaz, antes de abrir el acceso: cambia la contraseña del usuario admin por defecto, desactiva el registro autoservicio si no lo necesitas, define el límite de tamaño de adjuntos coherente con el de Nginx, activa la autenticación obligatoria (Authentication required) para que nada sea visible sin login, y configura el host name y el protocolo para que los enlaces de los correos se generen bien.

7. Docker frente a instalación nativa

La imagen oficial de Redmine en Docker es buena y resuelve en minutos lo que en nativo lleva una tarde. La pregunta no es si funciona —funciona—, sino qué te conviene a medio plazo.

Docker gana cuando quieres reproducibilidad, cuando ya tienes una plataforma de contenedores con su monitorización y su gestión de secretos, y cuando pruebas versiones nuevas con frecuencia: levantar una 7.0.1 junto a tu 6.1 para validar plugins es cuestión de un docker compose up.

La instalación nativa gana cuando usas plugins que requieren compilación o parches sobre el código, cuando tu equipo de sistemas no gestiona contenedores en producción, y cuando quieres control fino sobre la versión de Ruby y las gemas. También cuando el volumen de adjuntos es grande: gestionar cientos de gigas en volúmenes de contenedor añade complejidad que no compensa.

Si vas por Docker, tres reglas: los adjuntos y la base de datos siempre en volúmenes externos al contenedor, fija la versión exacta de la imagen (nunca latest en producción) y no metas los plugins copiándolos a mano dentro del contenedor en caliente: constrúyete tu propia imagen derivada con los plugins dentro, o perderás el trabajo en el primer docker compose pull.

8. Seguridad de la instalación

Redmine suele contener el mapa completo de lo que hace una organización: proyectos, clientes, incidencias, a veces credenciales pegadas en un comentario por descuido. Tratarlo como una herramienta interna «de poca importancia» es un error clásico.

• HTTPS obligatorio y redirección desde HTTP, con certificado renovado automáticamente. Añade HSTS cuando estés seguro de que no queda nada sirviéndose por HTTP.
• Autenticación en dos factores: Redmine la soporta de serie desde la 4.1. Actívala al menos para administradores; idealmente, para todos.
• Modo sudo: en la serie 7 viene activado por defecto y obliga a reintroducir la contraseña para acciones administrativas. No lo desactives por comodidad.
• Revisión de la API key: si vienes de una versión anterior a la 7.0.1, la API key podía acabar en los logs. Tras actualizar, rota las keys de los usuarios que integren servicios externos.
• Permisos y visibilidad: los bypass corregidos en la 7.0.1 afectaban a la visibilidad de relaciones entre peticiones y a la herencia de miembros en subproyectos. Aprovecha para revisar quién ve qué, especialmente si tienes proyectos de clientes distintos en la misma instancia.
• Actualizaciones de plugins y gemas: las vulnerabilidades no siempre están en Redmine. Ejecuta bundle audit periódicamente y trata las gemas como lo que son, dependencias de tu cadena de suministro.
• Acceso restringido: si no necesita ser público, que no lo sea. VPN o lista de IPs permitidas a nivel de Nginx elimina de golpe casi toda la exposición.

Si quieres una revisión sistemática de este apartado más allá de la aplicación concreta, la guía de seguridad informática para pymes desde cero plantea el orden en que conviene atacar los distintos frentes.

9. Backups: lo único que de verdad te salva

Un backup de Redmine tiene exactamente dos piezas, y las dos son obligatorias: el volcado de la base de datos y el directorio de adjuntos. Tener solo una de las dos equivale a no tener backup, porque restaurarás una base de datos llena de referencias a ficheros inexistentes, o unos ficheros que nadie sabe a qué petición pertenecen.

#!/bin/bash
set -euo pipefail
FECHA=$(date +%F)
DESTINO=/srv/backups/redmine

pg_dump -Fc -U redmine redmine_production > "$DESTINO/db-$FECHA.dump"
tar czf "$DESTINO/files-$FECHA.tar.gz" -C /srv redmine-files
tar czf "$DESTINO/conf-$FECHA.tar.gz" -C /opt/redmine/app config plugins

find "$DESTINO" -type f -mtime +30 -delete

Añade el fichero config/ —contiene secret_token, sin el cual todas las sesiones se invalidan— y el directorio plugins/, porque reconstruir de memoria qué plugins y en qué versión tenías instalados después de un desastre es una experiencia que conviene evitar.

9.1 La regla que casi nadie cumple

Un backup que nunca se ha restaurado no es un backup, es una carpeta con ficheros grandes. Al menos una vez al trimestre, levanta la copia en un servidor de pruebas y comprueba tres cosas: que la aplicación arranca, que puedes abrir una petición al azar y que el adjunto de esa petición se descarga correctamente. La tercera es la que falla, y es precisamente la que detecta que llevas meses copiando la base de datos pero no los ficheros.

Aplica además el esquema 3-2-1 —tres copias, dos soportes distintos, una fuera de sitio— y asegúrate de que la copia externa no sea escribible desde el propio servidor. Si un ransomware cifra tu infraestructura, un backup montado en NFS con permisos de escritura se cifra igual que todo lo demás.

10. Upgrades entre series sin romper nada

El upgrade es donde se concentra casi todo el riesgo del ciclo de vida de Redmine, y la causa número uno de problemas no es Redmine: son los plugins.

10.1 Antes de empezar

Haz inventario de los plugins instalados y busca, uno por uno, si tienen versión compatible con la serie de destino. Los plugins abandonados que dependen de APIs internas de Rails son los que te van a dar un error de arranque después de la migración. Decide antes de tocar nada qué haces con cada uno: actualizar, sustituir por funcionalidad nativa o eliminar. El salto a Rails 8 de la serie 7 es especialmente sensible en este punto.

Revisa también las notas de versión de cada serie intermedia, no solo de la de destino. Las migraciones de base de datos son acumulativas y algunos cambios de comportamiento se documentan únicamente en la versión donde se introdujeron.

10.2 El procedimiento

1. Backup completo y restauración de prueba. No el backup de anoche: uno nuevo, restaurado en otro sitio y verificado. Este paso no es opcional.
2. Ensayo en preproducción. Clona la instancia con datos reales y haz el upgrade ahí primero. Cronometra cuánto tarda db:migrate: en bases grandes puede ser una hora, y esa hora es tiempo de servicio caído que hay que anunciar.
3. Ventana de mantenimiento. Para la aplicación y los cron. No migres con usuarios escribiendo.
4. Desplegar el código nuevo conservando config/, files/ y plugins/.
5. Dependencias: bundle install --without development test.
6. Migraciones: rake db:migrate y después rake redmine:plugins:migrate.
7. Limpieza de caché: rake tmp:cache:clear y borrado de tmp/sessions si procede.
8. Arranque y validación: login, listado de peticiones, creación de una petición con adjunto, descarga de ese adjunto, envío de un correo de prueba y revisión de log/production.log en busca de excepciones.

Mantén el backup y la versión anterior disponibles durante 24-48 horas. Los problemas de un upgrade rara vez aparecen en los primeros diez minutos: aparecen cuando alguien usa el informe de tiempos o el módulo de repositorios por primera vez al día siguiente.

10.3 Si vienes de una versión muy antigua

No saltes dos series mayores de una vez. El camino correcto es encadenar upgrades —por ejemplo 5.1 → 6.0 → 6.1 → 7.0— verificando que la aplicación arranca en cada escalón. Es más lento y es la única forma de saber qué migración concreta rompió algo cuando algo se rompe. Si además tienes que cambiar de versión de Ruby por el camino, hazlo como paso independiente: primero Ruby, compruebas, luego Redmine.

11. Monitorización y mantenimiento rutinario

Una vez en producción, Redmine necesita poca atención, pero necesita alguna. El mínimo razonable:

• Disponibilidad: una comprobación HTTP externa cada minuto contra una URL que requiera acceso a base de datos, no contra la página de login estática.
• Recursos: alertas de disco (especialmente el volumen de adjuntos y el de la base de datos), memoria y crecimiento del log.
• Logs: rotación configurada en logrotate y revisión periódica de excepciones en production.log. Redmine no rota su log por sí solo, y un fichero de decenas de gigas llenando el disco es un clásico.
• Base de datos: VACUUM y ANALYZE automáticos en PostgreSQL, y vigilancia del crecimiento de las tablas journals y journal_details, que son las que más crecen.
• Backups: alerta si el backup diario no se ha generado. El fallo silencioso del backup es el fallo más caro que existe.
• Seguridad: suscripción al feed de noticias de redmine.org para enterarte de las actualizaciones de seguridad el día que salen, no seis meses después.

11.1 Rendimiento: dónde mirar cuando va lento

Cuando Redmine se vuelve lento, el orden de sospechosos casi siempre es el mismo. Primero, consultas sin índice sobre campos personalizados en listados con muchos filtros. Segundo, el módulo de repositorios: si tienes repositorios grandes conectados y el fetch_changesets se ejecuta en cada petición web en lugar de por cron, cada carga de página espera a Git. Tercero, adjuntos servidos por Ruby en lugar de por Nginx. Y cuarto, falta de workers de Puma para la concurrencia real.

La forma correcta de abordarlo es medir, no adivinar: activa el log de consultas lentas de la base de datos durante unos días y mira qué aparece. El enfoque es el mismo que aplicamos en cualquier revisión técnica de una plataforma heredada: datos antes que intuiciones.

12. Errores frecuentes en instalaciones reales

• Usar el Ruby del sistema sin fijar versión. La distribución actualiza, las gemas nativas dejan de cargar y la aplicación no arranca después de un apt upgrade rutinario.
• Adjuntos dentro del directorio de la aplicación. Convierte cada upgrade en una operación delicada.
• Olvidar client_max_body_size en Nginx. Errores 413 inexplicables para el usuario.
• No guardar secret_token en el backup. Restauras y todas las sesiones y los tokens quedan invalidados.
• Instalar plugins sin comprobar mantenimiento. Cada plugin abandonado es un upgrade futuro bloqueado.
• Dejar la instancia expuesta a internet sin necesidad. Restringir el acceso es la medida más barata y efectiva.
• No probar nunca la restauración. El error más caro de todos, y el más común.

13. Conclusión

Redmine es una herramienta que envejece bien: su modelo de datos apenas ha cambiado en veinte años, la migración entre versiones está documentada y el proyecto sigue publicando actualizaciones de seguridad con diligencia. Eso lo convierte en una opción sólida para quien quiere control sobre sus datos y un coste que no crece con la plantilla. Pero autoalojar implica aceptar una responsabilidad: la de mantenerlo.

Si al leer esta guía has identificado más de dos puntos que no cumples —una serie sin soporte, un backup nunca restaurado, plugins sin mantenimiento, adjuntos mezclados con la aplicación—, no es una emergencia, pero sí una lista de tareas con fecha. Empieza por el backup verificado, sigue por la actualización a una serie soportada y termina por el hardening. En ese orden.

Preguntas frecuentes

¿Cuánto cuesta realmente autoalojar Redmine?

El software es gratuito; el coste es el servidor y el tiempo de administración. Para un equipo de 30 personas, un VPS adecuado ronda cifras muy modestas frente a una licencia por usuario de una herramienta SaaS equivalente. El coste real que hay que presupuestar es el mantenimiento: upgrades, backups y soporte. Si no hay nadie con ese tiempo asignado, externalizarlo suele salir más barato que asumir el riesgo de una instancia desatendida.

¿Puedo migrar mis datos desde Jira o Trello?

Sí. Redmine dispone de API REST completa para crear proyectos, peticiones, usuarios y adjuntos, y existen scripts de importación para los formatos de exportación habituales. La parte laboriosa nunca es el volcado de datos, sino el mapeo de estados, flujos de trabajo y campos personalizados entre ambas herramientas: conviene diseñarlo antes de escribir una sola línea de script.

¿Qué versión de Ruby debo usar con la serie 7?

Ruby 3.2 o superior funciona. Si eliges Ruby 4.0, usa 4.0.4 o posterior por la regresión conocida en el renderizado del wiki de las versiones anteriores de esa rama.

¿Es seguro exponer Redmine a internet?

Puede serlo, con HTTPS, 2FA, la última versión de una serie soportada y acceso restringido en lo posible. Ahora bien, si todos tus usuarios se conectan desde la oficina o por VPN, no hay razón para exponerlo: reducir la superficie de ataque es siempre la medida más rentable.

¿Cada cuánto conviene actualizar?

Las actualizaciones de seguridad, en cuanto salen —la 7.0.1 de agosto de 2026 corregía cinco vulnerabilidades, algunas explotables desde la API—. Los saltos de versión mayor, una vez al año, planificados, con ensayo previo en preproducción y ventana de mantenimiento anunciada.