Cloudflare Void (open-source): контроль вайб-застосунків в IT — інвентар, не runtime Bubble і не другий редактор

Bubble плюс вайбкодінг здається найкоротшим шляхом, коли нетехнічний фаундер перевіряє нову ідею. Інтерфейс збирається за кілька днів. Допоміжний скрипт генерує AI-асистент. Перший робочий прототип уже можна показувати клієнтам чи інвесторам. Проблеми починаються, щойно в проєкті з'являється згенерований код: де він лежить, які ключі доступу отримує і хто відповідає за його безпеку. Про це окремо: Governance week: Cursor canvases vs.

15 жовтня 2026 року Cloudflare відкрила вихідний код проєкту Void під ліцензією MIT у репозиторії voidzero-dev/void. Новинні стрічки одразу назвали його спробою IT-відділів узяти під контроль стихійний вайбкодінг співробітників. Через назву й маркетинг вийшла плутанина. Одні вирішили, що це новий AI-редактор, інші побачили в ньому альтернативу no-code платформам. Я розібрав технічні межі релізу, щоб зрозуміти, що з нього корисно для запуску MVP, а що тільки додає складності. Схожий розбір: MCP без credits, але без.

Чим є і чим не є Void

Я фіксую три відмінності. Вони економлять час на інструментах, які не вирішують вашу поточну задачу.

Перша. Void від Cloudflare не є редактором коду. Колись існував проєкт із такою самою назвою, відкритий форк VS Code, зараз заархівований. Продукт Cloudflare до нього стосунку не має. У Void ви не пишете запити до нейромереж і не редагуєте файли.

Друга. Void не є low-code чи no-code середовищем виконання, як Bubble. У Bubble база даних, логіка робочих процесів, інтерфейс і правила доступу працюють як один керований сервіс, і сервери налаштовувати не треба. Void побудований на екосистемі Vite та Cloudflare Workers і складається з трьох частин: Схожий розбір: Reverse.dev for teams: чи допоможе.

• Void SDK — плагін Vite для розробки повноцінних вебзастосунків.
• Void CLI — інструмент для збірки, виділення ресурсів, розгортання та відкату версій.
• Void Platform — середовище спільного розгортання всередині акаунта компанії на базі Workers for Platforms.

Це стек доставки й обліку коду. Візуального конструктора тут немає.

Третя. Головне призначення Void Platform — централізований шлюз для IT. Автор коду чи AI-агент не отримує прямих адміністративних ключів від хмари Cloudflare. Розробник підключається до корпоративної платформи командою void connect, а потім деплоїть через void deploy. Адміністратори бачать у консолі проєкти, користувачів, логи виконання, ліміти ресурсів і прив'язку до корпоративної авторизації: Cloudflare Access, GitHub, Google чи OIDC.

Реалії self-hosted платформи на етапі MVP

Якщо вам треба швидко запустити MVP і перевірити попит, самостійно розгортати Void Platform немає сенсу. Щоб підняти власну платформу через void platform install, потрібні:

• платний тариф Workers for Platforms (від 25 доларів на місяць плюс фактичне використання);
• сховище R2;
• зовнішня база даних PostgreSQL;
• власний домен;
• налаштований провайдер ідентифікації.

Для нетехнічного підприємця це окремий шар системного адміністрування, і з'являється він раніше, ніж перші відгуки користувачів.

Перші аналітичні огляди, зокрема публікація The New Stack від 16 жовтня 2026 року, показують суттєві обмеження контролю в поточному релізі:

• У стандартному процесі немає обов'язкового аудиту безпеки перед публікацією застосунку.
• Авторизація через корпоративний акаунт звужує коло користувачів, але не зупиняє витік чутливих даних, якщо згенерований код сам робить небезпечні зовнішні API-запити.
• Залежно від конфігурації платформи нові проєкти можуть створюватися публічними за замовчуванням.
• Розробник однаково може задеплоїти напряму у свій персональний акаунт Cloudflare в обхід корпоративної платформи, якщо внутрішні правила компанії цього жорстко не забороняють.

Що взяти в роботу: звичка інвентаря без зайвої інфраструктури

На етапі прототипу корпоративні надбудови фаундеру не потрібні. Але дисципліна, яку Void намагається автоматизувати, корисна для будь-якої роботи з вайбкодінгом і no-code.

Найбільший ризик швидкої розробки з AI — втратити контроль над тим, куди йдуть доступи. Коли агент пише допоміжний скрипт чи мікросервіс, я не даю йому повних адміністративних ключів від основного проєкту, платіжної системи чи робочої бази даних. Тільки мінімальні права з обмеженням за ресурсами.

Я тримаю простий перелік активів: які домени зареєстровані, які сервіси задіяні, які сторонні API підключені до Bubble-застосунку. Контроль доступу не замінює правил безпеки всередині самої програми. У Bubble базовий захист будується на вбудованих Privacy Rules у базі даних, а не на сподіванні, що застосунок ніхто не знайде.

Поки ви перевіряєте гіпотезу й шукаєте перші інвестиції, головне — цінність для клієнта. Для цього Bubble дає достатньо контролю та швидкості, і власна платформа деплою вам не потрібна.