Local AI Apps Your Colleagues Can Rely On

T11-L03 · Run your own AI · Level 3 Builder · 21-minute read, plus 90 minutes of doing

When your laptop becomes the group's printer

In a lab it's Monday, 9:40. The group meeting starts in twenty minutes, and for three months it has opened with a one-page digest of the week's new papers. Mehmet, a technician, built it: an n8n workflow, a chain of automated steps, on his laptop runs the group's saved PubMed search, has a local model write three lines per abstract, and emails the page to everyone. This Monday nothing arrived. Mehmet is on holiday, his laptop installed an update over the weekend, and nobody else knows how the workflow runs. When he's back, he finds the container he started from a tutorial has gone, and with it every workflow he built.

In a company it happens on a Thursday. Petra runs the office of a fourteen-person engineering firm. She set up Open WebUI, a chat app that runs in the browser, with a local model and a small library of saved prompts for quote letters and supplier replies. Two colleagues now use the same setup on their own laptops. One of them "cleaned up" Podman, the program that runs these apps on his laptop, to free disk space, and his prompts and chats vanished.

Neither of them did anything unusual. They built something colleagues came to depend on, on a setup only they understood. This book gives you a way to run local AI apps that survives your holiday, an update and a colleague's clean-up.

You are at Level 3 Builder: colleagues depend on what you run. When it breaks, the group loses a result it counts on, and possibly the data behind it.

After this you can

• Install Heidelberg AI Desk and Podman Desktop, and get one reviewed app running on your own computer.
• Say what an app will download, where its data will live and what it needs from you, before you install it.
• Find an app's named volume, back it up to a file, and restore it on a second computer.
• Update an app without losing its data, and know the way back if the update goes wrong.
• Tell when a laptop setup has outgrown its place and the service belongs on a server.

Before you start

• Books: T11-L02 · A Local Model Your Tools Can Call. Your apps will use the LM Studio server you set up there. This book applies the four quadrants from T01-L01.
• A computer you may install software on: Windows 10 or 11 (64-bit), a Mac with an Apple chip, or Linux. On Windows you need administrator rights. The Desk installers are beta and not fully signed, so on a managed device ask IT first and show them this book.
• A second computer for the restore test, usually a colleague's. It needs Desk and Podman Desktop too.
• Memory and disk: Podman Desktop suggests 6 GB of RAM for its Linux machine on Windows, on top of what your model needs. Plan on 16 GB in total and 20 GB of free disk.
• About 2 hours: 21 minutes to read, 90 to do, plus downloads.

Last verified 23 September 2026. Heidelberg AI Desk is a free beta for Windows, Apple-chip Macs and Linux, not Intel Macs. Its installers aren't fully signed, so your computer may warn you. Podman Desktop is free but needs administrator rights on Windows. Details for experts at the end of this book.

The idea in one page

Heidelberg AI Desk is a launcher for reviewed local apps. You pick an app from its catalogue, Desk asks Podman to run it on your computer, and you open it in your browser through a local address. Desk has no model of its own. It runs apps, and the apps do the work.

Four words that change what you do. You don't need container theory. You need these four, because each one decides what survives:

Mehmet's tutorial container had no named volume. His workflows lived inside the container, so they went with it.

The lifecycle, from gentle to destructive. Desk's help page puts it in one table, and it's worth learning by heart:

Closing the browser tab or the Desk window doesn't stop anything. The app keeps running until you press Stop. And the cleanup commands that free disk space can delete named volumes: resetting the Podman machine (the small Linux system Podman runs in on Windows and Mac), or pruning volumes, which deletes every volume no container is using. That is what happened to Petra's colleague.

Ready means one check answered. When Desk shows an app as ready, its health check responded. That doesn't mean a model is connected, an account is set up or a workflow produced a correct result. You check those yourself, every time.

Persistence and backup are different things. A named volume survives a restart and a replaced container. It doesn't survive a deleted Podman machine, a dead disk or a stolen laptop. A backup is a separate copy, stored somewhere else. And until you've restored it once, you don't know that it works.

What "reviewed recipe" means. Each app in Desk comes as a recipe the Desk team has checked. It names a pinned version of the upstream app (the app as its own makers publish it), how it starts, its local route and where its durable data goes. Apps don't get the Podman control socket, so an app can't start or delete other containers. Reviewers look at the source, the exact downloaded file, permissions, persistence and platform notes.

