This document is meant to server as a checklist of items to make sure a server administrator has implemented before deploying a Realm Platform application into a production environment. These follow the Realm best practices and will ensure the best possible experience for your organization and endusers.
Realm Sync can be configured using realm:// and http:// which will send authentication and sync traffic across the wire unencrypted. This traffic is susceptible to an attacker sniffing the traffic allowing them to glean sign-on credentials and sync data. Always configure your mobile app to use a certificate on the sync-client connection and a matching certificate in the Realm Object Server configuration. This is the only setting allowed on Realm Cloud. You can use the following guide as an example for configuring HTTPs on your server.
The Realm Object Server can be deployed as a single node application via a Docker or an npm package, however, this is only recommended for development and testing purposes. When it is time to go into staging and production, we always recommend our cluster deployment. This is because it can be difficult to predict usage patterns of your app when you are testing until you get it out into the wild and when you deploy as a cluster you have the ability to scale horizontally - a single node deployment does not have this capability and you can incur downtime if you must migrate from a single node to a cluster in production. Additionally, you should be deploying the stateful elements of Realm like the sync-workers or the Realm enabled server-side apps like the Global Notifier or Adapter on persistent volumes. To deploy in a distributed cluster use our Helm chart for Kubernetes or leverage the built-in cluster by using Realm Cloud
In addition to deploying Realm in a distributed cluster which comes with a built-in proxy specific for Realm traffic it is recommended to place a dedicated load balancer in-front of the proxy that is public facing. This load balancer serves as the entry point from the public Internet and has specialized functionality to prevent DDOS attacks, enforce firewall rules, and prevent malware intrusions. Typically this is a cluster of load balancers deployed with VRRP that share the same virtual public IP address which corresponds to public DNS address - this is also commonly where HTTPS termination should occur. An example on cloud would be AWS ELB and for self-hosted a cluster of F5s.
Within your client application, it is important to have the auth + Realm URLs point to the load balancer rather than the Realm Object Server directly. This will ensure the smoothest possible experience in case any backend components are migrated in the future.
In development it can be useful to leverage a single user with nickname auth or a simple username and password, however, once it is time to go to production a more robust user management strategy should be implemented. JWT is the recommended authentication provider for Realm when going into production. We recommend leveraging a 3rd party token issuer to manage users and issuing tokens - it is quick, easy, and secure. For server administrators, it is important that you disable all authentication providers that are not used by the client application.
Before going into production you need to make sure that you are monitoring the Realm cluster to get an accurate read on the resource consumption of sync users of your app for scaling as well as to alert you when the cluster enters an error state. Once an error occurs a thorough perusal of the logs will help determine the root cause of the issue. It is always recommended to stream logs to an external logging system as well as scrape metrics from the stats endpoints of the Realm cluster by an external monitoring system. These metrics can then be fed into an alerting system that notifies operators in case of error states.
The Realm Object Server by default comes with only a few optimizations enabled however Realm Cloud comes with a variety of options enabled to give you the best possible performance. If you are self-hosting we recommend configuring the following parameters in your server configuration
The Realm Cloud comes with built-in backups as part of a dedicated package, in the event of a disaster we will be able to recover and restore your data. If you are self-hosting, you should also implement a regular backup system, such as a cron job that takes a backup of the Realms on the sync-workers and moves the backup to a redundant file system such as S3. Be sure to document and test your disaster recovery and restoration procedure.
There are a number of additional items that should be considered within the client application before deploying to production. The best place to learn more about these is within a dedicated guide in our sync documentation. You can find the details here: