Resumen

●​ Backstage (Open Source): marco open-source de Spotify para construir un Internal

Developer Portal (IDP) altamente personalizable. Ideal si querés control total, flexibilidad
y coste de licencia 0, pero requerirá más trabajo de integración/operación en
producción. GitHub+1​

●​ Red Hat Developer Hub (RHDH): versión empresarial/soportada por Red Hat basada
en Backstage, empaqueta pre-configuraciones, plugins verificados, gestión por
Operator/Helm y soporte empresarial (incluye integración con OpenShift, Keycloak,
ArgoCD, etc.). Excelente opción si usás OpenShift o buscás entrega “enterprise” con
soporte y features listas. Red Hat Developer+1​

Tabla rápida (compare one-pager)

Criterio Backstage (OSS) Red Hat Developer Hub (RHDH)

Complejidad de Baja (npx create-app, SQLite Moderada (Operator/Helm en

instalación (PoC) local). [Link] OpenShift — requiere admin cluster).
[Link]

Complejidad de Media-Alta (Postgres, Media (soportado con Operator/Helm;

instalación autenticación, storage, CI/CD, requisitos empresariales
(Producción) k8s recomendado). documentados; opciones air-gapped).
[Link] [Link]+1

Integraciones Muchas por comunidad Plugins pre-configurados, gestión de

out-of-the-box (plugins), pero plugins dinámica y verificada por Red
auto-configuración manual. Hat. Red Hat Developer+1
[Link]+1

Soporte / SLA Comunidad / self-support Soporte Red Hat (SLA, parches, CVE
handling) Red Hat Developer

Seguridad & Depende de tu Integración Enterprise (Keycloak,

Enterprise features implementación audit logs, adoption insights)
(Keycloak/LDAP, RBAC) [Link]
Migración / Nativo (es Backstage) — buen RHDH está basado en Backstage ⇒
compatibilidad ecosistema de migración migración técnica posible y acelerada.
GitHub

Recomendado para Equipos con capacidad Empresas en OpenShift que quieran

SRE/Platform que quieran solución soportada y lista para uso
control total

Detalle técnico
1) Complejidad de instalación
Backstage (OSS)

●​ PoC/local: npx @backstage/create-app → arranca con SQLite en minutos (ideal

para demos). [Link]
●​ Producción: se recomienda desplegar en Kubernetes/containers, usar PostgreSQL para
catálogo y user data, configurar autenticación (OIDC/LDAP/Keycloak), storage para
TechDocs y CI para construir imágenes. Requiere pipeline de builds, secretos y
observabilidad. [Link]+1​

Red Hat Developer Hub (RHDH)

●​ Instalación orientada a OpenShift (Operator o Helm chart). También hay guía para
instalar en otras plataformas (EKS/AKS/GKE) y entornos air-gapped. Requiere
privilegios cluster-admin para instalar Operator/CRs o permisos para Helm + recursos
asociados. [Link]+1
●​ RHDH ofrece plantillas, CRDs y recursos preconfigurados (menos trabajo inicial que
montar Backstage desde 0). Artifact Hub​

2) Uso y experiencia de desarrollador

●​ Backstage: experiencia muy personalizable; plugins como TechDocs, Software
Templates, Catalog, Scaffolder, etc. Muy usado por equipos que desean “portales a
medida”. Requiere que el equipo Platform implemente y mantenga los
templates/plugins. [Link]+1​
 ●​ RHDH: añade experiencia más “empresarial” (audit, adoption insights, plantillas
verificadas, integración con Red Hat Toolchain). Tiene foco en acelerar adopción y
reducir el trabajo de verificación de plugins. Red Hat Developer+1​

3) Integraciones y ecosistema
●​ Backstage: enorme ecosistema de plugins open-source (CI/CD, SCM, K8s, ArgoCD,
Sonar, Vault, etc.). Integración manual pero flexible. GitHub+1
●​ RHDH: incluye plugins pre-seleccionados/integrados (ArgoCD, Keycloak, Tekton/CI,
Topology, GitHub/GitLab integraciones) y capacidades de dynamic plug-ins para
instalar sin recompilar el portal (Red Hat promociona gestión de plugins dinámica). Esto
reduce fricción operativa. GitHub+1​

4) Migraciones y compatibilidad
●​ Migrar a RHDH desde Backstage: RHDH está basado en Backstage (mismas APIs y
catálogo), por lo que gran parte del trabajo (catalog entities, techdocs, templates) es
portable. Red Hat ofrece documentación y herramientas para facilitar la
adopción/compatibilidad. Aun así, custom-plugins muy específicos requerirán
adaptación y testing. GitHub+1
●​ Mover fuera de RHDH / volver a Backstage puro: posible técnicamente porque RHDH
extiende Backstage, pero si te apoyás en features empresariales (dynamic plugins
gestionados, integraciones Red Hat), deberás planear el reemplazo de esas piezas.​

5) Requerimientos (mínimos y recomendados)

Backstage (producción recomendada)

