Self-host Appwrite or Supabase when control over deployment, data location, or an isolated environment justifies taking responsibility for the platform. Choose between them by the application's data interface and the operations your team can maintain. A successful container startup demonstrates installation; production readiness requires tested upgrades, access controls, backups, and recovery.
Start with the reason to self-host
Write down the requirement that managed hosting cannot meet. It might be an isolated network, a customer-controlled environment, or a specific operational constraint. “Avoid the monthly bill” is incomplete unless the comparison includes infrastructure and engineering ownership.
Identify who will maintain the operating system, database, object storage, email delivery, certificates, and application services. Assign a second person who can recover the system when the primary operator is unavailable.
If the team cannot provide that ownership, a managed service may fit the product better. The general Supabase, Appwrite, and Firebase comparison covers platform selection; this article focuses on running the first two yourself.
Compare the data interface before the infrastructure
Supabase centers the application around PostgreSQL with related authentication, API, storage, and realtime services. Self-hosting therefore includes maintaining the database and the services that expose it.
Appwrite exposes its own application APIs over the configured database backend. Its current database configuration documentation lists PostgreSQL, MariaDB, and MongoDB, with PostgreSQL as the default for new installations. It says the database is selected during installation and cannot be changed afterward through that configuration.
That update makes older “Appwrite means MariaDB” comparisons unreliable. It also does not make Appwrite's public API identical to a direct PostgreSQL application. Your code still depends on the platform's resource model, permissions, and supported operations.
Evaluate the interface the application will use, then the engine you will operate. An existing PostgreSQL team may find Supabase's model familiar. A team already productive with Appwrite may prefer keeping its API contract. Neither preference removes the operational responsibilities below.
Treat Docker configuration as a release artifact
Both platforms document container-based self-hosting. Pin the platform release and record the complete configuration, including service images and environment variables. Avoid an unreviewed update that changes several dependencies because a floating image tag moved.
Supabase's Docker guide covers service configuration and deployment. Its self-hosting overview distinguishes a production deployment from the local development stack; the latter should not be exposed as a hardened production service.
For Appwrite, follow the current installation and production preparation guide. The production responsibilities include configuration beyond installing the containers.
Keep an inventory of public endpoints and internal services. Database ports, administration consoles, and internal service credentials should not become public accidentally. Verify the network policy from outside the server, rather than assuming a container name implies a private boundary.
Secure configuration is part of the data model
Replace example credentials, protect administrative access, and use HTTPS. Store deployment secrets in an access-controlled system and define how they are recovered during a disaster.
Appwrite's security guide calls out _APP_OPENSSL_KEY_V1, the key used to protect sensitive platform data. It warns that changing it can make existing protected values inaccessible. Backing up data without the required key can leave a restoration unusable.
For Supabase, follow the current Docker security configuration rather than reusing a sample environment file. Protect privileged API credentials and database access. A browser-facing application should not receive the secrets used by trusted backend services.
Review the product's authorization model after deployment. Platform installation does not prove that a customer can access only their organization's records and files. The tenant isolation guide describes the tests that matter at the application layer.
Back up the complete recoverable system
A database dump alone may omit uploaded files, function code, deployment configuration, and secrets. Inventory what must be restored for users to sign in and complete the primary workflow.
Appwrite's backup guide identifies database, storage, and environment configuration as backup concerns. Match the database procedure to your deployed engine and release. At verification time, its backup examples covered fewer engines than the current database configuration page, so this article intentionally provides no universal copy-and-paste backup command.
For Supabase, self-hosting does not include the managed platform's backup service. You must design database backup and recovery, and separately protect object storage and configuration. The self-hosting overview explicitly lists backup and disaster recovery as operator responsibilities.
Define recovery point objective, the acceptable data loss window, and recovery time objective, the acceptable outage duration. Then restore into a separate environment and measure actual recovery. Verify uploaded files, credentials, application records, and a representative transaction.
Keep backup access separate from ordinary application access. An attacker or mistaken operator who can delete the primary data should not automatically be able to delete every recovery copy.
Rehearse upgrades and rollback
Read the release-specific migration notes before changing production. Appwrite's updates guide describes the upgrade and migration process and recommends testing on a non-production instance first.
Use a staging environment with representative data. Take a verified backup, apply the documented upgrade, run migrations, and exercise login, authorization, storage, and background execution. Record the image versions and migration result.
Treat rollback as a data question as well as a container question. Starting an older image may fail against a newer schema. Determine whether recovery requires a forward fix, a compatible rollback, or restoration of both data and deployment configuration.
An illustrative release checklist is:
Record current platform and database versions.
Confirm a recent restore has succeeded.
Review migration and compatibility notes.
Upgrade staging and test business workflows.
Define the production recovery decision point.
Deploy, inspect health, and verify real operations.
This checklist is operational guidance, not a substitute for the platform's version-specific instructions.
Compare ongoing responsibility
| Operating concern | Self-hosted Appwrite | Self-hosted Supabase |
|---|---|---|
| Primary data interface | Appwrite APIs | PostgreSQL and related platform services |
| Engine maintenance | Selected supported engine | PostgreSQL |
| Backup ownership | Operator | Operator |
| Upgrade ownership | Operator follows platform migrations | Operator coordinates stack and database changes |
| Email delivery | Operator configures and monitors | Operator configures and monitors |
| Production monitoring | Operator defines coverage | Operator defines coverage |
Monitor user-visible behavior alongside container health. A running authentication service can still fail to send recovery email. A healthy database can still be unreachable from the API because credentials changed.
Track storage growth, failed requests, database connections, background work, certificates, and backup completion. Alert on conditions that need action and test that someone receives the alert.
Decide with a recovery exercise
Build the smallest representative application on each serious candidate. Then perform a clean restore and a version upgrade. Record the manual steps, missing documentation, time spent, and the expertise required.
Choose Appwrite when its application interface fits and the team can operate the selected stack. Choose Supabase when PostgreSQL-centered development fits and the team can maintain its surrounding services. Keep managed hosting in the comparison until self-hosting has a concrete, demonstrated benefit.
For an early product, the MVP architecture guide helps keep that infrastructure decision proportional to the business requirement.