Deployment, Environments and Operations
Environments
A Mendix app typically runs in Development, Acceptance/Test and Production. Each environment has its own database, file storage, constants and admin account. Data does not travel with a deployment: the model is deployed and the database is migrated, but records created in Acceptance are not copied to Production.
Configuration per environment
Constants, custom runtime settings (heap size, scheduled-event toggles, log levels) and the application root URL are environment settings, not model settings. Keep secrets out of the model - use constants marked as secrets or the platform's environment variables. Disable scheduled events in environments that share external systems with Production.
Operations
Build a package from a committed revision, deploy it, then verify: application log for startup errors, the health endpoint, login, and one end-to-end business flow. Backups and restore are platform features - test a restore before you need it. Keep Production at Info log level and raise it only while diagnosing.
Worked example
A release adds a scheduled event that emails reminders. Deploy to Acceptance first, set the ReminderEnabled constant to false there, run the migration and verify the new table, then enable the event in Production only after the business confirms. Reasoning: otherwise the event emails real customers from a test environment using test data.
Traps
Assuming constants carry over (they are per environment); deploying a revision other than the one tested; leaving debug or trace logging on in Production; forgetting the admin password is per environment; running a data migration microflow twice without making it idempotent.