Version 0.6.2  
Docs

Production

Appwrite default setup is designed to help you get started quickly with using the Appwrite server. To run Appwrite successfully in a production environment, you should follow a few basic concepts and best practices. This document assumes you have some very basic understanding of Docker and Docker Compose command-line tools.

Encryption

By default, the Appwrite setup doesn’t come with a uniquely generated encryption key. This key is used to store your files and sensitive data like webhook passwords or API keys in a safe way. To take advantage of this feature, you must generate a unique key and set it as the value of the _APP_OPENSSL_KEY_V1 environment variable.

Make sure to keep this key in a safe place and never make it publicly accessible. There are many online resources with methods of keeping your secret keys safe in your servers.

Limit Console Access

By default, anyone can signup for your Appwrite server, create projects, and use your computing power. While this is great for testing around or running your Appwrite service in a network isolated environment, it is highly not recommended for public production use.

We are providing three different methods to limit access to your Appwrite console. You can either set a list of IPs, email address or email domains which users are allowed to signup from. You can choose one or multiple restriction methods to apply.

Scaling

Appwrite was built with scalability in mind. Appwrite can scale both horizontally and vertically.

Appwrite uses a few containers to run, where each container has its job. Most of the Appwrite containers are stateless, and in order to scale them, all you need is to replicate them and setup a load balancer to distribute their load.

If you decide to set up a load balancer for a specific container, make sure that the containers that are trying to communicate with him are accessing him trough a load balancer and not directly. All connections between Appwrite different containers are set using Docker environment variables.

There are three Appwrite containers that do keep their state. MariaDB, Redis, and InfluxDB containers are used for storing data, cache and pub/sub messaging, and usage stats (in this order). To scale them out, all you need to do is set up a standard cluster (just like you would with any other app using these technologies) according to your needs and performance.

Emails

Sending emails is hard. There are a lot of SPAM rules and configurations to master in order to set a functional SMTP server. The SMTP server that comes packaged with Appwrite is great for development but needs some work done to function well against SPAM filters.

Another easier option is to use an ‘SMTP as a service’ product like Sendgrid or Mailgun. You can change Appwrite SMTP settings and credentials to any 3rrd party provider you like who support SMTP integration using our Docker environment variables. Most SMPT providers offer a decent free tier to get started with.

Backups

Backups are highly recommended for any production environment. Currently, there is no built-in script we provide to do this automatically. To be able to backup your Appwrite server data, stats, and files, you will need to do the following.

  1. Create a script to backups and restore your MariaDB Appwrite schema. Note that trying to backup MariaDB using a docker volume backup can result in a corrupted copy of your data. It is recommended to use MariaDB or MySQL built-in tools for this.
  2. Create a script to backups and restore your InfluxDB stats. If you don’t care much about your server stats, you can skip this.
  3. Create a script to backup Appwrite storage volume. There are many online resources explaining different ways to backup a docker volume. When running on multiple servers, it is very recommended to use an attachable storage point. Some cloud providers offer integrated backups to such attachable mount, some of them are GCP, AWS, DigitalOcean, and the list continues.

Error Reporting

By default, Appwrite installation comes with error debugging is turned off, You can turn it off in dev mode to try and debug issues, or report problems while still in development mode.

In production, it is highly recommended to turn error reporting off. To do so, make sure the Appwrite container environment variable _APP_ENV value from is set to production and not development.