Enterprise Server
Deploying the primary Self-Hosted product of Form.io. The Enterprise Server.
We will start our deployment with the Form.io Enterprise Server, which can be found on Docker Hub at the following URL.
A Docker Compose can be found here to set up the API Server Container (formio-enterprise) only, without the PDF Server Container:
https://github.com/formio/deploy/blob/main/deployments/compose/api-server.zip
The Enterprise Server can be deployed as follows:
Where the environment variables would be replaced with the following.
Environment Variables
Within the tabs below are all of the variables that are available for the formio/formio-enterprise deployments. Some of these variables are required to deploy the Enterprise servers while others are recommended.
It's recommended to change the Admin email and password to something secure before deploying.
Environment Variable
Description
Example
MONGO
The MongoDB connection string to connect to your remote database.
mongodb://<credentials>@aws-us-east-1-portal.234.dblayer.com:23423/formio?ssl=true
LICENSE_KEY
A valid license obtained from form.io.
abcdefghi1234567890
DB_SECRET
The database encryption secret
CHANGEME
PORTAL_ENABLED
Used if you wish to enable the portal in this environment making this a Portal Environment
true
ADMIN_EMAIL
If PORTAL_ENABLED is set to "true" this is used to determine the default root user email login
admin@example.com
ADMIN_PASS
If PORTAL_ENABLED is set to "true", this is used to determine the password of the default root user login
CHANGEME
PORTAL_SECRET
If PORTAL_ENABLED is not set (as in an API Environment), then this secret is used to connect another portal to this environment
CHANGEME
JWT_SECRET
The secret password for JWT token encryption.
CHANGEME
PDF_SERVER
The deployed PDF Server URL
http://pdf-server:4005
Using Docker Secrets As Environment Variables
For more documentation on this feature, please go to https://help.form.io/userguide/actions#template-service
You can also provide Environment Variables through the use of Docker Secrets. To utilize Docker Secrets, all of the configuration variables are the same as environment variables. Simply use the same name in docker secrets and the server will use the value. In order to use them, set DOCKER_SECRETS=1 in your environment variables. You can also set DOCKER_SECRETS_PATH to use a path other than /run/secrets.
Using Environment Variables with Node.js
For the Node.js deployments, we use a Node.js utility called dotenv to configure the environment variables of the running node application. This can be configured by creating a .env
file at the root of the Node.js application, that is similar to the following.
Database Connection String
When connecting to your database, it is important that you provide the name of the database within the Database connection string. By default, many of the platform providers such as Azure, AWS, and others do not provide the database name in the connection string. This causes a problem because the default name that MongoDB picks if it isn't provided is test which is different from the default database name of the Form.io platform, which is formio. Because of this, we recommend changing all database connections string to change the following
Incorrect:
mongodb://:@aws-us-east-1-portal.234.dblayer.com:23423/?ssl=true
Correct:
mongodb://:@aws-us-east-1-portal.234.dblayer.com:23423/
formio
?ssl=true
Form.io Enterprise API Server Environment
Portal Enabled Environment
Prior to deploying your environment, it is important to review the necessary environmental variables for your deployment. Ensure that variables such as the Database secret are properly configured, and consider enabling the Portal functionality as described below. Taking these steps will help ensure a successful and secure deployment of your environment.
It is recommended to enable the Portal during the initial environment creation, as it serves as the connecting mechanism to other environments. Given that the environment is usually restricted due to its connection with the production application, and additional may experience intermittent availability based on the development team's activities, it is advisable for this to be positioned between the and .
By enabling this non-production environment (referred to as the Test stage) amidst your other environments, your Form Builders will be able to work on their Forms within a stable Portal application environment. This setup eliminates the risk of altering the environment while alleviating the instability that may arise from working in other .
Run the following command to spin up your Portal Enabled API server environment.
Once this is done, the server will go through the initialization process and will install the Portal Base project as well as create the initial admin account for the deployment.
The Portal Base project is a special project that is used to control the portal application. Any users that can log into the portal are added to the User resource within this project, and anyone with an Authenticated role within this project will have the ability to log in and create new projects.
After the portal has been enabled, you can now login to the portal, by navigating to the root URL of the deployed API. The Admin email and password within the environment variables will authenticate you into the Portal.
Stand-Alone API Environment
Prior to creating additional environments, it is crucial to establish Stages within the Project of the Portal Enabled environment as a means to connect and provide a user interface between the additional environments we will be creating. These stages will be referred to as Developer, Test, and Live, aligning with the provided documentation. It is unnecessary to assign a specific name to the Live stage since it serves as the default production stage once a Project has been created.
Stages provide a way to isolate your Project forms and resources to enable Form Management between different environments.
Click Here for more information
Keep in mind, the Portal Application created within the Portal Enabled Test environment step simply serves as an API pathway and User Interface to create, modify, and save JSON for your other environments.
Now that our Stages have been set up, we can proceed to create our additional production and non-production environment(s) by executing the following command:
Next, we need to establish Remote Connections to our stages. Within each independent stage, navigate to the Stages settings and access the Connected Environment tab. Enter the environment URL and Portal Secret that was established during the environment creation process.
With these steps completed, you will have independent environments with their respective databases, all conveniently accessible within a unified Portal Application UI.
Last updated