Deploy to Web with Licensed Containers
Deploy your application to a licensed node, when and how to request one, how to set it up.
Overview
You can deploy your application to the web on a free node or a paid (licensed) node. See the FAQ below for the differences. This article describes the process of requesting a licensed node and deploying to it.
- Request licensed node
- Set up licensed node after it has been provisioned
- Invite Website Support user (websitessupport@byu.edu) to project with Application Operator role
- Deploy to Acceptance environment on licensed node
Browse the FAQ section below to familiarize yourself with Licensed Nodes.
1. Request Licensed Node
Go to the licensed node request form to submit a Mendix License Node request. If you are a student, you will not be authorized to submit the request and will need to have your manager submit the request. If you are working with a church institution other than BYU please submit your requests to mendixrequest@byu.edu.
Mendix licensed node request form
Below you will find the list of items you will need when submitting the request.
- App name - the exact name of your application project
- Technical contact name - from the General menu, should be a full-time employee
- Technical contact email - from the General menu
- Hosting Type - Select "Mendix Cloud"
- Location - Select "US West (Oregon)"
- URL - keep it relatively short
- Size - Select "XS21-STANDARD"
Example screenshots:
The Preferred URL is not a byu.edu subdomain. You can create that later. This is the (preferably short) URL for the Mendix Cloud environment (for example, funstuff.apps.us-2a.mendixcloud.com) that distinguishes your application from the thousands of others running in the Mendix Cloud. The Preferred URL will be used to automatically generate the URL for your Acceptance and Production environments. For example, if the Preferred URL is byu-personnel, the Mendix-generated URLs will be:
| URL | Environment |
| https://byu-personnel-accp.apps.us-2a.mendixcloud.com | Acceptance |
| https://byu-personnel.apps.us-2a.mendixcloud.com | Production |
If you need servers larger than the ones in the default XS21-STANDARD plan, explain that in the email. We start all applications at XS21-STANDARD, it is easier to upgrade the container size than to downgrade . See Mendix Pricing Plans for server details.
Once your request has been approved, an email will be sent from Mendix to the technical contact when the node is ready. They are usually provisioned within 24 hours, often in just an hour or so, unless we are out of them and need to order more.
2. Set Up Licensed Node
If your application is running on a free node and you have data in it that you don't want to lose, back it up before linking your application to a licensed node. You can upload and restore the backup to your application when it is running on the licensed node.
1. Sign in to Mendix online and go to the Nodes page to verify that your requested licensed node is available to use (Apps > Nodes).
2. Open the application project page and navigate to Environments from the menu on the left.
3. Select the "unlink your app" link. You will see a warning about losing data if it's running on a Free Node.
4. In the next popup, select "Yes, delete all data and unlink this app". You will be asked to use two factor authentication to proceed. If you haven't set up Mendix two factor authentication in Google Authenticator or Duo you will also see a popup with a QR code you can scan in Duo or Google Authenticator. Follow the prompts. If you have to sign in with two factor authentication, you may have to go back to step 3 to unlink your app and proceed.
5. Once the app is unlinked, the prompt changes. Click on the "select a node" link (not the button that says "Please select your preferred cloud"). You are selecting a node, not a cloud environment.
6. Locate your node that doesn't have an application linked to it yet and select the "Use this node" button.
Once the node is selected you can deploy your application to it. See step 4 below.
3. Invite Website Support User To Project
After you have set up your licensed node in the Mendix project management console for your project, invite the Website Support user (websitessupport@byu.edu) to your Team. Give it the Application Operator role.
This allows your application to be automatically tracked in the CMDB, which helps us calculate how much to budget each year for Mendix Cloud resources. These are paid for by BYU, not your department.
4. Deploy to Acceptance Environment
After you have linked your application to a licensed node, you will deploy it to the Acceptance environment. See Deploy to Acceptance Environment for details.
What Is A Licensed Node?
You can deploy your application to the Mendix Cloud on a free node, but it will go to "sleep" after an hour of inactivity and take awhile to access from the Internet when waking up. This can take 30 seconds to a minute or more. For applications that are always available, use a licensed node.
A licensed node usually has two environments, Acceptance and Production. Each environment has an application server to run the Mendix application and a database server to store its data. The database servers don't share data between environments and they can't be accessed directly. You can only access data through your Mendix application. You can export the data from one environment and import it to another or download it. Mendix does daily backups of data which can also be downloaded or imported.
BYU's Office of Information Technology currently pays for each environment in a licensed node. Because of the enthusiastic adoption of Mendix by many departments and other CES schools we are developing a policy to better manage the annual cost. Please bear in mind that when you request a node with two environments, we are paying for two sets of servers: two application servers, web servers for the application servers, and two database servers. The size of the servers, the number of CPUs, the amount of memory, and the size of the database storage all affect the cost. By default, we request the smallest servers. If you need more capacity or performance, please include that in the request for a licensed node. You can see the current Mendix Cloud server sizes here.
When Should I Request A Licensed Node?
If your application is intended to be used by others and needs to be available all the time, it is recommended that you deploy it to a licensed node sooner rather than later so you can show your work, get feedback from users, enable Single Sign-On with CAS, and test in an almost-live environment. You can deploy to Acceptance even if you have just the barest outline of a functional application; for example, just the basic BYU Starter App renamed with your site name. Redeployment to either environment only takes a few minutes and can be done as many times as needed. You can deploy to Production at any time, even while the app is still being developed.
If your application is an experiment, for your own use, for use by a small number of users and it's okay if it takes a minute or so to wake up from "sleep" after an hour or more of inactivity, a free node should suffice. You can enable BYU single sign-on with an app on a free node.
Can I Combine Applications On One Licensed Node?
To conserve and use resources more efficiently you can combine your application with one already running on a licensed node by either exporting it as a module package, importing it into the other project, and re-deploying that project, or by starting with an existing project and adding another module that you develop. Combining small applications with related or similar functionality to run on the same licensed node will reduce cost to the University. This is recommended especially if your application is relatively small:
- few users
- used infrequently
- not much data storage
The modules can have their own home pages and users can land on a specific home page when they sign in based on their security role. You can have a custom BYU subdomain, like nursing.byu.edu, pointing to the main application but you won't be able to have custom subdomains for each module in the app. You can have sub-paths of the domain point to each module. For example, nursing.byu.edu could point to a main landing page with links to other modules and the sub-paths nursing.byu.edu/internship, /schedule, /scholarship, /alumni could point to different modules inside the main app with their own security roles.
You can actually have a custom subdomain for each module using redirects. For example nursingalumni.byu.edu could redirect to nursing.byu.edu/alumni but once the user goes to nursingalumni.byu.edu and it redirects, the address they will see in the browser is nursing.byu.edu/alumni.
Another drawback to having multiple modules with different functions is the necessity of adding and managing more security roles and modifying the SAML20.CustomAfterSigninLogic microflow to automatically direct the signed-in user to a specific landing page based on the user's security role. The main project will need security roles for all the roles in each of your custom modules. The added complexity is not difficult to manage once you understand how it works.