> ## Documentation Index
> Fetch the complete documentation index at: https://platform.atlan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Manage updates

> Control how and when the Atlan desktop app updates on managed devices.

By default the app checks for updates automatically and applies them when the
user is idle, with a randomized delay so a fleet never restarts in unison.
On managed devices you decide who owns updates: the app, or your MDM.

## Option 1: the app updates itself, you set the pace

Set a deferral policy through managed preferences and the app will not
download updates more often than your cadence allows.

| Key                  | Domain                | Type    | Values |
| -------------------- | --------------------- | ------- | ------ |
| `UpdateDeferralDays` | `com.atlan.dashboard` | Integer | 1-30   |

Deploy it as a managed preference through your MDM. Common choices: `7`
(weekly), `21` (every three weeks), `30` (monthly). Absent means fully
automatic.

When the policy is active:

* The app makes no update downloads between cadence windows.
* The in-app update control is disabled, with a note that updates are
  managed by the organization. Users cannot override the policy - the app
  honours the key only when it arrives through MDM, not when planted
  locally.

<Note>
  **Security releases are the one disclosed exception.** If Atlan flags a
  release as a required security floor, a device inside a deferral window
  shows a persistent in-app warning naming the required version. The app
  never blocks or locks itself on a managed device - the warning is the
  escalation, and your MDM can push the update on your own terms.
</Note>

## Option 2: your MDM owns updates

Push each new `.pkg` on your schedule; it installs over the existing version
in place. Set a long deferral (`30`) so the app's own updater stays out of
the way. When the updater wakes and finds the machine current, it does
nothing.

## Inventory detection

The app self-updates by design, so exact-version detection drifts: you deploy
1.2.0, the console still says 1.2.0, and machines are actually on 1.4.1.
Write detection as **deployed version or newer**:

```sh theme={null}
installed="$(defaults read /Applications/Atlan.app/Contents/Info.plist CFBundleShortVersionString)"
```

Compare with a version-aware check, not string equality.

## Non-admin users

An MDM-pushed `.pkg` installs to `/Applications` owned by root. If your users
are standard users, the app's self-update cannot overwrite the bundle and
prompts for administrator credentials on every attempt.

If you chose Option 1 (self-updating), run this once per device as a
post-install script, as root, after a user session exists:

```sh theme={null}
#!/usr/bin/env bash
# Hand ownership of the app bundle to the console user so self-update works
# without administrator rights.
set -euo pipefail

APP="/Applications/Atlan.app"

if [ "$(id -u)" -ne 0 ]; then
  echo "must run as root" >&2
  exit 2
fi
if [ ! -d "$APP" ]; then
  echo "app bundle not found at $APP" >&2
  exit 2
fi

CONSOLE_USER="$(stat -f %Su /dev/console)"
if [ -z "$CONSOLE_USER" ] || [ "$CONSOLE_USER" = "root" ]; then
  echo "no console user logged in - run after a user session exists" >&2
  exit 1
fi

chown -R "$CONSOLE_USER:$(id -gn "$CONSOLE_USER")" "$APP"
echo "OK - $APP now owned by $CONSOLE_USER"
```

If you chose Option 2 (MDM-pushed), skip the script - your MDM installs as
the system and ownership never matters.

## The sync runtime updates separately

The background sync runtime installs into each user's own folder, needs no
administrator rights, and keeps itself current independently of the app.
None of the policies on this page affect it.