Can you use a MacBook as a server with the lid closed?
You have a fast MacBook and something that needs to keep serving requests — a local API, an Ollama endpoint, a webhook listener. Close the lid and macOS suspends everything on it. By default, a sleeping Mac does not answer HTTP requests, so the real question of using a MacBook as a server with the lid closed is how to keep the system awake while something listens on a port.
Running a local dev server on a closed MacBook
A MacBook can serve local HTTP traffic, LLM inference requests, and reverse-tunnel connections while the lid is closed. Flask, FastAPI, Next.js, a local Ollama endpoint, or an ngrok tunnel all work at the process level. The hardware is capable. The limitation is macOS, not the chip.
By default, closing the lid puts the system to sleep and suspends every process with it — including the server you left listening on a port. The client on the other end sees a connection timeout. The server did not crash; it is just paused until you open the lid again.
Holding the system awake through a lid close requires an IOKit power assertion. That is the same mechanism used for builds and long agent runs. Once the assertion is held, the server process keeps running and responding normally, the same as if the lid were open.
What works well and what is out of scope
For developer use, the range of server-style tasks that work well is broad. Local HTTP APIs, webhook listeners, small FastAPI or Flask dev servers, Ollama inference endpoints, and reverse tunnels via ngrok or cloudflared all run reliably on a closed MacBook as long as the system stays awake. These are the workloads this setup is built for.
Production traffic is a different story. A MacBook has no redundancy, no hot-swap storage, and a finite battery. A sleep event, a low-battery floor, or a system update can take the service offline. For occasional development sessions that is a manageable tradeoff. For external users or anything business-critical, it is not.
The honest framing: this is a dev workstation doubling as a local server for a session, not a server running production services. That scope makes it genuinely useful — testing webhooks from an external service, serving a local LLM to other devices on your network, or keeping a dev API accessible while you step away from your desk.
Related guideKeep a MacBook running with the lid closedKeeping the Mac alive while serving requests
With a power assertion held, the server keeps running through a lid close. LidRun holds that assertion for the duration of a session and watches battery and thermal state while it does. The session ends when a threshold is reached or the timer expires — not when macOS decides to sleep.
Set a session timer that matches how long you actually need the server up. Without a cap, a server you forgot about stays awake until the battery runs out. A one-, three-, or eight-hour limit means a hung or abandoned process cannot hold the Mac awake indefinitely.
The activity log records why each session ended — timer expiry, a battery threshold, or a manual stop. That matters when you check in the morning and want to know whether the server ran the full overnight window or cut off at 2 am. For more on how the keep-running mode works, see the guide on keeping a MacBook running with the lid closed.
Safety limits for server-style use on a laptop
Server-style use tends to be sustained load, and sustained load means the thermal picture matters more than in a short build. A closed lid retains more heat than an open one. Keep the Mac on a hard, flat surface with clearance underneath — not on a bed, a couch, or anywhere airflow is blocked. Never in a bag.
Plug in for anything more than a short session. A dev server handling network I/O and running inference draws more power than an idle machine, and a low-battery auto-stop mid-session is an annoying interruption. Battery life is not the bottleneck you want to discover halfway through an overnight test run.
Set a battery floor even when plugged in. A power outage or accidental unplug can happen, and the floor means the Mac sleeps cleanly at a safe charge level rather than draining completely before the session ends.
A feature of LidRun for closed-lid Mac.
LidRun keeps your work running with the lid closed, with battery and thermal safety built in.
Frequently asked
Yes, with a keep-awake tool holding a power assertion. HTTP servers, LLM endpoints, and reverse tunnels continue responding normally through a lid close. Without that assertion, macOS sleeps the machine and suspends any process listening on a port.
It can be, with the right setup. Ollama draws real CPU and GPU load, so thermal pressure can climb during sustained inference. Running on a hard, ventilated surface while plugged in, with a battery floor and thermal watch active, helps reduce risk. Leaving it in a bag or unmonitored overnight on battery is where problems tend to happen.
Plug in, start the server, enable keep-running mode in LidRun, then close the lid. Set a session timer that matches the window you need — it ensures a hung or forgotten process does not hold the Mac awake past its time. Battery and thermal thresholds auto-stop the session if conditions go out of range while you sleep.
The main ones are thermal buildup with the lid closed, battery drain if left unplugged, and no redundancy if the Mac sleeps or a threshold cuts the session. For occasional dev sessions these are manageable with the right setup. For production traffic serving external users they are not acceptable — that work belongs on dedicated server hardware.