Managing Backend Processes & Logs | B A C Documentation

Understand how to start, stop, or restart processes and read server console logs.

Your applications are isolated within secure sandboxes on our cluster node architecture. You have full process control over starting, stopping, restarting, and inspecting logs directly from the control panel in the console dashboard.

Node Action Commands

Each application details page has a top action control bar containing the following commands:

Start Node

Spins up the application process and binds it to the designated port. Once active, the ingress gateway starts routing public domain requests to your application container instantly.

Status changes to Running

Stop Node

Gracefully terminates the app instance. The process is taken offline, releasing port bindings. Visitors will receive a 503 screen. Stopped apps consume 0 billing credits.

Status changes to Stopped

Restart Node

Performs a quick stop-and-start cycle. This is the fastest way to clear runtime memory leaks, force cache updates, or apply newly saved .env environmental variables.

Hot swap cycle (1-3s)

Reading Application Logs

Our process monitor splits application output logs into two distinct streams to help you debug errors faster:

stdout.log Standard Output

[INFO] Database connected successfully.

[HTTP] GET /home - 200 OK (12ms)

[HTTP] POST /profile/update - 200 OK (28ms)

[LOG] Cron task executed successfully.

Stores successful connections, HTTP routing transactions, and manual console.log() statements.

stderr.log Errors

MongoServerError: authentication failed

at connection.js:125:12

ReferenceError: activeUser is not defined

at dashboard.js:52:19

Stores runtime exceptions, script crash trace stacks, unhandled promise rejections, and server load warnings.

Process Stabilization Cooldown: Rapidly toggling process states (e.g. clicking start/stop repeatedly within a few seconds) triggers network safety blocks. Please wait at least 5-10 seconds between commands to allow the server process to fully bind ports and register gateway routes.

Linux Systemd Container Migration

To provide enterprise-grade reliability, isolated security environments, and precise hardware scaling, our hosting infrastructure is migrating to **Linux Systemd Containers**. Every hosted client website executes as an independent, sandboxed service daemon managed directly by the Linux kernel.

Strict Policy: Mandatory Entrypoint File To enable reliable startup commands on Linux, a **Runtime Entry File (e.g., `app.js` or `server.js`) is strictly mandatory** during application registration.

Your repository must contain this file at the specified path.
Immediately after cloning the repository, the platform validates file existence on the host disk.
If the file is missing, the deployment will immediately be aborted, the directory cleaned up, and a validation alert displayed to prevent dead services.

Hardware Resource Allocation by Plan

Hardware resources are automatically allocated and enforced on the systemd service layer (utilizing CGroups v2 kernel resource controllers) based on your active billing subscription plan:

Subscription Plan	Memory Limit (RAM)	CPU Allocation	Max Processes/Threads
Starter Cloud	256 MB Max	10% of 1 Core	20 max
Professional Cloud	1024 MB (1 GB) Max	50% of 1 Core	50 max
Enterprise VPS Cluster	4096 MB (4 GB) Max	200% (2 Dedicated Cores)	150 max

Automated Limit Adjustments: When you recharge or upgrade your hosting plan in your billing console, all active hosted applications are dynamically reconfigured on the host kernel level in real-time, instantly unlocking your upgraded hardware capacity without requiring service downtime.