n8n и бэкенд-сервисы: Часть 4 — Appwrite

Appwrite — открытая бэкенд-платформа, которую изначально проектировали для установки на собственный сервер. Код распространяется под лицензией BSD-3-Clause. Есть и облачная версия Appwrite Cloud, но основной сценарий — самостоятельная установка в Docker.

Из чего состоит Appwrite

• Databases — хранение структурированных данных. Сейчас сервис называется TablesDB: данные лежат в таблицах и строках (раньше — в коллекциях и документах).
• Auth — регистрация, вход, сессии, команды пользователей.
• Storage — файлы с правами доступа.
• Functions — серверные функции, которые запускаются по событиям, по расписанию или по HTTP-запросу.
• Realtime — подписка клиентов на изменения данных, пользователей и файлов.

Все возможности доступны через единый REST API, а в консоли администратора ими можно управлять вручную.

Какая база внутри

В статьях об Appwrite часто пишут, что он работает на PostgreSQL. Для большинства существующих установок это неверно: до версии 2.0 Appwrite использовал MariaDB. В Appwrite 2.0, вышедшем 7 сентября 2026 года, PostgreSQL стал базой по умолчанию для новых самостоятельных установок. Мастер установки предлагает на выбор PostgreSQL, MariaDB или MongoDB.

Выбор делается один раз: перенести существующую установку с одной базы на другую нельзя. Старые установки после обновления до 2.0 остаются на MariaDB.

Установка на свой сервер

Минимальные требования по документации — 2 ядра процессора, 4 ГБ оперативной памяти, 2 ГБ файла подкачки и Docker Compose версии 2. Установка идёт через мастер настройки в браузере на порту 20080: задаются основные параметры, генерируются ключи безопасности, создаётся учётная запись администратора. Если сервер удалённый, порт 20080 нужно временно открыть в межсетевом экране, а после установки закрыть.

Для рабочей установки дополнительно понадобятся доменное имя и HTTPS, резервное копирование базы и томов с файлами, а также план обновлений: Appwrite обновляется вместе со схемой данных, поэтому перед обновлением обязательна свежая копия.

Для проектов с персональными данными граждан России самостоятельная установка у российского провайдера закрывает требование о первичном сборе данных в базах на территории России. Облачная версия размещена за рубежом.

Как подключить Appwrite к n8n

Встроенного узла Appwrite в n8n нет, все операции выполняются узлом HTTP Request.

1. В консоли Appwrite создайте проект и API-ключ с нужными правами (scopes). Давайте ключу только те права, которые нужны процессу: например, чтение и запись строк, без управления пользователями.
2. В n8n создайте учётные данные типа Header Auth или задайте заголовки в самом узле.
3. Настройте HTTP Request.

Запрос на создание строки в таблице выглядит так:

POST https://appwrite.example.ru/v1/tablesdb/{databaseId}/tables/{tableId}/rows
Content-Type: application/json
X-Appwrite-Project: <ID проекта>
X-Appwrite-Key: <API-ключ>

{
  "rowId": "unique()",
  "data": {
    "name": "Иван Петров",
    "email": "ivan@example.ru"
  }
}

Строка "unique()" вместо идентификатора просит Appwrite сгенерировать его самостоятельно. Если запись соответствует объекту во внешней системе, лучше передать собственный стабильный идентификатор — тогда повторный запрос не создаст дубликат.

Как Appwrite сообщает n8n об изменениях

Веб-хуки настраиваются в консоли проекта: Settings → Webhooks. Указывается адрес узла Webhook в n8n и события, на которые нужно реагировать, — создание пользователя, изменение строки, загрузка файла и другие.

Каждый запрос Appwrite сопровождает заголовками: X-Appwrite-Webhook-Events (какие события сработали), X-Appwrite-Webhook-Project-Id, X-Appwrite-Webhook-User-Id и X-Appwrite-Webhook-Signature. Подпись — это HMAC-SHA1 от строки «адрес веб-хука + тело запроса» с ключом подписи веб-хука, закодированный в Base64. В n8n её проверяют узлом Crypto и сравнивают с заголовком; запросы с неверной подписью отбрасывают.

Если нужна логика, которую удобнее выполнить внутри Appwrite, событие обрабатывает Function, а она уже вызывает n8n.

Примеры процессов

Приветствие нового пользователя. Веб-хук на создание пользователя → Webhook в n8n → проверка подписи → письмо через SMTP-сервер компании и задача менеджеру в CRM.

Синхронизация клиентов из CRM. Триггер CRM на нового клиента → HTTP Request создаёт строку в таблице customers с идентификатором клиента из CRM в качестве rowId.

Обработка загруженных файлов. Веб-хук на загрузку файла в Storage → n8n получает метаданные → при превышении размера или неподходящем типе — уведомление администратору.

Когда выбирать Appwrite

• Нужен бэкенд с авторизацией, файлами и функциями, размещённый на своём сервере.
• Команде ближе единый REST API и консоль, чем прямая работа с SQL.
• Проект начинается сейчас: на Appwrite 2.0 можно сразу выбрать PostgreSQL.

Если важны сложные SQL-запросы и прямой доступ к базе из n8n, удобнее Supabase: там база — обычный PostgreSQL, к которому подключается узел Postgres.

Типичные ошибки

• API-ключ со всеми правами. Утечка такого ключа открывает весь проект; создавайте отдельный ключ под каждую интеграцию.
• Веб-хук без проверки подписи. Адрес узла Webhook может узнать посторонний и отправлять поддельные события.
• Обновление без резервной копии. Обновление меняет схему данных; откатиться без копии нельзя.
• Порт мастера установки оставлен открытым после настройки.