●​ [Link] / Yarn para build.

●​ PostgreSQL (producción) — catálogo y usuarios.
●​ Kubernetes + Helm (recomendado) o despliegue en contenedores con CI.
●​ Storage para TechDocs (S3/GCS/MinIO). [Link]+1​

RHDH

●​ OpenShift Container Platform (recomendado) — Operator/Helm. También soporta

EKS/AKS/GKE vía Helm/Operator.
●​ Identidad empresarial (Keycloak / IdP corporativo).
●​ Requisitos de red/privilegios para deploy (cluster admin para operator).
 ●​ Opciones para air-gapped y certificaciones Red Hat. [Link]+1​

6) Pros / Contras (prácticos, para presentar)

Backstage (OSS)

Pros

●​ Máxima flexibilidad y control; comunidad grande; no hay costo de licencia. GitHub

●​ Ecosistema de plugins amplio; fácil empezar con PoC local. [Link]​

Contras

●​ Mayor esfuerzo operativo en producción (DB, auth, scaling, backups). [Link]

●​ No hay soporte comercial oficial (salvo terceros/partners) — depende de la propia
SRE/Platform.​

Red Hat Developer Hub (RHDH)

Pros

●​ Entrega empresarial: soporte Red Hat, parches, guías, plugins verificados y plantillas
empresariales. Red Hat Developer+1
●​ Instalación y gestión facilitada en OpenShift (Operator/Helm) y workflows para empresas
(audit logs, adoption insights). [Link]
●​ Dynamic plug-ins y pre-configuraciones que reducen time-to-value. Red Hat Developer

Contras

●​ Requiere entorno compatible (ideal OpenShift) y podría implicar coste por

soporte/licenciamiento (si se usa soporte RH).
●​ Menor control absoluto sobre actualizaciones si se busca customizar muy
profundamente (aunque sigue siendo extensible — es Backstage por debajo). GitHub

Anexo: pasos de instalación (resumen

operativo)
Abajo tenés dos anexos separados y listos para pegar en la documentación: Backstage
(OSS) y Red Hat Developer Hub (RHDH). Cada uno incluye: prerequisitos, pasos rápidos
(PoC y producción), verificación y notas de troubleshooting/recomendaciones. He dejado los
comandos y fragmentos YAML más usados.

A) Backstage (Open Source) — Pasos de

instalación
0) Prerrequisitos
●​ Máquina local o servidor Linux / CI que pueda construir imágenes Docker.
●​ [Link] ≥ 18 y Yarn (para scaffolding / build).
●​ Git, Docker (para imágenes) y acceso a un registry (Docker Hub / Artifact Registry).
●​ Para producción: Kubernetes (recomendado), PostgreSQL (producción),
almacenamiento para TechDocs (S3/GCS/MinIO). [Link]+1​

1) PoC / demo local (rápido — 10–30 min)

1.​ Crear app:​

npx @backstage/create-app@latest
cd my-backstage-app
yarn dev

2.​ Abrir [Link] y validar que el frontend y backend arrancan (demo

usa SQLite local). [Link]​

Verificación PoC: acceder a / y ver catálogo; ejecutar yarn test si querés validar
instalación.
2) Build de imagen Docker (para correr en
contenedor/K8s)
1.​ Desde el repo generado:​

# ejemplo simplificado
yarn build
docker build -t [Link]/my-backstage:1.0.0 .
docker push [Link]/my-backstage:1.0.0

2.​ Preparar variables de entorno (ej.: APP_CONFIG_*, DATABASE_URL,

NODE_ENV=production) antes de ejecutar.​

Nota: en producción usar PostgreSQL (no SQLite) y configurar DATABASE_CLIENT=pg y

DATABASE_URL. [Link]

3) Despliegue recomendado en Kubernetes (producción)

— alto nivel
1.​ Crear namespace / secret para acceso al registry y credenciales DB.​

2.​ Desplegar PostgreSQL (managed DB o StatefulSet) y crear DB/usuario para Backstage.​

3.​ Usar un Helm chart o manifests para desplegar el backend + frontend container, service
y Ingress. Hay charts disponibles (artifact hub / community). Artifact Hub+1​

Ejemplo de valores mínimos ([Link])

image:
repository: [Link]/my-backstage
tag: "1.0.0"
database:
client: pg
 connection:
"postgresql://backstage:password@[Link]
32/backstage"
ingress:
enabled: true
host: [Link]

4.​ Configurar TechDocs storage (S3/GCS/MinIO) y apuntar

[Link]/credentials.
5.​ Habilitar autenticación OIDC/LDAP con el IdP corporativo (Keycloak, Okta, Azure AD) —
configurar auth y [Link]. [Link]​

Verificación en K8s: kubectl get pods -n <ns> → pods Ready; acceder via Ingress
host; probar login OIDC y subir un TechDoc.

4) Checklist posterior / recomendaciones

