If you already treat infrastructure as code elsewhere, Appwrite project configuration was the odd layer out: databases, tables, storage buckets, functions, and sites were easy to tweak in the Console, with the CLI, or in appwrite.json, and hard to keep identical across staging, production, and extra regions. That is operational drift with a familiar fix: declare the same resources in HashiCorp Configuration Language (HCL), store the Terraform state next to your other tooling, and let plan / apply (or your CI wrapper) do the talking.
The official Terraform provider is now published as appwrite/appwrite on the HashiCorp Terraform Registry. It manages project resources over the Appwrite API: TablesDB, Storage, Functions, Sites, Auth, Messaging, webhooks, and backup policies. It does not install or operate the Appwrite instance itself. For that, stay with self-hosting and your existing deployment story.
Why we built it this way
We set out to make Terraform cross-cutting across the Appwrite project configuration, not a databases-only path you abandon when you work on Functions, Sites, or the next surface area. The provider maps most of what you manage at the project layer through the API, so one IaC story covers those capabilities instead of a tool that stops at schemas.
Cross-project mattered too: the same workflow is meant to work across Appwrite projects and environments when you need aligned baselines, not only inside a single stack or a single product silo.
We also wanted it open by design. Use it for familiar patterns (parity between environments, plan / apply in CI, imports from existing projects), or compose resources in ways that fit your architecture when you need something less conventional. The point is full freedom to stay traditional or get creative; Terraform is the shared layer, not a rigid template you have to follow.
What is in scope
The provider maps Appwrite project resources to Terraform resources the way you would expect if you have used the platform before. TablesDB is the deepest surface: databases, tables, columns, indexes, and rows so you can declare schemas and seed data in HCL. Storage covers buckets and file uploads (appwrite_storage_bucket, appwrite_storage_file). Functions and Sites let you define serverless functions (with runtimes, schedules, event triggers, and environment variables) and hosted frontends (with framework presets for Next.js, Nuxt, Astro, SvelteKit, and others) right alongside the backend resources they depend on. Auth resources manage users and teams (appwrite_auth_user, appwrite_auth_team). Messaging handles providers, topics, and subscribers. Dedicated resources for webhooks (appwrite_webhook) and backup policies (appwrite_backup_policy) round out the set. An appwrite_tablesdb data source looks up an existing database by ID when another resource needs a stable reference.
Authentication follows the same model as any other automation: your Appwrite API endpoint, a project API key with the right scopes, and (on Community Edition or dev clusters) whatever TLS settings you already use. The configuration guide documents endpoint, project_id, api_key, and self_signed so you can mirror how CI talks to Appwrite today.
What a basic flow looks like
End to end, Terraform does what you expect: pin the provider, pass credentials, declare resources, then run terraform init, terraform plan, and terraform apply when you like the diff. The snippets below are intentionally small so you can see the shape before you open the full guides.
Provider and configuration. Declare appwrite/appwrite, then point the provider at Appwrite Cloud (swap <REGION> for your region subdomain). On Community Edition, set endpoint to your instance URL and use self_signed when you need it. The Configuration page has the exact pattern.
terraform {
required_providers {
appwrite = {
source = "appwrite/appwrite"
version = "~> 1.0"
}
}
}
provider "appwrite" {
endpoint = "https://<REGION>.cloud.appwrite.io/v1"
project_id = "project-id"
api_key = "api-key"
}
A database and table. A appwrite_tablesdb resource creates a database, and appwrite_tablesdb_table adds a table inside it.
resource "appwrite_tablesdb" "main" {
name = "main"
}
resource "appwrite_tablesdb_table" "users" {
database_id = appwrite_tablesdb.main.id
name = "users"
}
A storage bucket. Buckets follow the same pattern: declare the resource and configure the options you need.
resource "appwrite_storage_bucket" "images" {
name = "images"
maximum_file_size = 10485760
allowed_file_extensions = ["jpg", "png", "webp", "gif"]
compression = "gzip"
}
A serverless function. Declare the runtime, wire up event triggers, and set environment variables, all in HCL.
resource "appwrite_function" "on_signup" {
name = "on-signup"
runtime = "node-22"
entrypoint = "index.js"
commands = "npm install"
events = ["users.*.create"]
timeout = 30
}
resource "appwrite_function_variable" "api_url" {
function_id = appwrite_function.on_signup.id
key = "API_URL"
value = "https://api.example.com"
}
A hosted site. Pick a framework preset and configure the build pipeline.
resource "appwrite_site" "dashboard" {
name = "dashboard"
framework = "nextjs"
build_runtime = "node-22"
install_command = "npm install"
build_command = "npm run build"
}
From there you layer columns, indexes, rows, files, messaging resources, webhooks, backup policies, and data sources as needed. Start from the Terraform provider overview and the guides for Databases, Storage, Functions, Sites, Auth, Messaging, Webhooks, and Backups.
How Terraform fits
You are not replacing the Console for debugging or the SDKs for application logic. You are giving project-level config a path through code review, pinned required_providers versions, and repeatable applies, the same contract you use when someone opens a PR against VPC rules or a managed database.
In practice that usually means: preview changes with terraform plan before they hit a shared environment; attach plans to tickets or merge requests; and import resources that predate the Terraform rollout instead of recreating them by hand. The generated documentation on the Terraform Registry is the source of truth for arguments, attributes, and import syntax per resource.
Where to go next
Our Terraform provider docs list every resource area and link to Configuration (required_providers, environment variables, optional per-resource project_id), resource guides for Databases (including the appwrite_tablesdb data source for lookups), Storage, Messaging, Auth, Functions, Sites, Webhooks, and Backups.
The implementation is open-source at appwrite/terraform-provider-appwrite for issues, feature discussion, and contributions. The Integrations catalog also lists Terraform provider for Appwrite next to the rest of the ecosystem. This release is summarized in the changelog. The Registry listing tracks the latest published provider version and generated schema.
