About Instances
An instance is an isolated environment beneath a Client, such as Production, Development, or Test. It's named using the client's naming convention plus an environment suffix, e.g. company-name for production and company-name-dev for development, which carries through to the URL used to access it: company-name.modlr.cloud.
Instances are single-tenanted: there is no overlap of customer data between them, even across instances belonging to the same client.
Instance Components
| Component | Description |
|---|---|
| Model | The configuration layer containing the cubes, dimensions, elements, mappings, processes, and applications that make up a MODLR solution. An instance can hold multiple models. |
| Security | An instance-level framework governing read, write, or no access to model components: models, cubes, dimensions, elements, cards, and workviews. |
| Internal Datastore | A MySQL database used as the instance's internal data store, for reporting or data processing via cards, custom pages, or processes. |
| Thin (Customer Frontend) | The customer-branded web application through which Applications, Screens, and their content are served to end users. |
Server time
All MODLR servers run on UTC +0000, regardless of where the instance is hosted or where its users are.
This matters wherever a time is entered or produced. A Schedule set to run at 02:00 runs at 2am UTC, not 2am local, and that offset shifts relative to local time across daylight saving transitions. The same applies to dates a Process derives from the JavaScript Date object, and to timestamps written into Table audit fields.
Where local time matters to the business logic, convert explicitly within the Process rather than assuming the server's clock matches the user's.
See MODLR Architecture for how an instance fits into the wider object hierarchy.