# Process (/academy/process)



The MP3 on disk is silent. Hit play and you have a **process**.

Same bits. One of them is alive. It has an id, a slice of RAM, a slice of CPU. Close the player, the process dies. The file is still there. You can start a new performance whenever you want. Two players can open the same file. That is two processes.

`bun run dev` is you hitting play on the app. The [runtime](/academy/runtime) sits down and starts a process. Kill the terminal — or close the lid — and [localhost](/academy/localhost) goes dark. You did not delete the repo. You ended this particular living copy.

**Why the todo list evaporates**

RAM belongs to the process. In-memory [state](/academy/state) is a note taped to the performer. Restart, new performer, empty pockets. The [database](/academy/database) is how truth outlives any one run. If you "fixed" a bug by restarting and the bug is gone, you probably hid state in RAM.

A [daemon](/academy/daemon) is a process that keeps playing after you leave the room. On a laptop you usually just leave the terminal open. On a [server](/academy/server), logout should not be an encore that kills the show.

Activity Monitor / `ps` is the list of who is currently on stage. When the laptop fans up during a demo, you are not asking "what files do I have." You are asking which processes are eating the room.

An [agent](/academy/agent) is the same split. The system prompt is the file. The running agent is a process. Stop the process and the agent is gone, even if the instructions still exist. create-hackhaton-space-stack gives you scripts that start processes. You give them a cabinet so the next performance still knows the plot.

**What this unlocks**

"Kill it and start it again" stops sounding violent. You are ending a performance, not shredding the score. The [CLI](/academy/cli) `dev` command is one living copy. [Deploy](/academy/deploy) is another, on a machine that does not close its lid.

The file is the song. The process is the night it is playing.