●​ Backups periódicos de PostgreSQL y archivos de TechDocs.
●​ Monitorización: métricas y logs (Prometheus / Grafana / ELK).
●​ Pipeline CI: build automatizado de imágenes, test e implementación (canary/rolling).
●​ Seguridad: habilitar HTTPS en Ingress, añadir CSP headers, revisar plugins externos
antes de habilitarlos. [Link]​

5) Troubleshooting rápido
●​ Arranque lento / 500s: revisar DATABASE_URL y que la DB acepte conexiones
(migraciones).
●​ Problemas con OIDC: revisar auth config y relojes (NTP) entre Backstage y IdP.
●​ Plugins que rompen frontend: verificar versiones y rebuild del app (frontend/backend).​
B) Red Hat Developer Hub (RHDH) —
Pasos de instalación (OpenShift /
Kubernetes)
RHDH es la distribución empresarial de Backstage de Red Hat; tiene Operator y
Helm chart como vías oficiales de instalación en OpenShift (y soporta AKS/EKS
con matices). Los pasos siguientes resumen el flujo recomendado por Red Hat.
[Link]+1

0) Prerrequisitos
●​ OpenShift Container Platform (recomendado) o Kubernetes compatible.​
Usuario con permisos cluster-admin (para instalar Operator) o permisos
administrativos en el proyecto donde se desplegará.
●​ Acceso a Image registry (puede usarse el interno de OpenShift)
●​ ConfigMaps/Secrets previos: baseUrl, service-to-service credentials y otros
(según la guía de Red Hat). [Link]+1​

1) Instalar el Red Hat Developer Hub Operator (método

recomendado — admin)
1.​ Desde la consola OpenShift (Administrator perspective) → Operators > OperatorHub.
2.​ Buscar Developer Hub (o Red Hat Developer Hub Operator), abrir y click Install.
Seleccionar canal de actualización (Stable/Default). [Link]​

Alternativa CLI (oc) — ejemplo (conceptual):

# instalar operatorgroup / subscription (ejemplo conceptual; seguir

doc RH exacta)
oc apply -f [Link]
oc apply -f [Link]
2) Provisionar configuración requerida (configmaps &
secrets)
●​ Crear en el proyecto/namespace donde desplegarás RHDH los ConfigMap y Secret que
el CRD Backstage espera (ej.: baseUrl, service-to-service secrets, S3/GCS
credentials para TechDocs). Red Hat detalla exactamente qué claves se requieren en la
guía de instalación. [Link]​

Ejemplo (very basic):

apiVersion: v1
kind: ConfigMap
metadata:
name: rhdh-config
data:
baseUrl: "[Link]
---
apiVersion: v1
kind: Secret
metadata:
name: rhdh-secrets
stringData:
serviceAccountKey: "<...>"

3) Crear instancia RHDH (CR) — desplegar Backstage via

Operator
1.​ En OpenShift Developer perspective → +Add → Operator Backed → seleccionar Red
Hat Developer Hub → Create.
2.​ Completar formulario (o usar la vista YAML) para rellenar el Backstage Custom
Resource (nombre, imágenes, referencia al dynamicPluginsConfigMapName si usás
plugins dinámicos). Guardar y crear. [Link]+1​

Ejemplo mínimo CR (fragmento):

apiVersion: [Link]/v1alpha3
kind: Backstage
metadata:
name: my-rhdh
spec:
application:
baseUrl: "[Link]
dynamicPluginsConfigMapName: dynamic-plugins-rhdh

4) Alternativa: instalar vía Helm chart

●​ Red Hat publica un Helm chart para RHDH (puede instalarse desde la consola o CLI
helm). Útil si preferís controlar parámetros con [Link]. [Link]+1​

Ejemplo (conceptual):

helm repo add rhdh [Link]

helm install rhdh my-rhdh/rhdh -n my-rhdh -f [Link]

5) Post-instalación y configuración
●​ Verificar pods: oc get pods -n <project> → pods Ready. Abrir URL.
[Link]
●​ Configurar IdP corporativo (Keycloak/LDAP) en la instancia RHDH (igual que Backstage,
pero RHDH suele exponer formularios/guías para esto).
●​ Dynamic plugins: si los vas a usar, crear ConfigMap y referenciarlo en el CR para que el
Operator los gestione dinámicamente. [Link]​

6) Checklist de enterprise
●​ Revisar roles/PSP/SCC (OpenShift security constraints) y permisos para Service
Accounts.
●​ Habilitar TLS/Route y certificados.
 ●​ Provisionar almacenamiento para TechDocs y backups de la DB (Postgres o servicio
gestionado).
●​ Plan de upgrades: usar los canales del Operator y probar en staging antes de prod.
[Link]​

7) Troubleshooting / notas prácticas

●​ Si el Operator no aparece en OperatorHub: validar suscripción de repositorios de
Operators en OCP y permisos de red.
●​ Fallos en arranque: revisar ConfigMap/Secrets obligatorios (baseUrl, service-to-service).
Red Hat documenta las claves requeridas en la guía de instalación. [Link]​