Why Salieno Core's File Manager Runs as a Separate Process

The File Manager: A Control Panel's Silent Killer#

Every shared hosting control panel includes a file manager. It's the feature customers rely on for uploading WordPress themes, extracting backups, and editing .htaccess files without SSH access. It's also, quietly, the component most likely to destabilize your entire control panel.

The reason is straightforward: file operations are resource-intensive, unpredictable, and long-running. A user uploading a 2 GB backup archive or extracting a zip containing 80,000 small files can pin a CPU core and consume gigabytes of memory for minutes. When the file manager runs inside the same process as the control panel daemon—as it does in most legacy panels—that upload becomes everyone's problem. The dashboard slows, API calls time out, and billing cron jobs stall.

Salieno Core takes a different approach: the file manager runs as a completely separate process, communicating with the main control panel daemon over a local socket.

How the Separation Works#

When a user opens the file manager in Salieno Core's web interface, the control panel daemon spawns (or reuses) a dedicated worker process. This worker handles all file I/O—uploads, downloads, directory listings, archive extraction, permission changes—in its own memory space with its own resource limits.

The main daemon never touches the filesystem directly on behalf of the file manager. It passes the request to the worker, the worker does the heavy lifting, and the result comes back over a Unix domain socket. If the worker crashes, panics, or gets killed by the OOM killer, the main daemon notices immediately and can spawn a fresh one. The dashboard, API, DNS management, and billing integrations keep running without interruption.

This is not a thread pool or a coroutine inside the same binary. It is a genuinely separate process with its own PID, its own memory ceiling, and its own cgroup. You can see it in ps aux, you can limit it with systemd directives, and you can kill it without affecting anything else.

Why This Matters in Practice#

Consider a typical Monday morning on a reseller server. One customer is migrating a site and uploads a 3 GB archive through the file manager. Another customer's WordPress install is trying to auto-update. A third is running a cron job that generates a large PDF export.

In a monolithic panel, all three operations compete for the same process's memory and CPU. The file upload blocks the event loop. The auto-update stalls because the API is slow. The cron job times out and the customer opens a ticket.

With Salieno Core's architecture, the file manager worker absorbs the upload spike in its own isolated process. The main daemon continues handling API requests, serving the dashboard, and processing billing webhooks at normal speed. The other customers never notice the upload is happening.

This separation also makes capacity planning more honest. You can set a hard memory limit of 512 MB on the file manager worker. If a user tries to extract a zip that would exceed that, the operation fails gracefully instead of dragging the entire server into swap. You know exactly how much headroom your control panel has because its resource usage is not entangled with unpredictable file operations.

The Trade-Offs Are Real#

This design is not free. There are genuine costs.

First, inter-process communication adds latency. A directory listing that would be a function call inside a monolithic daemon now requires a socket round-trip. In practice this adds single-digit milliseconds, which is invisible to users but it is not zero.

Second, the file manager worker needs its own lifecycle management. Salieno Core's main daemon has to monitor the worker, restart it on failure, and handle the case where the worker is busy when a new request arrives. This is additional complexity in the codebase that a simpler architecture would avoid.

Third, debugging gets slightly harder. When something goes wrong with a file operation, you are looking at logs from two processes instead of one. The socket protocol between them is a surface area that can have its own bugs.

We think these trade-offs are worth it because the alternative—a single process that handles both lightweight dashboard requests and heavyweight file I/O—leads to exactly the kind of cascading failures that generate support tickets at 2 AM.

What You Can Tune#

If you are running Salieno Core, the file manager worker's resource limits are configurable. The relevant settings live in the [filemanager] section of the config file:

• max_memory_mb — hard cap on the worker's RSS. Default is 512.
• max_upload_size_mb — the largest single file the worker will accept. Default is 2048.
• archive_extract_timeout_seconds — how long an extraction can run before the worker kills it. Default is 300.
• concurrent_operations — how many file operations the worker handles in parallel. Default is 4.

If you are running a server with limited RAM, dropping max_memory_mb to 256 and concurrent_operations to 2 is a reasonable move. The worker will reject operations that would exceed these limits rather than letting them run wild.

The Broader Principle#

The file manager is just one example of a general pattern in Salieno Core's architecture: anything that can run for a long time or consume unpredictable resources gets its own process. The job queue, the backup engine, and the migration tool all follow the same model.

This is not the simplest way to build a control panel. A single-process monolith is easier to write, easier to deploy, and easier to reason about when everything is working fine. But shared hosting is not an environment where everything works fine. It is an environment where one customer's bad day should not become every customer's bad day.

Isolating the file manager is a small architectural decision that pays for itself the first time someone uploads a massive archive on a busy server and nobody else notices.