What a review doesn't do: it doesn't make the app a security boundary, it doesn't stop the app from reaching the internet, and it doesn't replace your organisation's approval. The app still has its own login, its own model settings and its own behaviour. Pinning also cuts both ways. The version doesn't move under you, and it doesn't pick up upstream fixes until the recipe is updated.

Set up Desk and Podman

The downloads on ai.32dots.de still carry the product's old name: the files start with Heidelberg-AI-Lab, and the Mac app appears in Applications as Heidelberg AI Lab. They are the right files.

Windows

1. Install Podman Desktop from podman-desktop.io. Its onboarding offers WSL2 or Hyper-V, two built-in Windows ways to run Linux; pick WSL2 unless IT says otherwise. Let it install Podman and create a Podman machine.
2. Download the Windows installer from ai.32dots.de. Windows may warn about an unrecognised publisher.
3. Run it, keep the default location, and open Heidelberg AI Desk from the Start menu.
4. If Desk says Podman isn't ready, select Repair Podman in Desk.

macOS (Apple chip)

1. Install Podman Desktop from its .dmg and follow its onboarding to install Podman and create a Podman machine.
2. Open the Desk disk image and drag the app to Applications. macOS asks for explicit approval before it opens this beta.
3. If Desk says Podman isn't ready, select Repair Podman.

Linux

1. Install Node.js 20 or newer and Podman with your distribution's package manager.
2. Download the Desk package and install it with npm install --global ./Heidelberg-AI-Lab-<version>-Linux-any.tgz.
3. Start Desk with ai-lab.

Desk never installs system software by itself. When something is missing, it says what and waits for you. On Windows and macOS, choose the Podman connection you actually use if Desk asks.

Worked example: a digest that survives a holiday

Here is Mehmet's case after his holiday, through the four quadrants, then Petra's in brief.

Lab: the Monday paper digest

Structure it. "The group reads a one-page digest of the week's new papers every Monday at 9:30. It must arrive when I'm away, and when it fails, people must see that it's missing instead of reading last week's page."

Understand it. He looks at how the digest ran before. A docker run line copied from a tutorial started n8n with no named volume. The workflows, the saved email login and the run history all lived inside the container, and the laptop update replaced it. He still has an exported copy of the main workflow from May, because he once emailed it to himself.

He also asks the group what they actually use. Two people read the summaries. Everyone else scans the titles and clicks the links. Nobody has ever checked a summary against its abstract.

That changes his problem. Back to Structure it: "The digest must survive an update, my absence and a lost laptop. The workflow lives in a named volume, with a weekly backup on the group share that has been restored at least once. Anna can start it and knows what to do when it fails. Titles and links come straight from PubMed; the summaries are marked as model-written."

Choose tools. Down the ladder first. PubMed's own saved-search email already sends titles and links every week, and for most of the group that would be enough. The summaries are the part that saves the two readers time, so the automation stays, but the plain PubMed email becomes the fallback in the run note.

For running it, he compares his own container command with Desk's reviewed n8n recipe. Desk's recipe pins a version, keeps data in a named volume and gives him Start, Stop and Open that Anna can use without a terminal. The model stays LM Studio's local server from T11-L02, which n8n reaches at the address that book taught. Desk shows what the recipe needs before anything changes, and he reads it first: a download, a local route, and an account he'll create in n8n itself.

Build it. He installs n8n through Desk, presses Start, waits for ready, and presses Open. He creates his n8n account, imports the May workflow file, and re-enters the email login, because credentials never travel in an exported workflow. He runs it once by hand and compares three summaries with their abstracts. One summary says a mouse study "shows efficacy in patients". He tightens the prompt ("Summarise only what the abstract states. Name the organism or cell type.") and adds the line "Summaries written by a local model; read the abstract before citing" to the top of the page.

Then he finds the data. In a terminal he lists Podman's volumes and spots the one that belongs to n8n:

podman volume ls

He stops n8n in Desk, exports the volume to a file on the group share, and starts it again. On Friday afternoon, Anna installs Desk and n8n on her laptop, and before she starts n8n for the first time, they restore Mehmet's backup into it (the steps are below). She presses Start, logs in with Mehmet's n8n account, and the workflow is there. The test run fails at the summary step: her laptop has LM Studio, but not the model the workflow asks for. The backup holds the workflow, not the model. The run note gets a new line, "Before running: LM Studio's server is on and this exact model is loaded", with the model's name.

What it taught him: the workflow took an hour to rebuild; the restore test found the one thing that would have stopped Anna on a Monday morning. When he's away now, Anna runs the digest from her laptop.

