El 24 de abril de 2026, la política de entrenamiento de modelos de GitHub cambió para los planes individuales de Copilot. GitHub ahora puede usar las interacciones de Copilot Free, Pro, Pro+ y Max, incluidas entradas, salidas, fragmentos de código y el contexto asociado, para entrenar y mejorar modelos de IA salvo que el usuario se excluya. Los datos de Copilot Business y Enterprise siguen protegidos por el Acuerdo de Protección de Datos de GitHub. Lo importante: esto afecta a los datos de interacción con Copilot, no a los repositorios privados que simplemente están guardados sin usarse en GitHub.
Al mismo tiempo, los argumentos a favor de migrar reaparecieron por otro motivo: las instancias Git autoalojadas públicas estaban absorbiendo un tráfico automatizado intenso. Una discusión en Hacker News reunió un conjunto útil de informes de operadores sobre ese problema: El fin de una era para mí: se acabó el git autoalojado.
Eso deja una pregunta más útil que «¿GitHub o autoalojamiento?»: ¿qué preocupación intentas resolver realmente?
La versión corta
Tres respuestas. Elige la que encaje con tu situación.
- A: Excluirte y quedarte. Úsalo cuando el cambio de entrenamiento de Copilot sea tu única preocupación y GitHub siga encajando con las necesidades operativas de tu equipo. Desactiva el ajuste a nivel de cuenta y sigue adelante.
- B: Montar un híbrido. Deja el OSS público en GitHub por el efecto de red. Mueve el código privado a una instancia autoalojada de Forgejo, Gitea o GitLab CE detrás de una VPN o una lista de IP permitidas. Úsalo cuando el alcance público y el control privado importan a la vez.
- C: Migrar del todo. Saca todo de GitHub. Úsalo cuando la regulación, la residencia de datos, la gobernanza o una política de solo software libre descartan GitHub y el equipo puede asumir el coste operativo.
La mayoría de los lectores están en la posición A o B. La posición C se justifica por exigencias más estrictas de gobernanza, soberanía o valores, no por el ajuste de Copilot por sí solo.
Qué cambió realmente en abril de 2026
El cambio mecánico es pequeño. En los ajustes de Copilot, los suscriptores individuales pueden poner «Allow GitHub to use my data for AI model training» en Disabled. GitHub describe el material cubierto como las interacciones con sus funciones y servicios, incluidas entradas, salidas, fragmentos de código y contexto asociado, no el contenido de repositorios privados que nunca pasó por Copilot.
Copilot Business y Enterprise no muestran este interruptor porque sus datos están protegidos por el Acuerdo de Protección de Datos de GitHub. En los planes individuales, desactivar el ajuste resuelve la preocupación por la política de entrenamiento; no resuelve una objeción más amplia a depender de una política controlada por el proveedor.
El cambio de Copilot puede ser el detonante sin ser todo el caso. A un equipo también puede preocuparle la dependencia de la plataforma, la identidad ligada a GitHub, los flujos de trabajo construidos alrededor de Actions, la residencia de datos o lo fácil que le resultaría mudarse otra vez más adelante. Esas son cuestiones de migración; el interruptor de entrenamiento es solo un ajuste.
Esa distinción importa: excluirte cambia un ajuste de uso de datos, mientras que migrar cambia quién controla el alojamiento, la identidad, las integraciones y la política. La segunda decisión acarrea un coste operativo mucho mayor.
Las tres posturas explicadas
La decisión comprimida en tres filas. Los detalles, más abajo.
| Tu preocupación | Respuesta | Qué hacer |
|---|---|---|
| Mis datos de interacción con Copilot usados para entrenamiento | Excluirte y quedarte (posición A) | Cambia el ajuste y vuelve al trabajo |
| Código privado que no quiero en un proveedor estadounidense + OSS activo que no quiero esconder | Híbrido (posición B) | Autoaloja los repositorios privados detrás de una VPN; deja el OSS público en GitHub |
| Soberanía, sector regulado, principio de solo software libre, independencia total del proveedor | Migración completa (posición C) | Muévelo todo; presupuesta el coste operativo |
Posición A: excluirte y quedarte
Si eres un desarrollador en solitario o un equipo pequeño con repos privados y tu única queja es el valor por defecto del entrenamiento, esta es tu respuesta. Cambiar un ajuste: un minuto, una vez. Autoalojar: una pequeña factura de VPS, una estrategia de copias que de verdad pruebas, integraciones que rehacer porque daban por hecha la autenticación de GitHub, y la actualización o recuperación ocasional que cae en el peor momento posible.
Autoalojar puede seguir mereciendo la pena, pero solo si ese trabajo recurrente te compra algo que realmente necesitas.
La objeción más fuerte: el interruptor también es una decisión del proveedor. GitHub pasó, en 2026, de no usar por defecto estos datos de interacción para entrenar a usarlos por defecto, y podría volver a cambiar su política.
Si tu preocupación de fondo es «nunca quiero que un proveedor estadounidense tome decisiones unilaterales sobre mi código», ninguna casilla resuelve eso, y la posición A es la respuesta equivocada para ti. Salta a la posición C.
Pero si tu preocupación es en concreto «no quiero mis datos actuales de interacción con Copilot en el entrenamiento» y vas a confiar en el ajuste de GitHub hasta el próximo cambio, la posición A es la respuesta correcta más barata. No hay vergüenza en algo barato y correcto.
Posición B: montar un modelo híbrido
El alojamiento híbrido separa el alcance público del control privado.
El reparto es simple. El OSS público se queda en GitHub: efecto de red, cantera de colaboradores, Dependabot y el ecosistema de Actions son valor real. El código privado pasa a una instancia autoalojada detrás de una VPN o lista de IP permitidas, nunca alcanzable desde la internet pública.
Que esto funcione es una propiedad del modelo de amenazas. La preocupación por el entrenamiento de Copilot solo aplica a los datos de interacción con Copilot que envías por GitHub. El problema del tráfico de rastreadores de IA (siguiente sección) solo aplica a instancias accesibles públicamente. Un montaje híbrido privado esquiva ambos.
Para un equipo privado de 2 a 10 personas, 2 vCPU y 4 GB de RAM son un punto de partida más seguro para Forgejo o Gitea, con más margen si la indexación de búsqueda, los paquetes o la CI comparten el host. Toma eso como dimensionamiento de Forgejo/Gitea, no de GitLab CE: el tutorial de GitLab para instalación en un solo nodo empieza en 8 vCPU y 7,2 GB de memoria, antes de la carga de CI.
No expongas la interfaz web abiertamente en el 80 o el 443. Restríngela en el cortafuegos, el proxy, la VPN o la capa de red en malla. Los runners de CI pueden dar servicio a ambos lados.
La elección de plataforma cambia más el conjunto de funciones que el propio modelo híbrido. Forgejo y Gitea encajan con una forja privada más ligera; GitLab CE tiene más sentido cuando además necesitas una pila integrada de CI/CD y registro.
Las copias de seguridad son manejables, pero no las reduzcas a un git bundle. La guía oficial de actualización de Forgejo considera como copia fiable una instantánea sincronizada, en un momento dado, de todo el almacenamiento que usa Forgejo y, cuando eso no resulta práctico, un dump de Forgejo acompañado de un dump aparte de PostgreSQL o MySQL. Tanto para Forgejo como para Gitea, mantén juntos repositorios, base de datos, configuración, adjuntos y datos LFS, guarda una copia fuera del servidor y prueba una restauración.
El clon local de un desarrollador puede recuperar el código, pero no las incidencias, los usuarios, los metadatos de pull requests, los adjuntos ni todos los objetos LFS. Si un fork privado se hace público más adelante, súbelo entonces a un espejo en GitHub.
Posición C: migración completa cuando el control es un requisito
La migración completa encaja con más claridad cuando la independencia del proveedor es un requisito y no una preferencia.
Destacan tres grupos: equipos regulados con reglas de auditoría, residencia o control del proveedor que descartan GitHub; equipos del sector público o europeos cuyos requisitos de soberanía son política, no preferencia; y organizaciones de solo software libre que quieren salir de una infraestructura propiedad de Microsoft y ya cuentan con personal capaz de operar servicios Linux.
El coste es un VPS pequeño, mantenimiento continuo y pérdida de integraciones. La pérdida de integraciones es la parte que la gente olvida. Todo lo que se autentica con «Sign in with GitHub» se queda en GitHub o necesita un proveedor de identidad aparte.
Planifica la migración en torno a las dependencias, no solo a los repositorios. Las previsualizaciones de pull requests, las Actions de terceros, los bots, los webhooks, los registros de paquetes y las integraciones con «Sign in with GitHub» pueden necesitar credenciales nuevas, flujos nuevos o servicios sustitutos. Las estrellas y los seguidores no se convierten en registros nativos en la nueva forja, así que los proyectos públicos también renuncian a parte de su señal de descubrimiento actual.
Haz una prueba en seco antes de cambiar el remoto canónico: migra un repositorio representativo, rehaz sus integraciones, comprueba el historial de incidencias y pull requests, y documenta la vía de reversión. La comparación de plataformas viene después de esa auditoría de dependencias.
Para equipos que quieren una gobernanza sin ánimo de lucro sin operar un servidor, Codeberg merece consideración.
Consejo sobre soberanía. Si eliges autoalojar por motivos de residencia de datos en la UE, la ubicación del centro de datos importa. Sitios como Fráncfort o Ámsterdam son la elección aburrida pero correcta. El VPS más barato en Virginia no ayuda a tu DPA.
El coste operativo del alojamiento Git público
El autoalojamiento público expone una forja al mismo tráfico automatizado que recibe cualquier aplicación accesible desde internet, salvo que las páginas de repositorio incluyen rutas caras como las vistas de blame, los archivos comprimidos y el historial de commits. Los informes que siguen son experiencias individuales de operadores, no mediciones de referencia.
En la discusión sobre Git autoalojado mencionada antes, un operador informó de 37.212.377 solicitudes contra una instancia de cgit en 60 días, con más del 99 % clasificadas como bots.
En la misma discusión, kstrauser contó que bajó una instancia de Forgejo de unas 600.000 solicitudes al día a alrededor de 1.000, pero solo tras añadir un desafío de JavaScript y cookie encima de las mitigaciones habituales.
Otros operadores mencionaron fail2ban, bloqueos por GeoIP, agujeros negros a nivel de sistema autónomo y devolver los repositorios a plataformas alojadas. Estos relatos muestran posibles modos de fallo; no son referencias universales de tráfico.
La razón mecánica de que esto sea difícil: un simple límite de velocidad por IP puede fallar frente al tráfico que rota por proxies residenciales. Una flota de rastreadores puede repartir las solicitudes entre suficientes IP como para que ninguna dirección parezca abusiva, mientras el servidor se satura igualmente en conjunto.
Los desafíos de JavaScript o cookie pueden reducir el scraping poco sofisticado, pero también pueden bloquear a usuarios sin JavaScript e interferir con Git sobre HTTPS si se aplican a todas las rutas. La caché de CDN ayuda con las lecturas repetidas; hace mucho menos por endpoints únicos o caros como archivos comprimidos, vistas de blame y páginas por commit.
Lo que un desafío cambia es la economía del problema. Anubis se coloca delante de una forja y obliga al cliente a superar un desafío, por ejemplo un pequeño cálculo de prueba de trabajo, antes de que el servidor devuelva la página protegida, lo que encarece el rastreo a gran escala. Es una mitigación, no una garantía.
Aplica los desafíos de navegador de forma selectiva. Mantén SSH disponible para las operaciones Git y prueba Git sobre HTTPS antes de proteger esa ruta: una página de desafío devuelta a un cliente Git se convierte en un clon fallido, no en una verificación útil.
GitHub absorbe esta clase de tráfico como parte de su servicio alojado. Una instancia pública de Forgejo o cgit te deja a ti la planificación de capacidad, los controles antiabuso, la caché y la mitigación. Esa transferencia operativa, y no el coste bruto del software, es la parte importante de la decisión de migrar.
Por eso el modelo híbrido es una opción de primera clase y no un recurso de emergencia. Código privado detrás de una VPN: los rastreadores no llegan. OSS público en GitHub: la infraestructura antiabuso de GitHub se ocupa del tráfico de bots.
Si aun así quieres una forja pública autoalojada, presupuesta registros, controles de tasa, caché, mitigación de bots, monitorización y una vía probada para el tráfico Git que no dependa de desafíos de navegador. Trata la defensa frente a rastreadores como parte de la operación normal, no como un caso extremo.
La cuestión del efecto de red para los mantenedores de OSS
Aquí me dirijo a un lector muy concreto: mantienes un proyecto de código abierto. Veinte colaboradores, doscientas estrellas y un gestor de incidencias activo. Estás pensando en sacarlo de GitHub.
Sé honesto sobre lo que estás cambiando: la visibilidad ante colaboradores, la marca implícita de confianza de github.com, Dependabot, CodeQL y el ecosistema de terceros que se apoya en la autenticación de GitHub. Nada de eso es imposible fuera; todo se vuelve fricción.
La regla general que yo ofrecería: si el valor de tu proyecto está sobre todo en el código, autoalojarlo es más fácil de justificar.
El código viaja. Si su valor depende en buena medida de los colaboradores, las incidencias, la visibilidad en buscadores y la confianza asociada a github.com, irse cambia parte de lo que hace funcionar el proyecto por lo que hace sentir mejor al mantenedor. Cambio legítimo si tus motivos son lo bastante grandes. Mal cambio si lo haces para demostrar algo.
La presentación de la plataforma Codeberg describe un servicio basado en Forgejo operado por la asociación sin ánimo de lucro Codeberg e.V. Para los mantenedores de OSS, eso significa gobernanza comunitaria sin la carga de mantenimiento de operar la forja tú mismo.
Para equipos afines al OSS que quieren gobernanza comunitaria sin la obligación de actualizar, supone un salto operativo menor que operar una forja pública. SourceHut implica un cambio de flujo de trabajo mucho más deliberado y necesita una evaluación aparte.
Haz el cambio más pequeño que resuelva el problema
Antes de cambiar de remoto, escribe el requisito en una frase: detener el entrenamiento con los datos de interacción de Copilot, separar el alojamiento público del privado, o sacar GitHub de la arquitectura. Si no sabes nombrar el requisito, no migres todavía.
Para una migración, empieza con un repositorio representativo como piloto. Inventaría la autenticación, las Actions, los webhooks, la publicación de paquetes, los entornos de vista previa, el histórico de incidencias, los datos LFS y los pasos de reversión antes de cambiar el remoto canónico.
El despliegue de Forgejo en un clic es una forma rápida de montar el lado privado de un modelo híbrido; una instalación manual en cualquier Linux VPS también funciona. Sea cual sea la vía que elijas, mantén la interfaz web privada, respalda el estado completo de la aplicación y prueba la restauración antes de mover un repositorio crítico.
Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.
Ver planes LinuxEl control solo es útil cuando resuelve el requisito a un coste operativo que tu equipo pueda sostener.
Preguntas frecuentes
¿Debería migrar fuera de GitHub por el cambio de entrenamiento de Copilot?
No automáticamente. Si tu única preocupación es que los datos de interacción con Copilot se usen para entrenar modelos, desactivar el ajuste a nivel de cuenta es el arreglo correcto más pequeño. Migrar tiene sentido cuando además necesitas controles más estrictos de residencia de datos, gobernanza, independencia del proveedor o política de solo software libre.
¿GitHub entrena con todos mis repositorios privados?
No. El cambio de política del que hablamos aquí cubre los datos de interacción con Copilot que reúnen los requisitos, incluidas entradas, salidas, fragmentos de código y el contexto asociado enviados a través de Copilot. No significa que todo repositorio privado guardado en GitHub se use automáticamente para entrenar modelos.
¿Autoalojar Git es siempre más privado?
Solo si la operas así. Una forja privada detrás de una VPN o lista de IP permitidas puede reducir la exposición, pero una instancia accesible públicamente añade responsabilidades de parcheo, monitorización, mitigación de bots, control de acceso y copias de seguridad que GitHub normalmente absorbe.
¿Qué plataforma Git autoalojada debería elegir?
Elige Forgejo o Gitea si quieres una forja privada más ligera. Elige GitLab CE cuando la CI/CD integrada y un registro de paquetes o contenedores importen lo bastante como para justificar sus mayores requisitos de recursos y mantenimiento.
¿Qué tamaño de VPS necesitan Forgejo o Gitea para un equipo pequeño?
Para un equipo privado de dos a diez personas, 2 vCPU y 4 GB de RAM son un punto de partida más seguro. Añade capacidad cuando la indexación de búsqueda, los paquetes, los repositorios grandes o los runners de CI compartan el host. Dimensiona GitLab CE aparte, porque necesita más recursos.
¿Qué debería probar antes de cambiar el remoto canónico?
Haz un piloto con un repositorio representativo. Comprueba el histórico de incidencias y pull requests, la autenticación, las Actions o los flujos de CI sustitutos, los webhooks, la publicación de paquetes, los datos LFS, los entornos de vista previa, las copias de seguridad, la restauración y la vía de reversión antes de moverlo todo.
