ssh
How to Keep Your App Running 24/7 After You Log Out
Learn why apps stop when an SSH session closes, and which safer options keep them running on your server.
You finally got your app running, then you closed your laptop — and the site went dark.
Short version: to keep an app running after closing SSH, you need something on the server to own and restart the app when your login session ends. For quick tests, tools like tmux or screen can help; for a real website or API, use a process manager such as systemd, PM2, or a container setup that starts automatically after reboot.
Why does your app stop when you close SSH?
SSH, short for Secure Shell, is your remote doorway into the server. When you type a start command inside that doorway, the app often becomes a child of that login session.
Think of it like plugging a lamp into an extension cord you are holding. As long as you stay connected, the lamp has power. When you leave and take the cord with you, the lamp turns off.
That is why a Node.js app, Python script, Rails server, or development server may run fine while your terminal is open, then disappear after logout. The server is not being cruel. It is cleaning up the programs that belonged to your session.
You may see this problem described as “keep app running after closing ssh,” “app stops after logout,” or “process killed when terminal closes.” Under the hood, the app may receive a signal called SIGHUP, which means the controlling terminal went away.
What keeps an app running after closing SSH?
The fix is to give the app a proper caretaker.
A caretaker is a program that runs on the server itself and does not depend on your open terminal. It starts your app, keeps track of it, and can bring it back after a crash or reboot.
There are two different needs people often mix together:
First, you may only want to keep something alive while you test. In that case, a terminal multiplexer like tmux or screen is like leaving your desk setup in a locked room. You can disconnect and come back later.
Second, you may want a public app to stay online all week. That needs a more permanent arrangement. A service manager such as systemd, a Node.js process manager such as PM2, or a Docker-based setup is closer to putting your app on the building’s electrical panel instead of a loose extension cord.
If you are still getting comfortable with the bigger deployment picture, start with the plain-English path in deploy a small web app without DevOps.
Which option should you use: tmux, systemd, PM2, or Docker?
There is no single magic tool. The right choice depends on whether you are experimenting, running one app, or managing several moving parts.
| Option | Best for | What it solves | What it does not solve |
|---|---|---|---|
| tmux or screen | Quick tests and long-running manual tasks | Keeps a terminal session alive after you disconnect | Not a clean production setup for a public app |
| nohup | Simple one-off background runs | Lets a command ignore terminal hangups | Easy to lose track of later |
| systemd | Most long-running apps on Linux servers | Starts on boot, restarts on failure, keeps logs in one place | Takes care to name and organize clearly |
| PM2 | Node.js apps | Keeps Node processes alive and restarts them | Mostly focused on the Node ecosystem |
| Docker | Apps packaged with their environment | Makes the app and its dependencies more repeatable | Adds another layer to understand |
For a real website, tmux is usually not enough. It is useful when you are testing, migrating data, or watching a temporary task. But if customers, clients, or teammates depend on the app, you want it to survive a closed laptop, a dropped internet connection, and a server reboot.
Docker can be a good fit when your app has several pieces, such as a web service, database, and background worker. If you are unsure whether that extra layer helps or just adds clutter, read Docker on a server for beginners.
FAQ
Can I just leave my laptop open? You can, but it is fragile. Your app should not depend on your laptop, home internet, or an open SSH window.
Is tmux safe for production? It is fine for temporary work, but it is not the best home for a public app. Production apps need clear ownership, restart behavior, and logs.
What happens if the server reboots? A proper service setup can start the app again automatically. A plain terminal session usually will not.
**Why did nohup not fix everything?** nohup can keep a process from dying when SSH closes, but it does not make the setup easy to inspect, restart, or understand months later.
Where do I look when the app still stops? Start with the app logs and the service logs. If logs feel like a wall of noise, this guide to reading server logs when something breaks will help.
The shortcut
Server Manager helps by making the app’s “caretaker” visible instead of hidden in a half-remembered terminal command. The outcome is simple: your app is not tied to an SSH tab, so closing your laptop does not quietly take the site down.
It also reduces the common mess that appears later: a process started with nohup that nobody can find, a tmux session named something vague, or a service that restarts differently after a reboot than it did on launch day. The real benefit is that the setup stays legible over time, so you can come back months later and still understand what is running and why.
That matters when you have more than one app, a background worker, or a database beside the website. One project should not accidentally break another, and your uptime should not depend on remembering the exact ritual you used the first night.
What you win
Keeping an app online after logout is not about one clever command. It is about moving from “my app is running because my terminal is open” to “my app is running because the server knows it should be running.”
Once that is true, closing SSH becomes boring. Your laptop can sleep, your connection can drop, and your app can keep doing its job.