n8n and backend services: Part 4 — Appwrite

Appwrite — an open backend platform that was originally designed for installation on your own server. The code is released under the BSD-3-Clause license. There is also a cloud version, Appwrite Cloud, but the primary scenario is self-hosting via Docker.

What Appwrite consists of

• Databases — storage for structured data. The service is now called TablesDB: data is stored in tables and rows (previously — in collections and documents).
• Auth — registration, login, sessions, user teams.
• Storage — files with access rights.
• Functions — server functions that run on events, on a schedule, or via HTTP requests.
• Realtime — client subscriptions to changes in data, users, and files.

All features are available through a single REST API, and they can be managed manually in the admin console.

Which database is used internally

Articles about Appwrite often say that it runs on PostgreSQL. For most existing installations this is not correct: before version 2.0 Appwrite used MariaDB. In Appwrite 2.0, released on September 7, 2026, PostgreSQL became the default database for new self-hosted installations. The installer offers a choice of PostgreSQL, MariaDB, or MongoDB.

The choice is made once: you cannot migrate an existing installation from one database to another. Older installations remain on MariaDB after upgrading to 2.0.

Installing on your own server

The minimum requirements per the documentation are 2 CPU cores, 4 GB of RAM, 2 GB of swap, and Docker Compose version 2. Installation is done through a setup wizard in the browser on port 20080: main parameters are set, security keys are generated, and an admin account is created. If the server is remote, port 20080 needs to be temporarily opened in the firewall and closed after installation.

For a production installation you’ll also need a domain name and HTTPS, backups of the database and file volumes, and an update plan: Appwrite updates include schema changes, so a fresh backup is mandatory before updating.

For projects handling personal data of Russian citizens, self-hosting with a Russian provider satisfies the requirement that initial collection of that data occur in databases located on Russian territory. The cloud version is hosted abroad.

How to connect Appwrite to n8n

There is no built-in Appwrite node in n8n; all operations are performed with the HTTP Request node.

1. In the Appwrite console create a project and an API key with the required permissions (scopes). Give the key only the rights needed for the process: for example, read and write rows, without user management.
2. In n8n create credentials of type Header Auth or set headers in the node itself.
3. Configure the HTTP Request.

A request to create a row in a table looks like this:

POST https://appwrite.example.ru/v1/tablesdb/{databaseId}/tables/{tableId}/rows
Content-Type: application/json
X-Appwrite-Project: <Project ID>
X-Appwrite-Key: <API Key>

{
  "rowId": "unique()",
  "data": {
    "name": "Ivan Petrov",
    "email": "ivan@example.ru"
  }
}

The string "unique()" instead of an identifier asks Appwrite to generate it itself. If the record corresponds to an object in an external system, it’s better to pass your own stable identifier — then a repeated request will not create a duplicate.

How Appwrite notifies n8n about changes

Webhooks are configured in the project console: Settings → Webhooks. You specify the address of the Webhook node in n8n and the events to react to — user creation, row change, file upload, and others.

Each Appwrite request includes headers: X-Appwrite-Webhook-Events (which events fired), X-Appwrite-Webhook-Project-Id, X-Appwrite-Webhook-User-Id, and X-Appwrite-Webhook-Signature. The signature is the HMAC-SHA1 of the string “webhook URL + request body” using the webhook signing key, encoded in Base64. In n8n it’s verified with the Crypto node and compared to the header; requests with an invalid signature are discarded.

If logic is more convenient to run inside Appwrite, the event is handled by a Function, which then calls n8n.

Example workflows

Welcoming a new user. Webhook on user creation → Webhook in n8n → signature verification → email via the company SMTP server and a task for the manager in the CRM.

Synchronizing customers from the CRM. CRM trigger on a new customer → HTTP Request creates a row in the customers table with the CRM’s customer ID as rowId.

Processing uploaded files. Webhook on file upload to Storage → n8n receives metadata → if size exceeds limit or type is unsuitable — notify the administrator.

When to choose Appwrite

• You need a backend with authentication, files, and functions hosted on your own server.
• Your team prefers a single REST API and an admin console over working directly with SQL.
• The project is starting now: with Appwrite 2.0 you can choose PostgreSQL right away.

If complex SQL queries and direct database access from n8n are important, Supabase is more convenient: there the database is a standard PostgreSQL to which a Postgres node can connect.

Common mistakes

• API key with all permissions. A leak of such a key exposes the entire project; create separate keys for each integration.
• Webhook without signature verification. The Webhook URL can be discovered by outsiders who can then send forged events.
• Updating without a backup. Updates change the schema; you cannot roll back without a copy.
• Leaving the setup wizard port open after configuration.