Company: a prompt library three people share

Structure it. Petra: "Three of us use the same saved prompts for quote letters and supplier replies. If any laptop is wiped, we lose nothing we can't get back in ten minutes."

Understand it. She checks where things live. Each laptop runs its own Open WebUI from Desk, so each has its own volume with its own chats and its own copy of the prompts. Her colleague's clean-up deleted his Podman machine, and his volume with it. The chats don't matter much to anyone. The prompts matter a lot, and she is the only one who edits them. Back to Structure it: "The prompts need one master copy outside any app. Chats are personal and may be lost."

Choose tools. A text file of prompts on the shared drive would already cover the worst case. She keeps that as the master and adds a monthly volume backup of her own Open WebUI, so a wiped laptop comes back with its settings too. A shared Open WebUI on a server would remove the three copies, but it would also make her the operator of a team service. She notes that as the next step if a fourth person joins (T02-L04).

Build it. She puts the prompts in a document on the shared drive, dated, with one editor: her. She writes the lifecycle table from this book on a sticky note for both colleagues: Stop is fine, Remove is fine, resetting Podman is not. Then she restores her own backup onto the colleague's rebuilt laptop and checks that the prompts and the model connection come back.

What it taught her: most of the protection came from a document, not from containers.

In both cases, the app was the easy part. The work was in knowing where the data lives, what the result depends on, and who can start it when you're not there.

Back up a volume, and restore it

Do this in a terminal on the computer where Desk runs. On Windows and macOS, your volumes live inside the Podman machine, and these commands copy them out to a normal file for you.

Back up

1. In Desk, press Stop on the app. A copy taken while the app writes can be broken.

2. Find the volume's name. The app's name is usually part of it:

   Copy

   podman volume ls
   

3. Export it to a dated file:

   Copy

   podman volume export <volume-name> --output n8n-2026-09-23.tar
   

4. Press Start in Desk again, and check that the app opens.

5. Copy the file somewhere that won't be lost with the laptop: the group share, or your organisation's backup location. Treat it like the data inside it. A backup of an app that holds unpublished results is itself unpublished results.

Some apps also keep settings or keys outside their volume. Desk's help says to back up every declared volume together with the app's settings and any encryption keys. You find out whether you have everything in the only way that counts: by restoring.

Restore on a second computer

1. Install Desk and the same app on the second computer. Don't start the app yet.

2. Create an empty volume with exactly the same name, and import the backup into it:

   Copy

   podman volume create <volume-name>
   podman volume import <volume-name> n8n-2026-09-23.tar
   

3. In Desk, press Start, then Open. Log in with the account from the original computer.

4. Check the things that matter: your workflows, prompts or chats are there, a credential works, and one real run produces the result.

If Desk already created the volume on that computer, press Stop first, then import into it. Restoring into a volume the app has never used is cleaner, because nothing from a fresh start gets mixed into your data.

Never practise a restore on the original volume. If the backup turns out to be broken, you want the original untouched.

Update an app without losing it

Desk keeps four kinds of change separate: the launcher itself, an app's image, the recipe catalogue and the App Store display. None of them happens on its own.

• Updating Desk doesn't update, restart or remove your apps, images, models or volumes. Desk tells you when a new version exists and asks before it opens the download page.
• Updating an app is a separate, deliberate step. When a newer reviewed version of an app is available, the change happens only when you act on it.

A new app version can change the data in its volume the first time it starts, for example by upgrading its database. After that, the old version may not be able to read it. So swapping back to the old image won't get you back. A backup will.

Before any app update:

1. Write down the current version.
2. Stop the app and export its volume, as above.
3. Update, Start, Open, and do one real run.

If the update goes wrong:

1. Stop making changes and leave the original volume alone.
2. Look at the app's error message and its state in Desk.
3. Check that your backup file is readable.
4. Repair or restore on a second computer first.
5. Reset or overwrite the original only once the restored copy works.

When you've outgrown a laptop

A laptop is a good home for an app that one person runs and a few people depend on for a result. It stops being one when:

• People need the app itself, not just its result, from their own computers. Desk's local route reaches only your machine, and opening it to the network means accounts, encryption and a firewall.
• It must run when your laptop is closed, travelling or in for repair.
• The data needs server rules: nightly backups kept somewhere else, access limited to named people, logs someone reviews.
• More than one person must be able to fix it, at any time, without borrowing your laptop.

