Appwrite is an open-source, self-hosted Backend-as-a-Service that makes app development easier with a suite of SDKs and APIs to accelerate app development. #30DaysOfAppwrite is a month-long event focused on giving developers a walkthrough of all of Appwrite's features, starting from the basics to more advanced features like Cloud Functions! Alongside we will also be building a fully-featured Medium clone to demonstrate how these concepts can be applied when building a real-world app. We also have some exciting prizes for developers who follow along with us!
Welcome to Day 27 👋. Now that we've covered many of the capabilities of Appwrite, we should discuss running Appwrite in production once your app is finally ready for users.
First and foremost, good security is a moving target. Appwrite provides a suite of APIs that abstracts many security requirements of your application, but hosting software online means exposing a computer to the internet. While we can't cover everything, let's discuss some security best practices when running Appwrite in production.
Before discussing the steps to run Appwrite in production, we need to talk about the system on which Appwrite will run. These tips assume you're running Appwrite on a Linux-based server, but the principles apply to any operating system.
Most security breaches occur on systems that run out-of-date software versions with security vulnerabilities. The problem is understandable - it's hard to keep up with system updates. Running updates on a cron schedule isn't the best either, as security updates are best installed immediately. Use tools like Ubuntu's
unattended-upgrades and Fedora's
dnf-automatic packages to run with the latest updates for your software.
A security best practice is a deny-by-default security policy - we should only give explicit access to the services we want. Appwrite considers this in its default configuration: the only service exposed to the outside world is what we need, the Traefik proxy. So, if Appwrite is the only service we want to expose on the server publicly, we can use firewall tools to block access to any other unused ports.
If you use SSH to administer your system, don't forget to leave that open in your firewall! SSH is considered a private service, meaning that it should be publicly accessible, but only to authorized accounts. The best practice is to use cryptographic tools like SSH keys instead of passwords, as they're much, much harder to falsify.
Here are some additional resources that go into more detail about best practices:
Now, let's discuss setting up Appwrite for production.
You can easily configure Appwrite for production with the many environment variables that it offers. The following variables should be set in the hidden
.env file in your
appwrite installation directory when deploying for production:
_APP_ENV: Change to
_APP_OPTIONS_ABUSE: Enables abuse checks and rate-limiting for the API. Set to
_APP_OPTIONS_FORCE_HTTPS: Forces connections to use HTTPS for secure data transfer. Set to
_APP_OPENSSL_KEY_V1: This is the secret used to encrypt information like sessions and passwords. Please change this to something secure and random, and keep it safe and backed up.
_APP_DOMAIN: Set this to your domain name for Appwrite to auto-generate an SSL certificate.
Three environment variables are available to restrict access to the Appwrite console:
_ROOT var to
enabled if you only want a single account to have access to the console. You can restrict access to specific email and IP addresses with their respective environment variables for multiple users.
For production, you can enable
clamav scanning of uploaded files for any known malicious objects. Set
enabled and uncomment the service in
docker-compose.yml to use this feature. Don't forget to also uncomment
clamav in the
depends_on section of the main
Cloud Functions can be customized to suit the needs of your production system, largely for controlling resources available to Function executions:
_APP_FUNCTIONS_CPUS: The maximum number of CPU cores that Cloud Functions can use.
_APP_FUNCTIONS_MEMORY: The maximum memory available to Cloud Functions (in megabytes).
_APP_FUNCTIONS_CONTAINERS: The maximum number of containers Appwrite keeps alive defaults to 10. Increase this number to increase the number of warm functions.
_APP_FUNCTIONS_RUNTIMES: A list of available runtimes for new Cloud Functions.
All Appwrite environment variables can be found in our docs.
Feel free to reach out to us on Discord if you would like to learn more about Appwrite, Aliens, or Unicorns 🦄. Stay tuned for tomorrow's article! Until then 👋