InsForge: open-source бэкенд, который пишет сам себя через ИИ-агентов

InsForge: open-source бэкенд, который пишет сам себя через ИИ-агентов

За последние два года ИИ научился писать фронтенд быстрее человека. Но как только речь заходит о бэкенде — базах данных, авторизации, хранилищах файлов — агенты начинают тупить. Не потому что глупые, а потому что каждый проект требует уникальной комбинации сервисов, а настройка этой комбинации отнимает больше времени, чем написание самого кода. InsForge, набравший за десять месяцев более десяти тысяч звёзд на GitHub, решает эту проблему радикально: он предоставляет готовый open-source бэкенд, которым ИИ-агент может управлять так же естественно, как человек управляет курсором.

Что такое InsForge и зачем он агентам

InsForge — это open-source Backend-as-a-Service (BaaS), распространяемый под лицензией Apache 2.0. По сути, это самоуправляемая платформа, которая даёт любому приложению полноценный бэкенд из коробки: PostgreSQL 15 с автоматическими REST API через PostgREST 12.2, JWT-аутентификацию с OAuth-провайдерами (Google, GitHub), S3-совместимое хранилище файлов, serverless edge-функции на Deno, AI-шлюз через OpenRouter с совместимым с OpenAI API, а также realtime pub/sub через WebSockets. Всё это разворачивается локально через Docker Compose за одну команду или в облаке на insforge.dev за три секунды.

Ключевое отличие от классических BaaS вроде Firebase или Supabase — архитектура, заточенная под агентное взаимодействие. InsForge не просто предоставляет API для человека. Он предоставляет MCP-сервер (Model Context Protocol), который превращает все операции с бэкендом в инструменты, доступные любому MCP-совместимому агенту: Claude Code, Cursor, GitHub Copilot, Codex, opencode или Pi. Агент может читать документацию, развёртывать функции, создавать таблицы в базе данных, настраивать аутентификацию и загружать файлы — всё текстовыми командами, без единого клика по интерфейсу.

Как агенты взаимодействуют с InsForge

Существует два канала связи между ИИ-агентом и платформой. Первый — MCP-сервер, доступный как в облачной, так и в self-hosted версии. MCP-совместимый агент получает набор инструментов: fetch-docs для чтения документации, get-backend-metadata для получения конфигурации проекта, run-raw-sql и get-table-schema для работы с базой данных, create-bucket и list-buckets для хранилища, create-function и update-function для развёртывания serverless-кода, download-template для создания стартовых шаблонов приложений. Каждый инструмент — это атомарная операция, которую агент вызывает так же, как раньше вызывал чтение файла или запуск терминальной команды.

Второй канал — CLI и Skills, пока доступные только в облаке. Агент вызывает команды напрямую из терминала через npx @insforge/cli, связывая локальный проект с облачным бэкендом по project ID. Этот путь ближе к традиционной разработке: агент пишет код, а затем деплоит его через знакомый интерфейс командной строки. Обе модели позволяют агенту работать с бэкендом как с первоклассным гражданином — не через посреднические API-вызовы, а через семантически понятные инструменты с предсказуемыми результатами.

Почему агентам не хватает обычных BaaS

Традиционные Backend-as-a-Service платформы создавались для людей. У них красивые дашборды, визуальные редакторы схем, кнопки для создания таблиц. Но агент не видит интерфейс — он видит текст. И когда агенту нужно создать таблицу в Firebase, он вынужден либо эмулировать клики через браузер (хрупко и медленно), либо изучать REST API, который никогда не проектировался для машинного потребления. В результате агент тратит десятки итераций на то, что человек делает за минуту.

