Cryptlex Documentation
  • Welcome to Cryptlex!
  • Getting Started
    • Overview
    • Licensing Models
  • License Management
    • License Templates
    • Implementing License Models
    • Creating Licenses
    • License Subscriptions
    • Custom License Fields
    • Meter Attributes
    • Suspending Licenses
    • Revoking Licenses
    • Maintenance Policies
  • Feature Management
    • Overview
    • Features and Entitlement Sets
    • License Feature Entitlements
    • Accessing Feature Entitlements
    • Use Cases
  • User Management
    • Roles
    • Creating Users
    • Authenticating Users
    • Organizations
    • Resellers
    • Customer Portal
    • Reseller Portal
    • Google SSO
    • SAML SSO
  • Release Management
    • Overview
    • Creating Releases
    • Distributing Releases
  • Node Locked Licenses
    • Overview
    • Using LexActivator
      • Using LexActivator with C, C++ and Objective C
      • Using LexActivator with C#
      • Using LexActivator with VB.NET
      • Using LexActivator with Java
      • Using LexActivator with Delphi
      • Using LexActivator with Python
      • Using LexActivator with Go
      • Using LexActivator with Node.js
      • Using LexActivator with Ruby
      • Using LexActivator with Android
      • Using LexActivator with iOS
      • Using LexActivator with Flutter
    • Using Web API
    • Offline Activations
    • Proxies and Firewall
  • Floating Licenses
    • Overview
    • Hosted Floating License Server
    • On-Premise Floating Licenses
      • LexFloatServer
      • Using LexFloatClient
        • Using LexFloatClient with C, C++ & Objective C
        • Using LexFloatClient with C#
        • Using LexFloatClient with VB.NET
        • Using LexFloatClient with Java
        • Using LexFloatClient with Delphi
        • Using LexFloatClient with Python
        • Using LexFloatClient with Node.js
        • Using LexFloatClient with Go
        • Using LexFloatClient with Android
        • Using LexFloatClient with iOS
      • Offline Floating License
  • Named User Licenses
  • Timed Trials
    • Verified Trials
    • Unverified Trials
  • Licensing Docker Apps
  • Webhooks
  • Automated Emails
  • Web Integration
    • Personal Access Tokens
    • Using Web API
    • Using Zapier
    • Using FastSpring
    • Custom Development
  • Changelog
    • Web API
    • LexActivator
    • LexFloatClient
    • LexFloatServer
  • Legal
    • Terms of Service
    • Privacy Policy
    • Subprocessors
    • Data Processing Addendum
    • Service Level Agreement
    • Security, Privacy, and Compliance
    • Open Source Licenses
  • Cryptlex On-Premise
    • Overview
    • System Requirements
    • Server Layout
    • Installation Guide
      • Docker Compose
      • Kubernetes
    • Configuring Client Libraries
    • Monitoring and Error Reporting
Powered by GitBook
On this page
  • Single server
  • Multiple servers with an external database
  1. Cryptlex On-Premise

Server Layout

PreviousSystem RequirementsNextInstallation Guide

Last updated 4 years ago

To help you determine the best server layout, look over the diagrams below, and determine which layout works best for your dev/testing and production environments.

Each layout will require the Cryptlex Web API server, Cryptlex Release server, Cryptlex GeoIP server, Postgres, Redis, and Nginx (for hosting the Cryptlex dashboard) web server .

The Cryptlex services are separated because as you will see in the diagrams below they may not all run on the same server, and each component can be horizontally scaled separately.

Single server

This configuration uses a single server to host all of the components for Cryptlex including the web dashboard. In this deployment model, there is no service redundancy and there is a risk of resource contention. For this reason, this model should be limited to the following purposes:

  • Development servers or workstations

  • Small production deployments

Multiple servers with an external database

This configuration uses separate servers to host all the services. The method for configuring this database is outside the scope of this guide but a general guideline would be to provide some sort of storage redundancy or clustering capability to ensure a high level of availability and performance. For the file store, it is recommended to use AWS S3.

Each Cryptlex Web API service is redundant and running on a separate server, this configuration provides basic redundancy.

In this scenario, Cryptlex should be placed behind a load balancer to utilize all services equally. Cryptlex doesn't use cookies, so sticky sessions are not required to be configured in the load balancer. This configuration is best suited for the following purposes:

  • Staging environments

  • Production deployments