Applications and environments

Configure what you run and where it runs once. Simplr reuses this map for monitoring, feature flags, releases, automation, investigation evidence, and deployment verification.

Open Dashboard → Workspace → Applications.

Add environments

Create environments before assigning applications:

1. Open the Environments tab and select Add environment.
2. Enter the name and stable key, such as Development and dev.
3. Choose the safety tier and whether its data is test or live.
4. Optionally add branch patterns, aliases, a deployment provider, and a verification window.
5. For non-production environments, enable bounded auto-deploy only when the configured workflow requires no additional input.

Production can have a deployment target, but Simplr never enables autonomous production deployment. Environment keys stay fixed after creation so existing telemetry and release mappings remain valid.

Add applications

Open the Applications tab and select Add application:

1. Enter a clear name and choose Web, iOS, Android, API, Worker, Service, or Other.
2. Set the application ID used by the SDK or telemetry producer.
3. Select only the environments where this application runs.
4. Add the repository, owning team, description, or older application-ID aliases only when needed.

Use a separate application for each independently operated or deployed system. For example, one environment can contain customer-web, customer-ios, and checkout-api. The application ID stays fixed after creation; archive an application when it is no longer operated. Archiving stops application-scoped rules, new runs, and external work, and disables application-scoped connections. Restore the application, then explicitly review and re-enable only the connections it still needs.

Other setup journeys

The same editors appear in first-time Setup, Automate, and Feature Flags. Changes made in any of those locations update the shared catalogue immediately; there is no second application or environment list to maintain.

Deleting a non-system environment removes its feature-flag deployments and release mapping rules, revokes environment-scoped agent access, removes automation and work mappings, and unassigns it from applications. A rule or connection is disabled if the deleted environment was its final scope, so deletion can never broaden restricted access. Historical releases, test credentials, verification runs, and workstation campaigns block deletion until they are reassigned or removed. Review that impact before confirming deletion.