24 квітня 2026 року політика GitHub щодо навчання моделей змінилася для індивідуальних планів Copilot. Тепер GitHub може використовувати взаємодії з Copilot Free, Pro, Pro+ і Max, зокрема введені й отримані дані, фрагменти коду та пов'язаний контекст, для навчання та вдосконалення моделей ШІ, якщо користувач не відмовиться. Дані Copilot Business та Enterprise залишаються захищеними угодою GitHub про захист даних. Важливо: ідеться про дані взаємодії з Copilot, а не про приватні репозиторії, які просто лежать без діла на GitHub.
Водночас аргументи на користь міграції зринули з іншої причини: публічні самостійно розміщені Git-інстанси приймали важкий автоматичний трафік. Обговорення на Hacker News зібрало корисний набір звітів операторів про цю проблему: Кінець епохи для мене: більше жодного самостійно розміщеного git.
Залишається питання корисніше, ніж «GitHub чи самостійний хостинг?»: яку саме проблему ви намагаєтеся розв'язати?
Коротко
Три відповіді. Оберіть ту, що відповідає вашій ситуації.
- A: Відмовитися і залишитися. Підходить, коли зміна щодо навчання Copilot — ваш єдиний клопіт, а GitHub досі відповідає операційним потребам команди. Вимкніть налаштування на рівні облікового запису й працюйте далі.
- B: Зробити гібрид. Публічний відкритий код лишіть на GitHub заради мережевого ефекту. Приватний код перенесіть на самостійно розміщений Forgejo, Gitea чи GitLab CE за VPN або списком дозволених IP. Підходить, коли публічне охоплення й приватний контроль важать одночасно.
- C: Мігрувати повністю. Заберіть із GitHub усе. Підходить, коли регулювання, резидентність даних, урядування чи політика «лише вільне ПЗ» виключають GitHub, а команда здатна нести операційні витрати.
Більшість читачів перебувають у позиції A або B. Позицію C виправдовують суворіші вимоги до врядування, суверенітету чи цінностей, а не саме лише налаштування Copilot.
Що насправді змінилося у квітні 2026 року
Технічна зміна невелика. У налаштуваннях Copilot індивідуальні передплатники можуть перевести «Allow GitHub to use my data for AI model training» у стан Disabled. GitHub описує охоплений матеріал як взаємодії з його функціями та сервісами, зокрема введені й отримані дані, фрагменти коду та пов'язаний контекст, а не вміст приватних репозиторіїв, який ніколи не проходив через Copilot.
У Copilot Business та Enterprise цього перемикача немає, бо їхні дані захищені угодою GitHub про захист даних. Для індивідуальних планів вимкнення налаштування закриває питання політики навчання, але не знімає ширшого заперечення проти залежності від політики, яку контролює постачальник.
Зміна Copilot може бути тригером, не будучи всією підставою. Команду можуть непокоїти також залежність від платформи, ідентичність, прив'язана до GitHub, робочі процеси, збудовані навколо Actions, резидентність даних або те, наскільки легко буде переїхати ще раз згодом. Це питання міграції, а перемикач навчання — лише одне налаштування.
Ця різниця важлива: відмова змінює одне налаштування використання даних, а міграція змінює те, хто контролює хостинг, ідентичність, інтеграції та політику. Друге рішення коштує в експлуатації значно дорожче.
Три позиції докладно
Рішення, стиснуте до трьох рядків. Подробиці нижче.
| Ваша турбота | Відповідь | Що робити |
|---|---|---|
| Мої дані взаємодії з Copilot використовують для навчання | Відмовитися і залишитися (позиція A) | Перемкніть налаштування й повертайтеся до роботи |
| Приватний код, який я не хочу тримати в американського постачальника, + активний відкритий код, який я не хочу ховати | Гібрид (позиція B) | Приватні репозиторії розміщуйте самостійно за VPN; публічний відкритий код лишіть на GitHub |
| Суверенітет, регульована галузь, принципова позиція «лише вільне ПЗ», повна незалежність від постачальника | Повна міграція (позиція C) | Перенесіть усе й закладіть операційні витрати в бюджет |
Позиція A: відмовитися і залишитися
Якщо ви розробник-одинак або невелика команда з приватними репозиторіями і ваша єдина претензія — типове налаштування навчання, це ваша відповідь. Перемкнути налаштування: одна хвилина, один раз. Самостійний хостинг: невеликий рахунок за VPS, стратегія резервних копій, яку ви справді перевіряєте, інтеграції, які доведеться перебудувати, бо вони покладалися на автентифікацію GitHub, і чергове оновлення чи відновлення, що припадає на найгіршу можливу мить.
Самостійний хостинг усе ще може бути вартим зусиль, але лише якщо ця регулярна робота купує вам щось справді потрібне.
Найсильніше заперечення: цей перемикач — теж рішення постачальника. У 2026 році GitHub перейшов від того, щоб типово не використовувати ці дані взаємодії для навчання, до того, щоб типово їх використовувати, і може змінити політику знову.
Якщо ваша глибша тривога звучить як «я ніколи не хочу, щоб американський постачальник ухвалював односторонні рішення щодо мого коду», жодна галочка цього не розв'яже, і позиція A — хибна для вас відповідь. Переходьте до позиції C.
Але якщо ваша тривога полягає саме в тому, що «я не хочу, щоб мої теперішні дані взаємодії з Copilot потрапляли в навчання», і ви довірятимете налаштуванню GitHub до наступної зміни, позиція A — найдешевша правильна відповідь. У дешевому й правильному немає нічого ганебного.
Позиція B: гібридна модель
Гібридний хостинг відокремлює публічне охоплення від приватного контролю.
Поділ простий. Публічний відкритий код лишається на GitHub: мережевий ефект, приплив контриб'юторів, Dependabot, екосистема Actions — це справжня цінність. Приватний код переїжджає на самостійно розміщений інстанс за VPN або списком дозволених IP, недосяжний із публічного інтернету.
Те, що це працює, — властивість моделі загроз. Занепокоєння щодо навчання Copilot стосується лише даних взаємодії, які ви надсилаєте через GitHub. Проблема трафіку ШІ-скраперів (наступний розділ) стосується лише публічно доступних інстансів. Приватна гібридна схема обходить обидві.
Для приватної команди з 2–10 осіб 2 vCPU і 4 GB RAM — безпечніша відправна точка для Forgejo чи Gitea, із запасом, якщо індексація пошуку, пакети або CI ділять той самий хост. Вважайте це розрахунком під Forgejo/Gitea, а не під GitLab CE: посібник GitLab зі встановлення на одному вузлі починається з 8 vCPU і 7,2 GB пам'яті, ще до навантаження від CI.
Не виставляйте вебінтерфейс відкрито на 80 чи 443. Обмежте його на рівні брандмауера, проксі, VPN або mesh-мережі. Раннери CI можуть обслуговувати обидві сторони.
Вибір платформи змінює набір можливостей більше, ніж сама гібридна модель. Forgejo і Gitea пасують легшій приватній форджі, а GitLab CE має більше сенсу, коли вам потрібен ще й вбудований стек CI/CD та реєстру.
Резервні копії цілком під силу, але не зводьте їх до git bundle. Офіційний посібник Forgejo з оновлення вважає надійною резервною копією синхронізований знімок на момент часу всього сховища, яке використовує Forgejo, а там, де це непрактично, — Forgejo dump у парі з окремим дампом PostgreSQL чи MySQL. І для Forgejo, і для Gitea тримайте разом репозиторії, базу даних, конфігурацію, вкладення та дані LFS, зберігайте копію поза сервером і перевіряйте відновлення.
Локальний клон розробника може відновити код, але не задачі, користувачів, метадані пул-реквестів, вкладення чи всі об'єкти LFS. Якщо приватний форк згодом стане публічним, ось тоді й залийте його в дзеркало на GitHub.
Позиція C: повна міграція, коли контроль — це вимога
Повна міграція пасує найясніше тоді, коли незалежність від постачальника — вимога, а не вподобання.
Вирізняються три групи: регульовані команди з правилами аудиту, резидентності чи контролю постачальника, які виключають GitHub; команди держсектору або ЄС, чиї вимоги суверенітету — це припис, а не вподобання; і організації «лише вільне ПЗ», що хочуть піти з інфраструктури, яка належить Microsoft, і вже мають персонал, здатний обслуговувати сервіси на Linux.
Ціна — невеликий VPS, постійне обслуговування і втрата інтеграцій. Саме про втрату інтеграцій забувають. Усе, що автентифікується через «Sign in with GitHub», лишається на GitHub або потребує окремого постачальника ідентичності.
Плануйте міграцію навколо залежностей, а не лише репозиторіїв. Прев'ю пул-реквестів, сторонні Actions, боти, вебхуки, реєстри пакетів та інтеграції «Sign in with GitHub» можуть потребувати нових облікових даних, нових процесів або замінних сервісів. Зірки й спостерігачі не стають рідними записами на новій форджі, тож публічні проєкти віддають і частину свого наявного сигналу відкриття.
Зробіть пробний прогін, перш ніж міняти канонічний remote: перенесіть один показовий репозиторій, перезберіть його інтеграції, перевірте історію задач і пул-реквестів та задокументуйте шлях відкату. Порівняння платформ іде вже після цього аудиту залежностей.
Командам, які прагнуть неприбуткового врядування без утримання власного сервера, варто придивитися до Codeberg.
Порада щодо суверенітету. Якщо ви обираєте самостійний хостинг заради резидентності даних у ЄС, розташування дата-центру має значення. Майданчики на кшталт Франкфурта чи Амстердама — нудний, але правильний вибір. Найдешевший VPS у Вірджинії вашому DPA не допоможе.
Операційна ціна публічного хостингу Git
Публічний самостійний хостинг підставляє форджу під той самий автоматичний трафік, що б'є по будь-якому доступному з інтернету застосунку, тільки сторінки репозиторію містять дорогі шляхи на кшталт blame-подань, архівів та історії комітів. Наведені нижче звіти — індивідуальний досвід операторів, а не еталонні заміри.
У згаданому вище обговоренні про самостійно розміщений Git один оператор повідомив про 37 212 377 запитів до інстансу cgit за 60 днів, з яких понад 99 % класифікували як ботів.
У тому ж обговоренні kstrauser розповів, що знизив навантаження на інстанс Forgejo приблизно з 600 000 запитів на день до близько 1 000, але лише після того, як поверх звичайних заходів додав перевірку з JavaScript і cookie.
Інші оператори згадували fail2ban, блокування за GeoIP, чорні діри на рівні автономних систем і повернення репозиторіїв на хостингові платформи. Ці звіти показують можливі сценарії відмови, а не універсальні орієнтири щодо трафіку.
Технічна причина, чому це складно: просте обмеження швидкості за IP може не спрацювати проти трафіку, що ротується через резидентні проксі. Флот скраперів здатен розмазати запити по такій кількості IP, що жодна адреса не виглядає зловживанням, а сервер усе одно захлинається в сумі.
Перевірки на JavaScript чи cookie можуть зменшити невибагливий скрапінг, але вони ж здатні заблокувати користувачів без JavaScript і зашкодити Git поверх HTTPS, якщо застосувати їх до кожного шляху. Кешування на CDN допомагає при повторних читаннях, а от на унікальних чи дорогих ендпоїнтах на кшталт архівів, blame-подань і сторінок окремих комітів допомагає значно менше.
Що змінює така перевірка, так це економіку питання. Anubis стає перед форджею і змушує клієнта пройти перевірку, наприклад невелике обчислення proof-of-work, перш ніж сервер віддасть захищену сторінку, що робить масове сканування дорожчим. Це пом'якшення, а не гарантія.
Застосовуйте браузерні перевірки вибірково. Лишіть SSH доступним для операцій Git і протестуйте Git поверх HTTPS, перш ніж захищати цей шлях: сторінка перевірки, віддана Git-клієнту, перетворюється на невдалий клон, а не на корисну верифікацію.
GitHub убирає цей клас трафіку на себе як частину свого хостингового сервісу. Публічний інстанс Forgejo чи cgit лишає планування потужностей, контроль зловживань, кешування та пом'якшення вам. Саме це перенесення експлуатаційного тягаря, а не гола вартість софту, і є важливою частиною рішення про міграцію.
Саме тому гібридна модель — повноцінний варіант, а не запасний. Приватний код за VPN: скрапери до нього не дотягнуться. Публічний відкритий код на GitHub: із трафіком ботів розбирається антизловживальна інфраструктура GitHub.
Якщо ви все ж хочете публічну самостійно розміщену форджу, закладіть у бюджет логи, контроль швидкості, кешування, захист від ботів, моніторинг і перевірений шлях для Git-трафіку, який не залежить від браузерних перевірок. Вважайте захист від скраперів частиною звичайної експлуатації, а не крайнім випадком.
Питання мережевого ефекту для мейнтейнерів відкритого коду
Тут я звертаюся до цілком конкретного читача: ви ведете проєкт з відкритим кодом. Двадцять контриб'юторів, двісті зірок і живий трекер задач. І ви подумуєте забрати його з GitHub.
Будьте чесні щодо того, чим ви міняєтеся: відкриваність для контриб'юторів, неявний знак довіри github.com, Dependabot, CodeQL і стороння екосистема, зав'язана на автентифікацію GitHub. Ніщо з цього не є неможливим деінде, але все перетворюється на тертя.
Практичне правило, яке я б запропонував: якщо цінність вашого проєкту здебільшого в коді, самостійний хостинг виправдати легше.
Код переїжджає легко. Але якщо його цінність значною мірою залежить від контриб'юторів, задач, видимості в пошуку та довіри навколо github.com, то відхід міняє частину того, що змушує проєкт працювати, на те, від чого мейнтейнеру легше на душі. Законний обмін, якщо ваші причини достатньо вагомі. Поганий обмін, якщо ви робите це, щоб щось довести.
Огляд платформи Codeberg описує сервіс на базі Forgejo, який веде неприбуткова організація Codeberg e.V. Для мейнтейнерів відкритого коду це означає громадське врядування без тягаря обслуговування власної форджі.
Командам, близьким до відкритого коду, які хочуть громадського врядування без обов'язку оновлюватися, це дає менший операційний стрибок, ніж утримання публічної форджі. SourceHut передбачає значно свідомішу зміну робочого процесу й потребує окремої оцінки.
Зробіть найменшу зміну, яка розв'язує проблему
Перш ніж міняти remote, запишіть вимогу одним реченням: припинити навчання на даних взаємодії з Copilot, розділити публічний і приватний хостинг або прибрати GitHub з архітектури. Якщо ви не можете назвати вимогу, мігрувати ще зарано.
Для міграції спершу візьміть один показовий репозиторій як пілот. Складіть опис автентифікації, Actions, вебхуків, публікації пакетів, прев'ю-середовищ, історії задач, даних LFS і кроків відкату, перш ніж міняти канонічний remote.
Cloudzy's розгортання Forgejo одним кліком — швидкий спосіб підняти приватний бік гібридної моделі; ручне встановлення на будь-якому Linux VPS теж працює. Хай який шлях ви оберете, тримайте вебінтерфейс закритим, зберігайте резервну копію повного стану застосунку і перевіряйте відновлення, перш ніж переносити критичний репозиторій.
Розробляйте на Linux VPS з root-доступом, NVMe та потужністю AMD EPYC.
Переглянути тарифи LinuxКонтроль корисний лише тоді, коли він закриває вимогу за операційних витрат, які ваша команда здатна тягнути тривало.
Часті запитання
Чи варто йти з GitHub через зміну щодо навчання Copilot?
Не автоматично. Якщо вас непокоїть лише те, що дані взаємодії з Copilot ідуть на навчання моделей, вимкнення налаштування на рівні облікового запису — найменше правильне виправлення. Міграція має сенс тоді, коли вам потрібні ще й суворіші вимоги до резидентності даних, урядування, незалежності від постачальника чи політики «лише вільне ПЗ».
Чи навчається GitHub на всіх моїх приватних репозиторіях?
Ні. Зміна політики, про яку тут ідеться, охоплює відповідні дані взаємодії з Copilot, зокрема введені й отримані дані, фрагменти коду та пов'язаний контекст, надіслані через Copilot. Це не означає, що кожен приватний репозиторій, який лежить на GitHub, автоматично йде на навчання моделей.
Чи завжди самостійний хостинг Git приватніший?
Лише якщо ви так його експлуатуєте. Приватна форджа за VPN або списком дозволених IP може зменшити відкритість, але публічно доступний інстанс додає обов'язки з латання, моніторингу, захисту від ботів, контролю доступу та резервних копій, які зазвичай бере на себе GitHub.
Яку самостійно розміщувану Git-платформу обрати?
Обирайте Forgejo або Gitea, якщо хочете легшу приватну форджу. Обирайте GitLab CE, коли вбудований CI/CD і реєстр пакетів чи контейнерів важать настільки, щоб виправдати вищі вимоги до ресурсів і обслуговування.
Якого розміру VPS потрібен Forgejo чи Gitea для невеликої команди?
Для приватної команди з двох до десяти осіб 2 vCPU і 4 GB RAM — безпечніша відправна точка. Додавайте потужності, коли той самий хост ділять індексація пошуку, пакети, великі репозиторії або раннери CI. GitLab CE рахуйте окремо, бо йому треба більше.
Що слід перевірити перед зміною канонічного remote?
Проведіть пілот на показовому репозиторії. Перевірте історію задач і пул-реквестів, автентифікацію, Actions чи замінні процеси CI, вебхуки, публікацію пакетів, дані LFS, прев'ю-середовища, резервні копії, відновлення та шлях відкату, перш ніж переносити все.
