---
url: /technical/about-instances.md
description: >-
  An instance is an isolated MODLR environment beneath a Client, such as
  Production, Development, or Test.
---

# About Instances

An instance is an isolated environment beneath a [Client](/technical/modlr-architecture#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](/technical/scheduling-processes) 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](/technical/tables) 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](/technical/modlr-architecture) for how an instance fits into the wider object hierarchy.
