---
# source: src/content/solutions/en/igel/igel-app-portal.md
# route:  /en/solutions/igel/igel-app-portal/
title: App Portal
tags: [modern-workplace, automation]
vendors: [igel]
summary: IGEL OS 12 ships with no applications. Everything a person uses arrives from here as a package, and updates without touching the operating system.
photoNeed: "An IGEL endpoint in place: a UD Pocket in a laptop, or a thin client at a working desk"
stub: false
draft: false
kind: product
addon: false
sourceNote: soultec.ch/solutions/igel, read 2026-08-30; igel.com product navigation, same day
vendorName: IGEL App Portal
status: current
---

## What it is

The App Portal is where the applications come from. IGEL OS 12's base image deliberately
contains none, so the Citrix client, the Omnissa Horizon client, the Azure Virtual Desktop
client and the browsers are all selected in the portal and pushed to devices or device
groups from there.

It is part of the IGEL cloud services rather than something you install.

## Why the split matters

Applications are delivered as containers, managed apart from the operating system. So a
client update is a package update, not an OS release, and the two stop being scheduled
against each other.

That is the actual argument for IGEL OS 12 over 11 in an estate where the VDI client
version is dictated by someone else's upgrade calendar.

## What to watch

An estate with no route to the internet does not reach the portal. IGEL's answer is the
distributed app repository, where devices pull packages from a local server instead, and
that is an Enterprise-licence feature. There is also peer update, where a device pulls from
another device on the same network, and that one is in every edition.

Which of the two you need is an air-gap question, and it belongs in the design.