Ketika Server Tidak Pernah Tidur: Catatan Praktis Menghidupkan Layanan Web Tanpa Login di Windows

Ketika Server Tidak Pernah Tidur: Catatan Praktis Menghidupkan Layanan Web Tanpa Login di Windows

Ada momen ketika semua indikator tampak hijau—service berjalan, tunnel terhubung—namun domain publik justru menolak melayani; di titik ini, kita belajar bahwa hidupnya proses belum tentu hidupnya layanan.

Jam tiga pagi. Laptop tua itu—sekarang berperan sebagai server sementara—berdengung pelan di sudut ruang kerja. Layarnya hitam, dalam mode sleep. Atau begitulah kelihatannya. Saya buka remote desktop. Masuk. Semuanya tampak normal. Service Apache “Running”. Ngrok tunnel “Active”. Tapi coba akses dari luar? Timeout. Halaman putih yang kosong, seperti tatapan bingung. Di dalam, segalanya berjalan. Di luar, segalanya mati. Ini bukan kegagalan, ini pengkhianatan. Sistem berbohong dengan tenang, dengan indikator hijau sebagai senyum palsunya.

Windows punya cara tersendiri untuk memahami “hidup”. Bagi manusia, hidup itu bernafas, berinteraksi, merespon. Bagi Windows Service Manager, hidup itu status: “Running”. Titik. Dia tidak peduli apakah service yang sedang “Running” itu benar-benar mendengarkan di port yang dituju, atau apakah dia sudah kebingungan mencari konfigurasi yang hanya ada di environment user tertentu. Dia seperti penjaga toko yang membuka pintu pagi-pagi benar, lalu berdiri di belakang konter sambil tidur berdiri. Pintu terbuka? Iya. Toko buka? Secara teknis, iya. Tapi bisa dilayani? Jangan tanya.