That's a server, and it's the next book: T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach. Securing it before anyone else can reach it is T12-L04. Owning an app that others depend on for years is T06-L05. Until then, don't make a laptop app reachable from the office network "just for a week". That week is how most exposed services start.

What goes wrong

Closing the window instead of stopping. Symptom: the battery drains and the fan runs, though you "closed" the app hours ago. Fix: the browser tab and the Desk window are only views. Press Stop on each app you're done with.

Taking ready for working. Symptom: Desk shows the app as ready, but it can't answer, or the Monday digest is empty. Fix: ready means the health check answered. Open the app and check the model connection, the account and one real run, in that order.

The empty screen after a restart. Symptom: you open the app and your workflows or chats are gone. Fix: don't reset or prune anything. Check that Desk and your terminal use the same Podman connection, and that the volume is still listed. A different connection shows different volumes. Restore from your backup only onto a second computer, until you understand what happened.

Cleaning up the wrong thing. Symptom: a colleague frees disk space by resetting the Podman machine or pruning volumes, and every app loses its data. Fix: put one line in the run note: "Never reset Podman or prune volumes on this computer. Ask first." And keep a backup that lives off the laptop.

A backup that was never restored. Symptom: the file exists, but on the day you need it the app won't start from it, or a password is missing. Fix: restore every new kind of backup once on a second computer, and again after each app update.

Updating on a Monday morning. Symptom: you accept an app update just before the result is due, and the new version needs a setting changed. Fix: update right after a run, never right before one, and export the volume first.

Docker Desktop and Podman side by side. Symptom: Desk can't find its engine, or apps appear and vanish depending on which tool you opened. Fix: Desk doesn't support Docker Desktop. Use Podman Desktop for Desk apps, and choose the right Podman connection if Desk asks.

Do it yourself (90 minutes)

Use one app from your own work. If you don't have one yet, install Open WebUI and connect it to your LM Studio server from T11-L02.

1. Structure it (10 min). Write one sentence: what result the app produces, who depends on it, by when, and what should happen when it fails. Name the person who can start it when you're away.
2. Understand it (20 min). Find where the result and its data live today. If you already run the app another way, find out whether it uses a named volume, and export what you can (for example, workflows as files). Ask the people who use the result which part they actually use. Rewrite your sentence if the answers changed it.
3. Choose tools (10 min). Go down the ladder: is there a simpler way to give people most of the result (a saved-search email, a shared document)? Keep it as the fallback. Then check Desk's catalogue for a reviewed recipe of the app, and read what it needs before you install.
4. Build it (50 min). Install Desk and Podman Desktop, then the app. Start, Open, set it up, and do one real run you check by hand. Stop it, export the volume, Start it again. Restore the backup on a second computer and check your data and one credential. Write the run note, and let the colleague you named follow it while you watch without helping.

Exit check

Delivered artifact: a one-page run note, plus a restore on a second computer.

The run note says, in plain words:

• What the app produces, for whom, and by when.
• How to start and stop it in Desk, and how to open it.
• Where its data lives (the volume name) and where the backups go, how often, and who makes them.
• How to restore it, including anything that doesn't travel in the backup, such as a password.
• When it fails: what people see, what the fallback is, and one line on what never to do (reset Podman, prune volumes).

The restore is your latest backup, brought back on a second computer, showing your real workflows, prompts or chats.

It passes when a colleague who didn't build it follows the note without your help, and the restored app shows your data and completes one real run.

Rule to remember

If you haven't restored it, you don't have a backup.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

Next books

• T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach: when colleagues need the app itself, not only its result.
• T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In: securing a self-hosted stack before anyone else can reach it.
• T06-L05 · Run the App Others Depend On, and Hand It Over: keeping something others depend on running for years.
• T02-L04 · A Self-Hosted Assistant Your Team Can Use Safely: Open WebUI for a whole team.
• T12-L03 · Give an Unattended Workflow Limits and a Stop a Colleague Can Use: what an automation may do on its own.

Tools

• Heidelberg AI Desk: Taught. Installs and runs the reviewed apps in this book.
• Podman: Taught. The container engine under Desk; Podman Desktop sets it up.
• n8n: Taught. The workflow app in the lab example.
• Open WebUI: Taught. The chat app in the company example.
• LM Studio: Taught. The local model server the apps call.
• PubMed: Catalogued. The saved-search email is the digest's fallback.
• Docker: Catalogued. The engine many tutorials assume; Desk uses Podman instead.