Experimenting with New Apps in the Free Sandbox Environment of Mendix

Are you new to the world of Mendix and want to experiment hands-on with the platform? Or are you already using Mendix, but want to use a small application to experiment or validate an idea? In that case, you can use the free 'sandbox environment.' This is the ideal place to test whether an application idea can add value. Within a sandbox, you can experiment and test extensively. If the idea catches on and has business value, you can switch to a licensed environment with more extensive agreements.

What is a sandbox?

The literal meaning of a sandbox is a sandbox. The term is often used in software development projects to indicate that the environment you are using is temporary, limited, or smaller than environments that have more demands on functionality, availability, or performance.

According to Wikipedia, sandbox environments are often used to test software in a fully isolated IT environment (without a network or connection to the outside).

What is a Mendix sandbox?

Every Mendix app you create on your local machine runs within Mendix Studio Pro, the development environment of the platform. However, Studio Pro is not well-suited for making apps available to other users. This is where the sandbox comes in. From Mendix Studio Pro, you can transfer the application to a sandbox environment with a single click of a button. The application now runs 'in the cloud' and is accessible to multiple people.

You can link one sandbox to a single Mendix project. This connection is established when you create a new project to build a Mendix app. The sandbox is limited in functionality, scalability, availability, and performance. The differences with a paid environment will be discussed in detail later in this article.

From a technical perspective, a sandbox application runs in a Docker container. This container runs in the Mendix Cloud v4 (free tier) on the AWS (Amazon Web Services) cloud platform. The specifications are:

• 1 GB of memory
• 1 GB for file storage
• 0.5 GB maximum database size The application will go into sleep mode during inactivity and restart when it is used again. In practice, an app that is used frequently during the day will often go into sleep mode at night.

Differences between a free sandbox and a paid license

A paid environment for which you need to pay an annual license fee is called a licensed cloud node. Such a node is typically delivered with at least a production and acceptance environment, and often a test environment is also used for deploying applications easily.

Here are the 11 differences between a sandbox and a licensed cloud node:

Can you solve the limitations differently?

If you encounter real problems when using sandbox environments, you need to purchase a paid environment with a license. You can then choose to deploy your Mendix projects in the Mendix Cloud. You can also use your cloud environment if your license supports that option. Think, for example, of Azure, Google Cloud, SAP Cloud, and Pivotal. Mendix has Mendix for Private Cloud for this purpose, which uses a Kubernetes cluster (see Mendix for Private Cloud). As a developer, you have the same capabilities via the platform portal as those in the public Mendix Cloud. If you choose not to use this, keep in mind that you need to manage everything for the infrastructure, configuration, and maintenance of applications on these cloud platforms yourself.

Some limitations can sometimes be solved with a workaround, but these solutions are often not ideal. Consider the following problems and solutions:

No insight into the monitoring of graphs and information → Use Google Analytics widgets in your model. These widgets provide more information about the application's usage, showing, for example, the number of users and when these users log in.

No log files available from the last period the application ran → Use the logging module from the Mendix Appstore to write log messages to the database. This way, you build your own logging archive. Note that you have limited space in your database. You can also write these log messages externally via a REST interface to, for example, Datadog or a similar platform. You can also choose an alternative database.

No own domain name where the app runs → To hide the URL of the sandbox, you can register a domain or use a page on an existing domain where an iframe is visible with the URL of the sandbox (example code can be found here). You can then call the application via this own domain name. Iframes have limitations, for example, when the screen size of your app changes.

Advanced tip: If you use deep links, you need to consider that (pass the deep link to the iframe, for example, using JavaScript).

No advanced backup functionality → Regularly secure a backup by downloading it locally. For a sandbox, backups are kept for a maximum of 2 weeks. An even better option is to develop functionality for exporting and importing your data. In a sandbox, you can only restore a backup made by Mendix, and you cannot upload it yourself.

