Skip to content

Environments

This page explains what environments are in ntkDeploy, how the environment sidebar works, and how environment context affects what you see when managing profiles and device groups. It also clarifies the important distinction between environments (a data-layer concept) and build flavors (a compile-time concept).

Prerequisites

What Environments Are

In ntkDeploy, an environment is a free-form text label you attach to a Profile to group it by lifecycle stage, department, or operational context. Environments are not fixed system values — you define them yourself.

Common conventions used by fleet administrators include:

Label Typical use
Development Experimental or work-in-progress profiles being actively edited
Staging Profiles validated internally and ready for pre-production testing
Production Approved, deployed configurations targeting live device fleets
Corporate-IT Department-scoped profiles for a specific team or business unit
Labs Profiles for test labs or canary device groups

You are not required to use these labels. The environment field accepts any non-empty string.

Where Environments Live

Each profile record stores its environment as a string field (for example "Production"). The environment sidebar reads all existing profile records and extracts the unique set of environment strings to build its list dynamically. An environment entry in the sidebar appears as soon as the first profile with that label is created, and disappears when the last profile using that label is deleted.

There is no global environment registry. Environments only exist as values on profile records. There is no separate screen to pre-define environments.

The Environment Sidebar

The environment sidebar is the collapsible panel on the left side of the Profiles screen. It provides fast filtering of the profile list by environment context.

Reading the sidebar

  • All Environments (the default) — shows every profile regardless of label. The counter beside each named environment shows how many profiles it contains.
  • Named environment row (e.g., Staging — 12 profiles) — clicking this row filters the profile list to show only profiles with that label. The row is highlighted and the folder icon changes to filled.
  • No environments yet — this placeholder message appears if no profiles have been created yet.

Switching the active environment

Click any environment row to set it as the active filter. Click All Environments to clear the filter and return to the full list.

The selected environment is a session-level UI state — it is not persisted across app restarts. The app always opens on All Environments.

Adding an environment

Click + Add Environment at the bottom of the sidebar. Enter a name in the dialog and press Add. The new environment row appears immediately in the sidebar and is selected. Profiles you create while this environment is selected will default to that label.

Note: Adding an environment via this dialog creates the sidebar entry in the current session only. The entry is anchored permanently once the first profile is saved with that label.

Renaming an environment

Hover over any environment row and click the ⋮ (more options) menu, then choose Rename. Renaming an environment updates the environment field on every profile that currently carries the old label. The sidebar and profile list both update immediately.

Caution: Renaming is immediate and affects all profiles in that environment. There is no undo. If you need to move a subset of profiles, edit those profiles individually and change their environment label manually.

Deleting an environment

Choose Delete from the ⋮ menu. If the environment contains profiles, a warning dialog states how many profiles will be permanently deleted along with the environment label. Deletion is irreversible.

How Environment Filtering Affects the App

Profile list filtering

When an environment is selected in the sidebar, the profile list shows only profiles with a matching environment value. Priority ordering, search, and all other list actions continue to work within the filtered view.

Profile creation defaults

When you create a new profile with an environment selected in the sidebar, the Environment field in the profile form is pre-filled with the selected environment label. You can change it before saving.

Device groups and deployments

Device groups are not filtered by environment. The Device Groups screen always shows all groups regardless of which environment is active in the sidebar. When you run the deployment wizard, you choose a profile (from any environment) and a device group independently.

This is by design: a single device group can receive configurations from different environments (for example, you may deploy a Staging profile to a test device group and a Production profile to a live fleet group).

Audit log

The audit log is not filtered by environment. It records all actions across all environments so you have a complete, unfiltered history.

Environments vs. Build Flavors

This is a common source of confusion for new administrators.

Concept What it is Who controls it When it matters
Environment (data label) A string field on a profile record You (the administrator) When organizing and filtering profiles at runtime
Build flavor A compile-time variant of the ntkDeploy executable The development team When the app is built and distributed

ntkDeploy ships in three build flavors — development, staging, and production — that differ only in app configuration baked in at compile time (such as app identifiers and diagnostic settings). All three flavors connect to the same local SQLite database and support the same full feature set.

You almost certainly run only the production flavor. The development and staging flavors are used by the engineering team during active development and testing. They are not related to the Development, Staging, or Production environment labels on your profiles.

Typical Fleet Workflow Using Environments

The following is a recommended workflow pattern. Adapt it to your organization's change management process.

1. Create profile in "Development"
   └─ Iterate on settings, use live JSON preview to validate

2. Promote to "Staging"
   └─ Clone the profile and change its environment label to Staging
   └─ Assign it to a staging device group (test lab)
   └─ Run preflight → deploy → verify ntkDrive picks up the config

3. Promote to "Production"
   └─ Clone the validated Staging profile and change label to Production
   └─ Assign it to the production device group
   └─ Run preflight → deploy → verify rollout events show success

4. Archive old versions
   └─ Older Profile Versions remain in history for audit purposes
   └─ Deactivate profiles no longer in use (do not delete if audit trail matters)

Because ntkDeploy stores data locally, this workflow happens within a single administrator's workstation. If your organization uses multiple administrators, coordinate profile promotions through your normal change management process (for example, export the profile JSON and import it on the destination workstation).

Next Steps