Operator Playbook: How We Set Up Appwrite as a Blog Backend for a Next.js Site

We chose Appwrite Cloud as the backend for our blog system on a Next.js site hosted on Vercel. Here is the exact setup process and what we learned.

Why Appwrite over a traditional database: Appwrite provides a managed database with built-in authentication, real-time subscriptions, and a generous free tier. For a blog that needs CRUD operations without managing a database server, it hits the sweet spot between simplicity and capability.

The setup required four environment variables on Vercel: `NEXT_PUBLIC_APPWRITE_ENDPOINT` (we used `https://sfo.cloud.appwrite.io/v1` for the San Francisco region), `NEXT_PUBLIC_APPWRITE_PROJECT_ID`, `APPWRITE_API_KEY`, and `NEXT_PUBLIC_BLOG_ADMIN_PASSWORD`.

The key insight: our blog service auto-provisions the Appwrite database and collection on first API call. When the `/api/blog/posts` endpoint is hit for the first time, it creates the database named `blog`, the collection `blog_posts`, and all required attributes (title, slug, content, excerpt, coverImage, author, status, createdAt, updatedAt) plus indexes. This means zero manual setup in the Appwrite console.

The upload process: we wrote a Node.js script that reads 100 blog posts from batch data files and POSTs them to the API with a 1-second delay between requests to avoid rate limiting. The script handles duplicate detection (HTTP 409) gracefully, so re-running it is safe.

One gotcha: the `NEXT_PUBLIC_` prefix on `BLOG_ADMIN_PASSWORD` makes it visible in client-side JavaScript. For a blog admin panel this is acceptable, but for production-grade authentication you would want server-only session management.

Practical takeaway: Appwrite Cloud works well as a blog backend for Next.js on Vercel. Auto-provisioning the database on first call eliminates manual setup steps. Use environment variables for all credentials and test the upload script with `--dry-run` before going live.