# How can I keep an application running after I disconnect from SSH?
Source: https://vpsdime.com/knowledgebase/technical-questions/keep-apps-running-after-ssh
Last reviewed: 2026-07-02
Summary: Why your program dies when the SSH session ends (it's the terminal's child), and the three answers by situation, tmux for interactive things you'll come back to, a systemd service for anything that should always run, and nohup for the quick fire-and-forget, plus recovering a job you started without any of them.

## What this is

You start something over SSH, a long build, a download, a game server, and when the connection drops (or you close the laptop), it dies. That's by design: processes you start belong to your login session, and the session's end sends them a hangup. Three tools fix it; pick by what the thing *is*.

## tmux: for interactive work you'll return to

The right default for humans. **tmux** gives you a terminal session that lives on the server, detached from your SSH connection:

```
apt install tmux
tmux            # start a session, run your stuff inside it
```

Detach with **Ctrl+B then D** (or just let SSH drop, same effect), reconnect any time from anywhere:

```
tmux attach
```

and your program is exactly where you left it, output history included. Multiple sessions: `tmux new -s build`, `tmux ls`, `tmux attach -t build`. This is why every long-running command in this knowledge base ([migrations](https://vpsdime.com/knowledgebase/getting-started/migrating-a-vps), big transfers) says "run it in tmux". (`screen` is the older equivalent, fine if it's what your hands know.)

## systemd: for anything that should *always* run

If the answer to "should this still be running next month?" is yes, a game server, an app, a bot, it isn't a terminal job at all, it's a **service**: a ten-line unit file gets it starting at boot, restarting on crash, and logging to the journal, [the same recipe as the timers guide](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers), and the difference between a program that survives your disconnect and one that survives [a reboot](https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot). An [AI chatbot](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management) drafts the unit from "write a systemd service for <command> as <user>".

## nohup: the quick fire-and-forget

For a one-shot command you just want to outlive the session, no reconnecting needed:

```
nohup ./long-job.sh > job.log 2>&1 &
```

It ignores the hangup, runs in the background, and writes output to the log you pointed it at. No way to reattach, that's tmux's job, but nothing to install.

## "I already started it without any of these"

A running job in your current session can still be saved: **Ctrl+Z** to suspend it, `bg` to resume it in the background, then `disown -h %1` detaches it from the session's hangup. Cruder than starting in tmux, but it rescues the three-hour job you forgot to protect. (The `fg`/`bg`/jobs machinery has [its own section in the process guide](https://vpsdime.com/knowledgebase/technical-questions/process-management).)

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-ticket/). So we can help on the first reply, it's worth mentioning:

- the VPS hostname or IP,
- the program you're keeping alive, and the approach you tried (tmux, systemd, nohup).

## Related questions

- "Why does my program stop when I close SSH?"
- "How do I use tmux to keep something running?"
- "Should I use tmux, nohup, or a systemd service?"
- "How do I save a running job I started without tmux?"