Skip to main content

Deployment Architecture

Appsmith can be accessed through the Cloud by signing up at app.appsmith.com or deployed on-premise using the setup instructions provided in the Self Hosting guide.

The Appsmith Cloud version runs on geographically distanced Kubernetes clusters via AWS. This deployment strategy allows the Appsmith Cloud platform to scale and avoid downtime during outages, as well as conduct rolling updates with minimal disruptions to service. The self-hosted Appsmith runs as a single Docker container, housing all five processes in one image via Supervisord.

This page provides information about the self-hosted deployment architecture of Appsmith.

Components​

Appsmith is deployed as a single Docker container with a single volume for storing persistent data. A single Docker container runs the following processes to deploy and get started with Appsmith:

  1. The Appsmith Server (backend) as a Java process, which handles:

    1. Authentication: login credentials, OAuth 2.0 with Google and GitHub, SSO with OIDC and SAML
    2. A CRUD API for users, workspaces, applications, pages, and widgets
    3. An action execution module that executes your queries to your databases and APIs
    4. A git module that maintains clones of your Git-connected apps on the file system

  2. The Caddy Server, which routes:

    1. Requests to static assets like JavaScript, CSS, and images
    2. Incoming requests to the backend server, or the RTS depending on the request path
    3. Path-unidentified requests to an index.html page with a 200 status code. This is like a typical single-page application where the client React code is expected to understand the path and show the UI accordingly.

  3. The Realtime Server (RTS), a tiny NodeJS server that handles a few features such as mapping dependencies between APIs, queries, and web UI components. It also updates references for all reference-able entities when their names change in Appsmith.

  4. The MongoDB Server, which stores all persistent data needed and generated by Appsmith’s building blocks, like:

    1. Your users’ details and permissions
    2. Workspaces you have created
    3. Applications you are building and have deployed
    4. Datasources you have connected to
    5. Queries that connect those datasources to your apps.

  5. The Redis Cache, which is used for storing user sessions and cache permissions that a user has access to directly and indirectly.

Process management​

To manage the processes needed to function, Appsmith uses Supervisor. This is a lightweight process manager that, when given a list of things to run, runs them, restarts them if they crash, and collects their logs for maintenance and debugging.

Supervisor comes with a command line tool called supervisorctl that's used to control these processes individually. For example, running supervisorctl restart redis restarts the Redis process. Or, as another example, the Save and Restart button under Admin Settings on the Appsmith UI is powered by the supervisorctl tool; clicking that button after making changes with the UI prompts the backend server to execute supervisorctl restart backend, which restarts the backend process.

When the user runs the Docker command to start the Appsmith container, Supervisor identifies which processes are required to start and run. This includes the backend server, the RTS, and the Caddy server, as well as any additional processes that haven't been plugged in by the user externally, such as a custom MongoDB or Redis instance.

For each of the processes in Appsmith, the container’s entry-point script (which Docker invokes when the container starts) generates a config file with all the details needed for the Supervisor daemon. For example, the config file generated for the backend Java server includes the full set of commands for starting the process, as well as all necessary environment variables and settings. This same entry-point script also helps set up SSL certificates and install custom CA roots.