Our goal? Making
Are you a newcomer to the Mendix universe who wants to do some hands-on experimenting? Or are you already a Mendix user, looking to use a small application to experiment or validate a business idea? If the latter is the case, you can reap the benefits of the free “sandbox” environment that Mendix offers. This environment allows you to experiment. If your idea catches on and has serious business value, you have the opportunity to switch to a licensed environment with more comprehensive service-level agreements.
The term “sandbox” is often used in software development circles and refers to an environment that is temporary, more limited and smaller than developments that make tougher demands on functionality, availability and performance.
According to Wikipedia, a sandbox is a testing environment that isolates untested code changes and outright experimentation from the production environment or repository.
Every Mendix app that you make on your own local machine runs in the Mendix Studio Pro development environment. However, Studio Pro is not the appropriate platform when it comes to making apps readily available to other users. Luckily, Mendix Studio Pro allows you to deploy your app to a Mendix sandbox environment with one simple click of a button. The application now runs in the cloud and can be accessed and used by other people.
You can attach one sandbox to one Mendix project. The link is established when you generate a new Mendix project. The sandbox is limited in terms of functionality, scalability, availability and performance. We will delve deeper into the differences between sandbox and paid environments later on in this blog post. Technically, a sandbox application runs in a single docker container. The container runs in the Mendix Cloud v4 (free tier environment), which, runs on AWS (Amazon Webservices). The specifications are:
The application will go into sleep mode if it’s inactive and will restart when it is used again. An app that is used regularly during the day will often only go into sleep mode at nighttime.
A paid environment that requires the purchase of an annual license is called a licensed cloud node. These nodes offer a default production and acceptance environment at the very least, but they also often an additional test environment is used that allows you to easily deploy and test applications in the cloud.
These are the 11 differences between a sandbox and a licensed cloud node:
|Licensed cloud node|
|It’s not possible to use a custom domain.||You are able to use a custom domain.|
|A maximum of 50 users at a time.||The number of users depends on the license agreement.|
|You can follow the progress of your deployment via a live log.||You can trace your deployments in real time in your project environment.|
|Contains no downloadable log files.||Contains actual log files and a log archive.|
|No elaborate options available for monitoring and alerts.||Default monitoring of CPU, memory, threads, sessions and much more.|
|You can’t package a version of the application and subsequently deploy it to a sandbox.|
Every time you deploy a new version to the sandbox, the version you run there will be overwritten.
|A licensed cloud node gives you more control. Packaging a version and deploying it to different environments (testing, acceptance and production) is much easier.|
|No scheduled events.||Scheduled events can easily be turned on or off.|
|Constants have to be set within the model.||Constants can be set per environment.|
|Daily backups are saved for a period of just two weeks.||Backups are saved daily/continuously and remain available on request for up to one year.|
|Client certificates and access restriction profiles are not configurable.||Client certificates and access restriction profiles are configurable.|
|The environment shuts down when it’s inactive and restarts when you reactivate the application or make a new deployment. This takes 10 to 20 seconds.||You can start up and shut down the environment at will.|
If you encounter serious problems when using sandbox environments, you would be well-advised to purchase a licensed cloud node. Such a solution gives you the opportunity to deploy your Mendix projects in the Mendix Cloud, but also allows you to utilize a different cloud environment of your choice if your license supports this option. MS Azure, Google Cloud, SAP Cloud Platform and Pivotal are prime examples of alternative cloud platforms that you could use. But keep in mind that you have to take care of all the infrastructure, management and system issues if you use one of the alternate cloud platforms.
Certain limitations are solvable by using specific workarounds, but these workarounds offer far from ideal solutions. We will list a couple of limitations and the corresponding workarounds.
No proper insight in tracking graphs and information → Add the Google Analytics widgets to your model. The widgets will already show you some extra information about the utilization of the application, such as who uses it and when users log in.
Log files about the recent periods in which the was application run are unavailable → Use the logging module from the Mendix App Store to write log messages to the database. This enables you to build a logging archive. Note that the storage space in your database is limited. To solve this problem, you could write these log messages to an external environment by using a REST interface. You can store them in Datadog or a similar loggin-platform or in an alternative database.
There’s no custom domain name available to run the app → To hide the URL of the sandbox, you can use a new domain name or use a page on an existing domain that shows an iframe. You can use the URL of the sandbox (click here to view a sample code) on this page. Subsequently, you can invoke the application through this custom domain name. Iframes do have limitations, especially when the size of the screen that displays your app changes on a regular basis.
No advanced backup functionality → You should regularly secure a backup by downloading it to your local environment. When you work in a sandbox environment, backups are stored for a maximum of two weeks. Developing your very own functionality for exporting and importing data would be even better. In a sandbox, you can only restore backups made by Mendix and you can not upload your own.
Wanting to store more than 1 GB in files → Does a certain application want to store many files? Consider using external cloud storage. You can integrate this storage solution with your cloud environment by using a REST API. AWS S3 of Dropbox are two reliable and popular external storage solutions that offer a low price per GB.
No scheduled events → To trigger processes that need to be executed daily, you will have to reach your sandbox application from another cloud application. This ensures that data is still synchronized on a daily basis. Google Scheduler, AWS Cloudwatch or a (CRM)-application that you already use can solve this problem for you.
Yes, you can. But you’ll have to take the aforementioned (technical) limitations into account. Besides that, you have to realize that lesser SLAs and uptime guarantees apply for sandbox environments. Of course, Mendix Support is always available if any issues arise. You can address your specific problem by filing a ticket. If this, in conjunction with the appropriate workarounds, suffices for the requirements that you have set for the application environment, you can safely and happily use a sandbox for production applications!
Based on my own personal experience, I would say that a sandbox is an excellent solution if you’re dealing with small, non-process-critical and non-mission-critical apps that are not simultaneously accessed by a huge number of users. I have been able to use several apps in a stable and satisfactory manner in a sandbox ever since the sandbox environments made its appearance.
If you create a new application on the Mendix platform, the URL of the app is also attached. It is important to know that you can’t adjust this URL afterward!
When you create a new application, the URL is available under:
https://<name-of-your-app-numberXXX>-sandbox.mxapps.io. This URL is generated according to the name that you initially used when you created your new app. After your first deployment, you will be able to reach the app through this URL.
Click on “Run”, which can be found in the menu “Run”, to deploy the new version to a sandbox environment. But beware! Your adjustments are immediately committed in the team server (SVN), whilst your version will be overwritten to the sandbox cloud. If you test locally, make sure you choose the option “Run locally”.
This is not a default option if you’re working on a Mendix project. But there is a workaround that enables you to create a testing environment in a sandbox. The availability of such an environment offers advantages when it comes to testing new features (or have them tested) before you deploy them to the “production” sandbox.
Unfortunately, you have to perform a number of manual actions if you want to create a testing sandbox. Follow the steps mentioned below if you want to create a testing environment to accompany your app.
Advanced tip: would you like to have a deviating URL for your testing environment? Then give the project a name. “SurveyBuilder-test” is a good example. Subsequently rename the .mpr via TortoiseSVN of SmartSVN and give the .mpr the exact same name as your production app .mpr. Commit this change first before you move on to step 4.
If you want to test the changes in your application in the testing environment, you should copy/paste all files from the directory of your production application, except the .svn and.mendix-cache directories (If you don’t see them, check image->hidden items).
Like I said before, this requires a lot of manual work. In the licensed version, all of these steps are, of course, neatly automated.
I hope you enjoy your sandbox experience. Experiment and learn! And if any questions should arise, feel free to contact us!