/
Backstage vs. Cycloid: comparativa de IDP 2026
A medida que los equipos de plataforma crecen, los problemas del día a día aparecen justo donde los ingenieros trabajan: un cambio de Terraform se aplica sin revisión, un clúster efímero sigue en marcha cuando acaba el sprint, o no está claro quién es el responsable de un servicio cuando algo falla. El primero es operativo: un cambio de Terraform llega a producción antes de que nadie revise el plan, un clúster de prueba de concepto sigue encendido porque ningún equipo se ocupa de apagarlo, o un entorno se desvía de su estado declarado y nadie se da cuenta hasta que algo se rompe. El segundo es organizativo: un desarrollador no consigue identificar rápidamente quién es el responsable del servicio de pagos, y la incorporación de un ingeniero nuevo se convierte en rebuscar entre hilos de Slack, pull requests antiguas y documentación interna para reconstruir el contexto.
vs
Escrito por
El equipo de Cycloid
Platform engineering
Publicado el
30 de julio de 2026
Tiempo de lectura
18 min de lectura
Backstage vs. Cycloid
Los equipos empiezan a evaluar Cycloid frente a Backstage cuando su plataforma de desarrollo interna se queda en la visibilidad del catálogo de servicios o no consigue controlar cómo se ejecutan los cambios de infraestructura, con las consiguientes lagunas de cumplimiento, de propiedad o de trazabilidad. Ambos resuelven problemas distintos, en capas distintas, y con supuestos distintos sobre dónde debe aplicarse el control.
Cada uno resuelve una preocupación distinta de la plataforma: uno estructura la propiedad de los servicios y reduce el esfuerzo de localizar sistemas y contexto; el otro gobierna cómo cambia realmente la infraestructura. Al final de este análisis sabrás cuál de las dos carencias le está costando más a tu organización.
El compromiso fundamental
Backstage
Backstage es un framework open source de portal para desarrolladores, creado originalmente por Spotify y hoy un proyecto de la CNCF. Centraliza en una sola interfaz la propiedad de los servicios, la documentación técnica y las plantillas de golden path. Los equipos lo usan para reducir la fricción de averiguar qué existe, quién lo mantiene y cómo construir cosas nuevas de forma coherente. Backstage no ejecuta infraestructura: la describe.
La plataforma única
Cycloid es una plataforma de desarrollo interna que trata la entrega de infraestructura como algo que la propia plataforma debe poseer y gobernar. Los planes de Terraform, las aprobaciones, las comprobaciones de políticas y las estimaciones de coste pasan todos por una ruta controlada antes de que nada toque el cloud. Los desarrolladores solicitan cambios mediante formularios respaldados por stacks versionados en Git, y la plataforma aplica el alcance y los permisos en cada paso.
FLEXIBILIDAD vs. TIEMPO DE PUESTA EN VALOR
Matriz de decisión
Matriz de decisión: Backstage vs. Cycloid
Comparar Backstage y Cycloid se reduce a un compromiso central: flexibilidad frente a tiempo de puesta en valor. Backstage es open source y muy personalizable, pero normalmente exige entre 2 y 4 ingenieros de plataforma dedicados para instalarlo, mantenerlo y ampliarlo. Cycloid se despliega en menos de 2 horas, con gobernanza multi-cloud y FinOps integrados. Esta página te da los datos cara a cara para decidir cuál encaja con tu equipo.
01
Dónde se ejecuta Terraform y dónde viven las credenciales
El modelo de despliegue importa porque determina dónde viven las credenciales, los archivos de estado y los registros de auditoría. Para los equipos sujetos a requisitos de residencia de datos o que operan en entornos air-gapped, esto no es una preferencia estética: es un requisito de cumplimiento.
Cycloid admite SaaS, instancias gestionadas dedicadas y despliegues totalmente autoalojados, incluidos entornos sin acceso saliente a internet. Cycloid orquesta la ejecución de Terraform a través de su motor de pipelines, donde los plan y los apply se ejecutan en entornos controlados con acceso a credenciales gestionadas de forma centralizada. La plataforma está diseñada con ese requisito en mente, no añadido a posteriori.
Backstage suele ser autoalojado y, aunque Spotify no ofrece un SaaS oficial gestionado de Backstage, sí existen ofertas y distribuciones comerciales gestionadas de proveedores como Spotify y socios de Red Hat. Los equipos construyen y despliegan su propia instancia, normalmente sobre Kubernetes, con una base de datos PostgreSQL y una imagen de Docker propia que empaqueta los plugins que usa la organización. Backstage ofrece herramientas para construir la imagen de Docker de tu instancia, pero se espera que sea el equipo quien la ensamble y la compile, con los plugins y la configuración necesarios, antes de desplegarla. Red Hat ofrece una distribución empresarial con soporte (Developer Hub) para organizaciones que quieren una build mantenida comercialmente sobre OpenShift, pero el Backstage upstream exige que el equipo se haga cargo del pipeline de build, de las actualizaciones de dependencias y de la compatibilidad de los plugins entre versiones. A escala, ese compromiso operativo no es trivial.
De serie, Backstage no maneja credenciales de infraestructura ni estado de Terraform, así que su superficie de seguridad es más estrecha; ampliarlo para gestionar esas capas o interactuar con ellas suele exigir plugins adicionales o trabajo de integración a medida. Se conecta con el control de versiones, los sistemas de CI y las herramientas de observabilidad, pero no ejecuta operaciones privilegiadas sobre la infraestructura. Las responsabilidades de ejecución más amplias de Cycloid vienen acompañadas de requisitos de aislamiento de datos más estrictos y de los controles de despliegue correspondientes.
CARACTERÍSTICA
BACKSTAGE
Modelo de despliegue
SaaS, gestionado dedicado o totalmente autoalojado, incluido air-gapped
Solo autoalojado; el equipo construye y opera su propia instancia
Control de la residencia de datos
El estado de la infraestructura, los registros de ejecución y las credenciales pueden permanecer en redes controladas por el cliente
Sin oferta gestionada; el equipo controla los datos operando él mismo la plataforma
Propiedad del runtime de la plataforma
Cycloid opera el nivel SaaS; las instancias dedicadas puede operarlas el cliente o gestionarlas Cycloid
El equipo es dueño de todo el runtime: builds de la imagen, actualizaciones de plugins, base de datos y versiones
Gestión de credenciales de infraestructura
Las credenciales cloud se almacenan y se usan dentro del runtime de la plataforma durante el plan y el apply
Sin almacenamiento de credenciales; el acceso a la infraestructura ocurre en sistemas de CI externos
Encaje en entornos regulados
Adecuado cuando la ejecución y las aprobaciones de infraestructura deben permanecer en redes privadas o aisladas
Adecuado cuando el equipo puede asumir la carga de ingeniería de operar el portal por su cuenta
02
Quién es dueño de la ejecución del plan y el apply de Terraform
El Scaffolder de Backstage puede disparar workflows externos, incluidos los que ejecutan Terraform. Una plantilla puede crear un repositorio, subir archivos de configuración y lanzar un workflow de GitHub Actions que ejecute terraform apply. Eso no es lo mismo que ser dueño de la ejecución. Las garantías de gobernanza de ese apply dependen por completo de cómo esté configurado el pipeline de CI externo, de qué protecciones de rama existan y de si alguien ha conectado una comprobación de políticas. Backstage inicia los workflows, pero no participa en su ejecución. Una vez disparado el pipeline, el control depende enteramente de sistemas externos —la configuración de CI, los permisos de IAM, los controles del repositorio—, ninguno de los cuales gobierna Backstage.
Cycloid es dueño de la ruta de ejecución: los runs de Terraform y Ansible ocurren dentro del motor de pipelines de la plataforma, respaldados por stacks versionados en Git que controla el equipo de plataforma. Los desarrolladores envían peticiones a través de StackForms, que limitan las entradas a variables predefinidas, tipos de instancia y parámetros validados por políticas. La plataforma evalúa las InfraPolicies antes de ejecutar, detecta desviaciones comparando el estado de Terraform y los cambios previstos con la infraestructura real durante la evaluación de políticas, y lleva el estado de forma centralizada en todos los entornos. Un entorno no puede quedarse abandonado sin que la plataforma lo sepa, porque es la plataforma la que gestiona su ciclo de vida.
Si los incidentes se remontan a clústeres olvidados, a planes que se saltan el proceso o a cambios en producción que no siguieron la ruta prevista, Cycloid ataca esos modos de fallo en su origen. Backstage, por diseño, no.
CARACTERÍSTICA
BACKSTAGE
Ejecución de Infrastructure as Code
Ejecuta los plan y apply de Terraform y Ansible como parte del workflow de la plataforma
No ejecuta IaC; el Scaffolder puede disparar pipelines externos que sí lo hagan
Conocimiento del estado de Terraform
Lleva el estado de Terraform de forma centralizada en todos los entornos y workspaces
Sin gestión de estado; enlaza a repositorios o a herramientas externas
Detección de desviaciones
Compara la configuración declarada con la infraestructura real en cada entorno mediante InfraPolicy
Sin detección de desviaciones integrada; solo a través de plugins de terceros (por ejemplo, Firefly)
Control del ciclo de vida de los entornos
Crea, actualiza y retira entornos mediante workflows gobernados
El ciclo de vida de los entornos se gestiona en pipelines de CI externos o en herramientas de IaC
Visualización de la infraestructura
Muestra la topología y los recursos reales asociados a cada entorno mediante InfraView
Muestra metadatos de servicio, enlaces a repositorios y estado de CI, sin topología de infraestructura
03
Cómo se solicitan y se aplican los cambios de entorno
El modelo de autoservicio de Backstage gira en torno a plantillas estandarizadas para crear servicios y componentes. El Scaffolder permite a los equipos de plataforma publicar plantillas que los desarrolladores ejecutan para crear servicios, repositorios o componentes con la forma correcta desde el primer día. El desarrollador elige una plantilla, rellena un formulario y obtiene un repositorio con el pipeline de CI, los hooks de monitorización y los metadatos de propiedad ya conectados. Esa estandarización en el momento de la creación tiene valor: reduce el número de servicios que se desvían de las normas de la organización antes incluso de cumplir una semana.
Lo que Backstage no hace es gobernar las operaciones de día 2 sobre la infraestructura existente. Actualizar un entorno, redimensionar un clúster o retirar un recurso ocurre fuera de Backstage, en pipelines externos donde su modelo de permisos no se aplica. El framework de permisos sí permite a los equipos de plataforma restringir quién puede lanzar cada plantilla del Scaffolder, pero esos controles cubren la ejecución de la plantilla, no los cambios de infraestructura que esa plantilla desencadena aguas abajo.
El modelo de autoservicio de Cycloid cubre tanto el aprovisionamiento inicial como los cambios posteriores. Los desarrolladores solicitan entornos o modificaciones mediante StackForms, que solo exponen las variables que el equipo de plataforma ha decidido exponer para cada stack. Los flujos de aprobación se ejecutan antes de la ejecución, no en paralelo. Toda acción, ya sea crear un entorno nuevo o cambiar el tamaño de una instancia de base de datos, sigue la misma ruta gobernada y deja la misma traza de auditoría.
CARACTERÍSTICA
BACKSTAGE
Qué puede hacer un desarrollador en la plataforma
Enviar peticiones para crear o modificar entornos usando stacks de Terraform aprobados
Ejecutar plantillas del Scaffolder para crear componentes nuevos; consultar y actualizar entradas del catálogo de servicios
Cómo se crea un entorno
La plataforma genera la configuración del stack respaldada por Git y ejecuta Terraform de forma controlada
El Scaffolder dispara pipelines externos; el aprovisionamiento real ocurre fuera de Backstage
Límites en las entradas
Los campos se limitan a variables predefinidas, tipos de instancia y parámetros validados por políticas
Las entradas de una plantilla pueden validarse dentro de la plantilla, pero no hay control sobre los parámetros del pipeline externo
Flujo de aprobación
Pasos de aprobación integrados antes del plan y del apply de Terraform
Sin flujo de aprobación nativo para infraestructura; las aprobaciones se gestionan en el control de versiones o en la CI externa
Qué ocurre si falla una política
El cambio se bloquea antes del apply
El control de políticas debe existir en la CI externa o en las herramientas de IaC
04
Dónde se aplican las comprobaciones de políticas y las aprobaciones
La gobernanza falla cuando se apoya en la costumbre en lugar de en el control. Si tu regla de rama protegida es el control principal que impide cambios de Terraform sin revisar, cualquiera que pueda saltársela, o que trabaje en un repositorio que no la tenga, queda fuera del modelo de gobernanza. No es una hipótesis: es una brecha que se ensancha a medida que se multiplican los equipos, los repositorios y los pipelines.
Cycloid aplica RBAC a nivel de stack y de entorno. Los roles controlan quién puede solicitar, aprobar, planificar o aplicar cambios de infraestructura, y la plataforma los comprueba antes de que empiece la ejecución. Las evaluaciones de InfraPolicy se ejecutan antes del terraform plan y pueden bloquear cambios según el tipo de recurso, el entorno de destino o las entradas declaradas. Los registros de auditoría recogen la cadena completa: quién pidió el cambio, quién lo aprobó, qué comprobaciones de políticas se ejecutaron y qué infraestructura se modificó. Esa cadena de auditoría vive en Cycloid, no repartida entre tres sistemas que hay que consultar por separado.
El framework de permisos de Backstage, introducido de forma progresiva desde 2022, permite a los equipos de plataforma controlar quién puede lanzar plantillas del Scaffolder, ver entidades del catálogo o realizar operaciones sobre las tareas del Scaffolder. Es un conjunto de controles relevante para el propio portal. Pero no se extiende a los pipelines de infraestructura que Backstage dispara. Un workflow de GitHub Actions que ejecuta terraform con permisos de IAM elevados se ejecuta con el acceso que tenga ese workflow, diga lo que diga el framework de permisos de Backstage. La frontera de la gobernanza termina donde termina el alcance de ejecución de Backstage.
Los equipos de cumplimiento que preguntan «¿podemos demostrar que este cambio de infraestructura se revisó y se aprobó antes de aplicarse?» obtienen una respuesta completa del registro de auditoría de Cycloid. Con Backstage, esa pregunta obliga a agregar datos del repositorio, del sistema de CI y del mecanismo de aprobación que se hubiera configurado allí.
CARACTERÍSTICA
BACKSTAGE
Control de acceso basado en roles
Se aplica a nivel de stack y de entorno, controlando quién puede solicitar, aprobar, planificar o aplicar
Controla el acceso a los metadatos del catálogo y a las plantillas del Scaffolder; para la infraestructura hereda del proveedor de Git y de la CI
Aplicación de políticas
InfraPolicy (política como código) se ejecuta antes del plan y del apply de Terraform y bloquea los cambios no conformes
Sin evaluación de políticas sobre despliegues externos; Backstage no intercepta la ejecución de la CI ni del IaC
Flujos de aprobación
Pasos de aprobación nativos en el workflow de entrega, obligatorios antes de que avancen los plan o los apply
Las aprobaciones ocurren en sistemas externos; Backstage enlaza a ellos pero no los impone
Registro de auditoría
Registros centralizados que recogen peticiones, aprobaciones, resultados de políticas y cambios de infraestructura en un solo sitio
Datos de auditoría repartidos entre commits de Git, registros de CI y Jira; Backstage muestra referencias pero no los consolida
Postura de cumplimiento
Impide los cambios no conformes aplicando los controles en la propia ruta de entrega
Documenta el estado de cumplimiento mediante scorecards y metadatos de propiedad, sin bloquear la ejecución
05
Cuándo se calcula el impacto en coste y cuándo puede bloquear un cambio
Un cambio de infraestructura que duplica la factura cloud cae igual haya pasado o no por revisión de código. Los procesos de revisión detectan errores de lógica. No detectan sorpresas de coste, salvo que alguien ejecute infracost en local, lea la salida y decida hacer algo al respecto: tres pasos voluntarios que se caen en cuanto aprieta una fecha de entrega.
Cycloid integra la estimación de costes directamente en la ruta de entrega mediante su motor open source TerraCost. Antes de que se ejecute un cambio lanzado desde StackForms, la plataforma calcula la diferencia de coste estimada a partir del plan de Terraform. Los equipos de plataforma pueden configurar umbrales de presupuesto que bloqueen los apply automáticamente: un cambio que superara un umbral aprobado no sigue adelante sin un escalado explícito. Los datos de coste reales se agregan por proyecto, entorno y proveedor cloud en una única vista. La plataforma también hace seguimiento de la huella de carbono asociada a la infraestructura desplegada, dando a las métricas de sostenibilidad la misma visibilidad que a las financieras.
Backstage puede mostrar información de costes mediante plugins. El plugin de Infracost, por ejemplo, muestra estimaciones de coste para las entidades del catálogo. Pero ningún plugin de Backstage condiciona la ejecución de la infraestructura en función del coste. El plugin enseña el dato; qué pasa con ese dato, y si cambia el comportamiento de alguien antes de que se ejecute un despliegue, no es algo que Backstage controle. En Backstage la visibilidad de costes es informativa. En Cycloid el control de costes es estructural.
Este montaje resulta pesado de operar, porque la visibilidad de costes depende de herramientas de terceros como Kubecost, lo que introduce dependencias adicionales y cierto grado de dependencia del proveedor.
CARACTERÍSTICA
BACKSTAGE
Estimación de coste previa al despliegue
TerraCost calcula el coste cloud estimado a partir del plan de Terraform antes del apply
El plugin de Infracost puede mostrar datos de coste, pero no condiciona los despliegues
Control del presupuesto
Umbrales de presupuesto aplicados mediante comprobaciones de políticas; los cambios que superan el límite se bloquean
Sin mecanismo para bloquear despliegues en función del coste
Visibilidad del coste real
Gasto multi-cloud agregado por entorno, proyecto y proveedor en una única vista
Datos de coste disponibles solo a través de integraciones externas mostradas en el portal
Señales de sostenibilidad
Huella de carbono monitorizada por entorno desplegado
Sin seguimiento nativo de sostenibilidad
Momento del control de costes
El coste se evalúa antes de crear o modificar los recursos
El coste solo es visible una vez que los recursos existen
Si la información anterior es inexacta o está desactualizada, contáctanos en marketing@cycloid.io y lo corregiremos de inmediato.
Cómo elegir
Cómo elegir
Los equipos de plataforma de empresa rara vez se enfrentan a un único problema aislado: los problemas aparecen a la vez en la ejecución, en la propiedad y en el coste, mientras el equipo responsable de resolverlos sigue siendo pequeño. La elección entre Cycloid y Backstage depende de dónde se rompe la cadena dentro de tu plataforma de desarrollo interna.
Cycloid encaja en equipos donde el fallo aparece durante la ejecución de la infraestructura: los planes de Terraform se ejecutan fuera de una ruta controlada, los entornos siguen activos sin seguimiento de su ciclo de vida, y existen requisitos de políticas que no se aplican en tiempo de ejecución. Cycloid encamina todos los cambios por su motor de pipelines usando stacks respaldados por Git, con StackForms controlando la entrada, InfraPolicy evaluando los cambios antes de ejecutarlos y un seguimiento centralizado del estado en todos los entornos. La estimación de costes y los pasos de aprobación forman parte de ese mismo flujo, así que los cambios se evalúan antes de llegar al apply. En estas condiciones, saber qué existe no basta: lo que evita las desviaciones y los entornos sin control es gobernar cómo se ejecutan los cambios.
Backstage encaja en equipos donde lo que se rompe es la propiedad de los servicios y la capacidad de encontrarlos: los desarrolladores pierden tiempo identificando responsables, la incorporación depende de documentación dispersa y los estándares varían porque no hay un punto de entrada único. Backstage lo resuelve con su Software Catalog y su Scaffolder, que estructuran los metadatos de servicio y aportan plantillas para crear componentes nuevos. Mejora cómo los equipos descubren el terreno y arrancan el trabajo, pero no participa en cómo se ejecutan los cambios de infraestructura una vez disparado un workflow.
Las dos herramientas pueden convivir y, en organizaciones grandes, a menudo conviven. La versión honesta del compromiso es esta: si la causa raíz de tus incidentes está en la ruta de ejecución, un portal para desarrolladores no va a evitarlos. Si la causa raíz de tus retrasos está en la coordinación y en encontrar las cosas, un plano de control de infraestructura no va a arreglarlo.
Preguntas frecuentes
Backstage es un framework open source de portal para desarrolladores creado por Spotify que da control total sobre la personalización, pero exige entre 2 y 4 ingenieros de plataforma dedicados para construirlo, mantenerlo y ampliarlo. Cycloid es una plataforma de desarrollo interna comercial que se despliega en menos de 2 horas, con gobernanza multi-cloud nativa, módulos FinOps integrados y sin necesidad de un equipo de operaciones dedicado. El compromiso de fondo es techo de personalización (Backstage) frente a tiempo de puesta en valor y menor carga operativa (Cycloid).
Backstage se descarga gratis bajo licencia Apache 2.0. Los costes ocultos están en las personas: un mínimo de 2 a 4 ingenieros de plataforma dedicados a instalar, mantener y ampliar el portal. A un coste medio totalmente cargado de 120.000 €/año por ingeniero, eso son entre 240.000 y 480.000 €/año solo en plantilla. Los equipos también declaran dedicar entre el 30 % y el 40 % del tiempo de platform engineering al mantenimiento de plugins en lugar de al desarrollo de funcionalidades.
Un despliegue de Backstage listo para producción suele tardar entre 6 y 12 meses. La instalación inicial es rápida, pero configurar los plugins, construir integraciones a medida, montar la autenticación y conectar los sistemas internos añade un plazo considerable. Cycloid, en cambio, se despliega en menos de 2 horas con módulos ya construidos de CI/CD, gobernanza y FinOps, reduciendo el camino hasta el primer valor de meses a días.
Para equipos de plataforma que no tienen de 2 a 4 ingenieros libres para dedicarlos al desarrollo del portal, un IDP comercial como Cycloid es una alternativa práctica. Cycloid aporta de serie un portal de autoservicio, catálogo de servicios (Stacks y StackForms), gobernanza multi-cloud y FinOps, sin exigir un equipo dedicado al portal. Encaja con equipos que necesitan entregar valor de platform engineering rápido sin asumir la carga de mantenimiento de una construcción propia.
Cycloid suele tener un coste total de propiedad menor para equipos que no cuentan ya con un escuadrón de platform engineering dedicado a mantener Backstage. La licencia de Backstage es gratuita, pero de 2 a 4 ingenieros a jornada completa a 120.000 €/año cada uno suponen entre 240.000 y 480.000 €/año en coste de personal antes de que el portal llegue a producción. La licencia comercial de Cycloid incluye soporte, FinOps integrado y gobernanza multi-cloud, y elimina esa carga oculta de plantilla y mantenimiento.
¿Quieres ver cómo se compara Cycloid con Backstage para tu equipo?
Descubre en acción el portal de autoservicio de Cycloid, sus módulos FinOps y su gobernanza multi-cloud. O sigue explorando la plataforma de desarrollo interna y descubre cómo Cycloid aporta el valor del platform engineering sin la carga de construirlo todo tú.