InsForge меняет подход: вся платформа спроектирована так, чтобы агент мог получить полный контекст за один вызов. Документация доступна через fetch-docs — агент читает актуальные инструкции перед тем, как писать код. Метаданные проекта возвращаются структурированным JSON, а не HTML-страницей, которую нужно парсить. Операции с базой данных идут через PostgREST, который автоматически генерирует REST endpoints из схемы PostgreSQL: создали таблицу — и сразу получили GET, POST, PATCH, DELETE без единой строчки бэкенд-кода. Агенту не нужно писать контроллеры, маршрутизаторы или сериализаторы — он просто вызывает endpoint, который PostgREST создал автоматически.

Что внутри: архитектура и технологии

На уровне инфраструктуры InsForge строится вокруг PostgreSQL 15.13 с Row Level Security для изоляции данных между пользователями. PostgREST 12.2.12 обеспечивает автоматическую генерацию REST API из публичной схемы базы данных: каждая таблица мгновенно становится набором HTTP endpoints с поддержкой фильтрации, пагинации, агрегации и вложенных ресурсов. Аутентификация работает через JWT-токены с тремя уровнями доступа: anon (только чтение), authenticated (CRUD) и project_admin (полный контроль). OAuth-интеграции с Google и GitHub настраиваются через переменные окружения, без необходимости писать собственные обработчики callback.

Edge-функции реализованы на двух рантаймах в зависимости от способа развёртывания. В облаке код деплоится на Deno Subhosting — глобально распределённую edge-платформу с нулевым управлением инфраструктурой. В self-hosted режиме функции выполняются в локальном Deno-рантайме в изолированных Web Workers. Оба варианта дают агенту возможность развёртывать serverless-код, который имеет полный доступ к InsForge SDK и может обращаться к базе данных, хранилищу и другим сервисам платформы. AI-интеграция идёт через OpenRouter: платформа предоставляет provisioned API-ключ, который агент использует с OpenAI SDK, обращаясь к любой модели из каталога OpenRouter по стандартному baseURL.

Realtime-слой работает через WebSockets и поддерживает как pub/sub событий, так и подписку на изменения в базе данных. Это позволяет агенту строить коллаборативные приложения — чаты, совместные редакторы, live-дашборды — без необходимости настраивать отдельный websocket-сервер. Весь стек упакован в Docker Compose с продакшен-конфигурацией, что означает: одна команда docker compose up, и локальный InsForge готов к работе на порту 7130.

Self-hosted vs Cloud: когда что выбирать

Облачная версия insforge.dev ориентирована на скорость: создание проекта занимает около трёх секунд, после чего агент получает готовый backend URL и anon key для подключения. Платформа берёт на себя масштабирование, бэкапы, SSL-сертификаты и мониторинг. Это идеальный вариант для прототипирования, MVP и учебных проектов, где важно время от идеи до работающего приложения.

Self-hosted версия даёт полный контроль. Все данные остаются на вашем железе, все сервисы работают в вашей сети, никаких внешних зависимостей кроме Docker. Это критично для корпоративных сред с требованиями compliance, для приложений с чувствительными данными, для регионов с ограниченным доступом к облачным сервисам. Кроме того, self-hosted версия бесплатна — вы платите только за свою инфраструктуру. Интересная деталь: на одном хосте можно запустить несколько изолированных проектов InsForge, просто назначив каждому уникальные порты через отдельные .env-файлы. Это удобно для разработки, когда агенту нужно тестировать изменения в изолированной среде, не рискуя боевыми данными.

Как выглядит рабочий процесс с агентом

Представьте, что вы просите Claude Code создать приложение для отслеживания привычек. В традиционном сценарии агент написал бы фронтенд, а потом застрял бы на вопросе: где хранить данные, как авторизовывать пользователей, как деплоить. С InsForge процесс выглядит иначе. Агент вызывает fetch-docs, получает инструкции по настройке проекта, затем через MCP создаёт таблицу habits с полями user_id, title, frequency, streak и created_at. PostgREST мгновенно генерирует REST API для этой таблицы. Агент скачивает шаблон проекта через download-template, встраивает SDK-вызовы для аутентификации и CRUD-операций, добавляет edge-функцию для ежедневных напоминаний и деплоит фронтенд через встроенный механизм развёртывания. Всё это — без вашего участия, за один длинный сеанс агентной работы.