Masalahnya berlapis, seperti bawang yang membuatmu menangis. Lapisan pertama: service memang bisa berjalan tanpa user login. Itu janjinya. Tapi ada yang namanya “session 0”. Sebuah ruang hampa di mana service itu berjalan, terpisah dari dunia desktop, dari drive mapping, dari registry user HKCU yang mungkin menjadi rumah konfigurasi kritis sebuah aplikasi. Service Anda bisa “Running” dengan gagah di session 0, sementara aplikasi di dalamnya merengek karena tidak menemukan file .env yang selalu ada di `C:\Users\Production\`. Itu kesedihan pertama.

Lapisan kedua: tunnel. Ngrok, Cloudflare Tunnel, sejenisnya. Mereka seringkali bukan service murni. Mereka adalah aplikasi console yang dirancang untuk berjalan di… well, console. Dalam sebuah session. Dengan window (walau tersembunyi) dan context seorang user. Ketika tidak ada user yang login, mereka kehilangan pijakan. Mereka bisa saja dijalankan oleh Task Scheduler saat boot, tapi Task Scheduler pun punya setingan “Run whether user is logged on or not” yang licik. Centang itu, dan proses akan berjalan—tapi di balik layar, tanpa akses ke jaringan? Terkadang iya, terkadang tidak. Seperti melempar burung ke dalam sangkar tertutup dan menyebutnya “terbang”.

Saya terjebak dalam siklus: reboot, login manual, jalankan tunnel, logout—dan lihat tunnel itu bertahan. Untuk sementara. Sampai Windows memutuskan untuk melakukan maintenance, atau sampai ada update yang membutuhkan restart, atau sampai listrik kedip sebentar. Lalu, kembali ke titik nol. Server tidak tidur, tapi layanannya pingsan. Ini kerja sunyi yang salah arah: sistem diam-diam mati, bukan diam-diam hidup.

Konfliknya di sini menarik. Di satu sisi, kita ingin otomatisasi penuh, elegan, “set and forget”. Di sisi lain, Windows—dengan warisan desainnya sebagai sistem operasi desktop—selalu menyisakan pintu belakang untuk interaksi manusia. Security vs Convenience. Automation vs Session Context. Kita berusaha memaksa Windows menjadi server yang anggun, sementara jiwanya tetap jiwa PC yang menunggu input dari mouse dan keyboard.

Solusi berbau rekayasa sosial. Bukan melawan arsitektur Windows, tapi mengakali nafasnya. Pertama, kita akui bahwa beberapa hal memang butuh session. Butuh konteks user. Maka, buatlah sebuah user khusus, sebut saja “runner”. User ini tidak pernah login secara fisik, tapi kita beri hak untuk “log on as a service” dan “log on as a batch job”. Itu seperti memberinya kewarganegaraan di dunia session 0.

Kedua, tentang aplikasi console yang manja itu. Kita buat batch file sederhana. Isinya tidak muluk-muluk:

@echo off
cd "C:\Program Files\ngrok"
start /B ngrok.exe http 80

Simpan sebagai `start_tunnel.bat`. Lalu, senjata rahasia: Task Scheduler. Buat task baru. Trigger: “At startup”. Action: jalankan batch file tadi. Tapi di silahkan sakralnya: di tab General, centang “Run whether user is logged on or not”. Dan masukkan kredensial user “runner” tadi. Lalu, di tab Settings, pastikan “Run task as soon as possible after a scheduled start is missed” dicentang. Ini jaminan: setelah reboot apapun, task ini akan bangkit.

Tapi tunggu. Masih ada jebakan. “Start /B” itu memulai proses sebagai child dari batch file. Ketika batch file selesai, anaknya bisa saja dianggap yatim dan dimatikan. Solusi bodoh sekaligus jenius? Gunakan aplikasi lain yang tugasnya hanya menjaga. Sebuah “watcher” kecil. Atau, struktur batch file yang menjebak dirinya sendiri dalam loop tanpa akhir:

:loop
ngrok http 80
timeout /t 10
goto loop

Jika tunnel crash, dia akan restart dalam 10 detik. Ini tidak elegan. Ini seperti menambal ban bocor dengan permen karet. Tapi bekerja. Dan dalam kerja sunyi sistem, “bekerja” seringkali lebih mulia daripada “elegan”.

Lalu ada lapisan ketiga: dependency. Service web (Apache, Nginx) harus jalan duluan sebelum tunnel mencoba menerobos. Maka di Task Scheduler, kita atur delay. Jalankan task service web dulu, tunggu 30 detik, baru jalankan task tunnel. Ini adalah orkestrasi primitif. Sebuah simfoni yang dimainkan dengan kode bat yang berantakan, bukan dengan alat monitoring yang mahal.

Setelah semua terpasang, ujiannya adalah momen paling sunyi: reboot dingin. Matikan listrik virtual mesin itu. Tunggu. Hidupkan. Jangan login. Lalu, dari ponsel di jaringan yang berbeda, akses domain publik. Dan… halaman utama terbuka. Perlahan, mungkin. Tapi terbuka. Tidak ada yang melihat proses boot-nya. Tidak ada yang melihat task scheduler menjalankan ritualnya. Tidak ada yang melihat batch file berputar dalam loopnya. Yang ada hanyalah seorang pengguna yang mendapatkan halaman web, seperti seharusnya. Dia tidak tahu—dan tidak perlu tahu—bahwa di balik layar, Windows sedang bernafas dengan susah payah dalam session yang tak terlihat, dikendalikan oleh skrip-skrip yang jujur pada ketidakanggunannya sendiri.

Ada pelajaran filosofis di sini, di antara baris kode bat dan checkbox Task Scheduler. Kerja sunyi yang sejati seringkali lahir dari pengakuan akan keterbatasan, bukan dari ilusi kontrol penuh. Kita ingin segalanya otomatis dan terisolasi dengan sempurna, tapi realitas Windows (dan mungkin realitas apa pun) adalah tentang konteks, dependency, dan urutan. Memaksakan kesempurnaan justru mengantar pada kegagalan yang sunyi. Menerima kerumitan, lalu merangkai solusi yang mengakui kerumitan itu—itulah yang menciptakan keandalan.

Kita jadi belajar membaca “hidup” dengan cara yang berbeda. Bukan dari status “Running” yang dingin, tapi dari bukti pelayanan. Sebuah ping yang membalas adalah hal. Sebuah halaman web yang terlantar adalah hal lain. Yang pertama adalah tanda kehidupan vegetatif. Yang kedua adalah tanda kehidupan sosial—sebuah sistem yang benar-benar berinteraksi dengan dunia luar.

Bab ini menegaskan bahwa kerja sunyi sistem bukan tentang membuat segalanya tampak aktif, melainkan memastikan setiap lapisan benar-benar bekerja; sering kali, jalan paling andal lahir dari solusi yang jujur pada cara Windows dan layanannya bernafas.

The Sleepless Server: A Practical Guide to Auto-Starting Web Services on Windows

There comes a moment when all indicators are green—the service is running, the tunnel is connected—yet the public domain refuses to serve; at this point, we learn that a running process does not guarantee a living service.

Three in the morning. The old laptop—now serving as a temporary server—hummed softly in the corner of the workspace. Its screen was black, asleep. Or so it seemed. I opened a remote desktop connection. Logged in. Everything looked normal. Apache service: “Running”. Ngrok tunnel: “Active”. But try accessing it from the outside? Timeout. A blank white page, like a confused stare. Inside, everything was running. Outside, everything was dead. This wasn't a failure; it was a betrayal. The system was lying quietly, with green indicators as its fake smile.

Windows has its own way of understanding “alive”. For humans, being alive is breathing, interacting, responding. For the Windows Service Manager, being alive is a status: “Running”. Period. It doesn't care if the “Running” service is actually listening on the intended port, or if it’s confusedly searching for configuration that only exists in a specific user’s environment. It’s like a shopkeeper who opens the door early in the morning, then stands behind the counter sleeping on his feet. Door open? Yes. Shop open? Technically, yes. But can you get service? Don’t ask.

The problem is layered, like an onion that makes you cry. The first layer: a service *can* run without a user login. That’s the promise. But there’s this thing called “session 0”. A vacuum where the service runs, isolated from the desktop world, from drive mappings, from the HKCU user registry that might house an application’s critical configuration. Your service can be “Running” valiantly in session 0, while the application inside it whimpers because it can’t find the .env file that always lives in `C:\Users\Production\`. That’s the first sorrow.

The second layer: tunnels. Ngrok, Cloudflare Tunnel, their ilk. They are often not pure services. They are console applications designed to run in… well, a console. In a session. With a window (albeit hidden) and a user context. When no user is logged on, they lose their footing. They can be launched by the Task Scheduler at boot, but the Task Scheduler also has a tricky setting: “Run whether user is logged on or not”. Check that, and the process will run—but behind the scenes, without network access? Sometimes yes, sometimes no. It’s like throwing a bird into a closed cage and calling it “flying”.

I was stuck in a cycle: reboot, manual login, start the tunnel, log out—and watch the tunnel survive. For a while. Until Windows decided to do maintenance, or until an update required a restart, or until the power flickered. Then, back to square one. The server wasn’t sleeping, but its service was fainting. This was silent work gone wrong: the system quietly dying, not quietly living.

The conflict here is interesting. On one hand, we want full automation, elegance, “set and forget”. On the other, Windows—with its design legacy as a desktop OS—always leaves a backdoor for human interaction. Security vs. Convenience. Automation vs. Session Context. We’re trying to force Windows to be a graceful server, while its soul remains that of a PC waiting for input from a mouse and keyboard.

The solution smells of social engineering. Not fighting Windows architecture, but working around its breath. First, we admit that some things really do need a session. They need a user context. So, create a dedicated user, let’s call it “runner”. This user never logs in physically, but we give it the rights to “log on as a service” and “log on as a batch job”. That’s like granting it citizenship in the world of session 0.

Second, about those finicky console applications. We create a simple batch file. Nothing fancy:

@echo off
cd "C:\Program Files\ngrok"
start /B ngrok.exe http 80

Save it as `start_tunnel.bat`. Then, the secret weapon: Task Scheduler. Create a new task. Trigger: “At startup”. Action: run the batch file. But here comes the sacred part: in the General tab, check “Run whether user is logged on or not”. And enter the credentials of that “runner” user. Then, in the Settings tab, make sure “Run task as soon as possible after a scheduled start is missed” is checked. This is the guarantee: after any reboot, this task will rise.

But wait. There’s still a trap. “Start /B” launches the process as a child of the batch file. When the batch file ends, its child can be orphaned and killed. A stupid yet genius solution? Use another application whose only job is to watch. A small “watcher”. Or, structure the batch file to trap itself in an endless loop:

:loop
ngrok http 80
timeout /t 10
goto loop

If the tunnel crashes, it restarts in 10 seconds. This is not elegant. It’s like patching a flat tire with chewing gum. But it works. And in the silent work of systems, “works” is often more noble than “elegant”.

Then there's the third layer: dependency. The web service (Apache, Nginx) must run before the tunnel tries to burst out. So in Task Scheduler, we set a delay. Run the web service task first, wait 30 seconds, then run the tunnel task. This is primitive orchestration. A symphony played with messy batch code, not with expensive monitoring tools.

After everything is set up, the test is the quietest moment: a cold reboot. Power down the virtual machine. Wait. Power on. Do not log in. Then, from a phone on a different network, access the public domain. And… the homepage loads. Slowly, perhaps. But it loads. No one sees the boot process. No one sees the Task Scheduler performing its ritual. No one sees the batch file spinning in its loop. All there is, is a user getting a web page, as they should. They don’t know—and don’t need to know—that behind the screen, Windows is breathing laboriously in an invisible session, controlled by scripts that are honest about their own clumsiness.

There's a philosophical lesson here, between the lines of bat code and Task Scheduler checkboxes. True silent work is often born from an acknowledgment of limitations, not from an illusion of total control. We want everything to be perfectly automated and isolated, but the reality of Windows (and perhaps the reality of anything) is about context, dependency, and sequence. Enforcing perfection only leads to silent failure. Accepting the complexity, then crafting solutions that acknowledge that complexity—that’s what creates reliability.

We learn to read “alive” differently. Not from the cold “Running” status, but from the evidence of service. A ping that replies is one thing. A served web page is another. The first is a sign of vegetative life. The second is a sign of social life—a system truly interacting with the outside world.

This chapter confirms that the silent work of a system is not about making everything appear active, but about ensuring every layer is truly working; often, the most reliable path is born from solutions that are honest about how Windows and its services breathe.