Staging vs. prod servers

By default, when you create an account on our website at https://www.seald.io/create-sdk, your team is created on our staging server (development environment).

This environment is very similar to our production environments, and allows you to develop your project with confidence that you can then switch to a production environment without any problems.

However, you should be aware that this staging environment is not suitable for protecting real confidential data, and should therefore never be used in production, as it has some significant differences from our production environments.

WARNING

Data from the staging environment cannot be migrated to a production environment. It is imperative to create a production account before starting to use the Seald SDK on real confidential data.

To create a production account, contact us.

Server Deployment

Our production servers are deployed in a replicated high-availability setup, with fail-over systems from one server to the next to ensure strong fault tolerance and provide a high level of service.

Our staging environment, on the other hand, runs on a single server, without any fault tolerance nor high availability of the application servers nor the database, and does not guarantee any level of service.

Data Persistence

Seald does not guarantee data persistence on the staging environment.

Indeed, we may have to reset this environment and delete accounts and data without notice, whether it be during crash recovery, to clean up unused accounts, in case of a violation of our terms and conditions, or for any other reason.

On our production environments, however, we strive to follow industry best practices, using replicated application servers, redundant databases, multiple regular backups to remote sites, etc.

Protection of stored identities

Since the staging environment is intended for development, it has some features to make testing easier.

For example, on the staging environment, you can use fake_otp: true to bypass sending an authentication challenge for retrieving an identity stored with Two-man-rule, which sets the challenge to 'aaaaaaaa'. This particular feature would allow your server, if you use Two-man-rule identity storage, to impersonate your users, thus rendering end-to-end encryption ineffective. This feature is blocked on production environments.

The staging environment also allows you to completely delete identities stored with Two-man-rule with full_forget: true, which would allow the server to overwrite the user's stored identity and replace it with another one it controls, thus performing the equivalent of a Man-in-the-middle attack.