Или другой сценарий: агент строит SaaS с AI-генерацией контента. Он настраивает аутентификацию через Google OAuth, создаёт таблицу для подписок с полем plan и лимитами на генерации, подключает AI-шлюз через OpenRouter с лимитом расхода токенов, настраивает хранилище для сгенерированных файлов и деплоит edge-функцию, которая считает использование и блокирует превышение лимитов. Каждый компонент — это один или два MCP-вызова, а не часы настройки инфраструктуры.

Экосистема и зрелость проекта

За десять месяцев с момента создания репозитория InsForge набрал 10 341 звезду, 868 форков и активное сообщество в Discord. Проект входит в программу Vercel Open Source, имеет официальные шаблоны развёртывания на Railway, Zeabur и Sealos, а также VS Code-расширение для однокликовой установки MCP-сервера. Последний релиз v2.1.6 вышел четыре дня назад, а changelog насчитывает более полутора десятков версий с фичами вроде S3-совместимого хранилища (Wasabi, MinIO), pre-validation edge-функций через deno check и soft-disable для AI-моделей.

Технологический стек проекта — TypeScript, PostgreSQL, Deno, Docker — выбран с учётом агентной разработки. TypeScript даёт типобезопасность, которую агент может использовать для генерации корректного кода. PostgreSQL — надёжная реляционная база с богатыми возможностями, от pgvector для векторного поиска до Row Level Security для изоляции данных. Deno — современный JavaScript-рантайм со встроенной типобезопасностью и sandboxing, идеальный для serverless-функций, которые агент генерирует на лету. Docker Compose обеспечивает воспроизводимость: один и тот же набор контейнеров работает одинаково на ноутбуке разработчика и на продакшен-сервере.

Часто задаваемые вопросы

В чём разница между InsForge и Supabase?

Оба проекта предоставляют PostgreSQL, аутентификацию и хранилище из коробки. Но Supabase создавался для человеческих разработчиков с визуальным интерфейсом, тогда как InsForge архитектурно заточен под агентное взаимодействие через MCP. Кроме того, InsForge включает AI-шлюз через OpenRouter и edge-функции на Deno, тогда как Supabase использует Edge Functions на Deno Deploy и требует отдельной настройки AI-интеграций.

Можно ли использовать InsForge без ИИ-агентов?

Да, платформа полностью функциональна и для традиционной разработки. SDK доступен для TypeScript, Swift, Kotlin и через прямой REST API. Но уникальное преимущество InsForge раскрывается именно в связке с агентами — благодаря MCP-серверу и семантически понятным инструментам.

Насколько безопасно давать агенту доступ к бэкенду?

MCP-сервер InsForge работает через явно определённые инструменты с предсказуемыми входными и выходными параметрами. Агент не получает прямого доступа к базе данных или shell — он вызывает абстракции вроде run-raw-sql или create-function, которые платформа выполняет в изолированной среде. Row Level Security на уровне PostgreSQL гарантирует, что даже если агент сформирует неожиданный запрос, он увидит только те строки, которые разрешены текущему пользователю.

Итог

InsForge — это не просто очередной open-source BaaS. Это попытка решить фундаментальную проблему агентного кодинга: ИИ отлично пишет логику, но плохо справляется с инфраструктурой. Предоставив агентам семантически понятный, предсказуемый и полнофункциональный бэкенд через единый протокол MCP, InsForge сдвигает границу того, что агент может построить без человеческого участия. От фронтенда — до полноценного full-stack приложения с базой данных, авторизацией, хранилищем и AI-интеграцией. Если вы экспериментируете с Claude Code, Cursor или Codex — стоит потратить пятнадцать минут на развёртывание InsForge и посмотреть, как агент справляется с бэкендом, когда ему дают правильные инструменты.

← Все записи
← Все записи