Want to store more than 1 GB of files → If you use an application that wants to store many files, consider using external cloud storage and integrating it via a REST API. Think, for example, of AWS S3 or Dropbox, solutions that offer a low price per GB.

No scheduled events → To trigger processes that you need to perform daily, you need to call your sandbox application from another cloud application. For example, data synchronization can still be done on a daily basis. Google Scheduler, AWS Cloudwatch, or the (CRM) application you are already using can solve this problem for you.

Can I run production applications in a sandbox?

Yes, you can. However, you must take into account the above (technical) limitations. Additionally, sandbox environments have a lower SLA and more limited uptime guarantees. Of course, Mendix Support is available if any issues arise in your environment. You can create a ticket for this.

Is this, possibly in combination with workarounds, sufficient for the requirements you have for the environment for your application? Then you can confidently use a sandbox for production applications!

In my experience, for small, non-mission or process-critical applications, a sandbox works fine, especially when not many users are using the application simultaneously. Since the introduction of sandbox environments, there are still apps that I use stably in a sandbox.

How do I deploy to a sandbox?

When you create a new application in the Mendix platform, the URL of your application is also determined. Note: this URL cannot be changed afterwards!

Your app is then available at the URL: https://<app-name-numberXXX-sandbox.mxapps.io. This URL is generated based on the name you used when creating your new app. After your first deployment, your app will be accessible via this URL.

To deploy a new version to a sandbox environment, click on 'Run' in the 'Run' menu. Note: your changes are immediately committed to the team server (SVN), and your version is overwritten on the sandbox cloud. When testing locally, make sure to choose the 'Run locally' option.

Can I have a production and test sandbox?

In the basic setup, this is not possible directly from one Mendix project. However, there is a workaround to create a test environment. This offers advantages if you want to test new features first before transferring them to the 'production' sandbox.

Unfortunately, some manual actions are always required. Follow the step-by-step plan below to create a test environment alongside your application:

• 1. Create a new blank project with the same name as your .mpr file as the existing application running in the 'production' sandbox.

Advanced tip: If you really want a different URL for your test environment, specify, for example, "SurveyBuilder-test" in the project name. Then rename the .mpr in this project via TortoiseSVN or SmartSVN to exactly the same name as your production app .mpr and commit this first before proceeding to step 4.

• Deploy this to the sandbox (see "How do I deploy to a sandbox").
• You now have a blank Mendix project with a sandbox that you can use as a test environment.

If you want to test the changes to your application first on the test environment, do the following:

Copy/paste all files from the directory of your production application, except .svn and .mendix-cache directories (if you don't see them, check View->Hidden items).

• You have now overwritten your blank test application with the Mendix model of your production application.
• Make your desired modifications now.
• If you deploy to your 'test application' now (see "How do I deploy to a sandbox"), you can test a few things.
• If the modifications are satisfactory, you can repeat the same copy/paste steps in your production application and eventually deploy to your 'production environment'. As I mentioned, creating a test environment in a sandbox requires a lot of manual work. In the paid version, this is, of course, all nicely automated.

Final tips

• When working with sandboxes, you sometimes need patience. The deployment process does not always proceed as quickly as in a licensed environment.
• You can use the debugger that you also use in your local environment.
• Make sure to create an administrator and user in the After Startup of your model if they are not already there.
• Ensure, as with Mendix apps running on a licensed node, that your security and access rules are in order.

I wish you a lot of fun using the Mendix sandbox. Experiment and learn! And if you have any questions, don't hesitate to contact us.

Want to know more?

There are plenty of opportunities to drive forward digital transformation in the tech industry. Would you like to improve the digital state of your organisation? And are you looking for a partner who can help you achieve this goal? In that case, Emixa is the right fit for you. We translate complex issues into simple, user-friendly IT solutions that accelerate your digital transformation and take your business to a higher level. Don’t hesitate to contact us. We would be delighted to meet you!