Deploy a Node.js App on Discloud with Environment Variables and Persistent Storage

Problem and takeaway

Discloud runs containerized apps behind a public URL with a web control panel. The useful pattern is to treat the panel as the source of truth for runtime configuration: inject secrets and config via environment variables at deploy time, and mount persistent storage for any path that must survive restarts and redeploys. The default filesystem is ephemeral, so writes outside a mount are lost.

Desired outcome

A Node.js application reachable at a Discloud public URL, started automatically on crash, with environment variables injected at runtime and logs viewable from the control panel. Optional persistent storage is attached for files that must survive redeploys.

Prerequisites

• Active Discloud account and access to the web control panel.
• Application source ready for Node.js execution, with a defined start command such as node index.js.
• Knowledge of the chosen plan limits for CPU, RAM and disk. Containers are enforced to those caps.
• List of configuration values to pass as environment variables, separated into non-secrets for validation and secrets for runtime use.

Deploy procedure via control panel

Create app and select runtime

In the panel create a new app. Choose Node.js as the runtime. The panel provisions a container and assigns a public hostname. Do not hardcode a host or port in code; Discloud provides the port via environment.

Start command and environment variables

Set the start command exactly as the process to run, for example node index.js. The command is executed as the app user inside the container.

Add environment variables in the panel’s variables section. Typical entries are NODE_ENV=production and any app-specific config such as API_BASE_URL. Secrets should be added here rather than in source code.

Risk: logging a secret variable will expose it in panel logs. Validate configuration by logging a non-secret variable at startup, for example the value of NODE_ENV, and compare it with the value shown in the panel.

Optional persistent storage

If the app writes uploads, caches or databases to disk, attach persistent storage in the panel and mount it to a path used by the app, for example /data. The mount persists across redeploys and restarts. The default filesystem does not persist.

Configure the application to read and write only under the mounted path. Writing to the working directory will be lost on redeploy or restart.

Deploy and initial start

Trigger a deploy from the panel. The panel builds the container image from the provided source and starts the process with the configured environment and mounts. Automatic restart on crash is enabled by default.

Expected checks

• Build completes without errors in the panel activity log.
• Application logs show the process started and is listening on the assigned port. Inspect logs in the control panel for a start confirmation and listening message.
• Request the public URL from a separate client to confirm the application responds as expected.
• Resource usage stays within plan limits. Sustained high RAM can cause the process to be killed and the app to restart repeatedly.

Verification steps: compare runtime environment variables shown in the panel with expected values via the non-secret startup log; request the public URL to confirm response; review resource graphs for sustained spikes.

Recovery and limitations

Restart the app from the panel if it becomes unresponsive. Redeploy after correcting code or environment variables; changes to variables require a new deploy to take effect.

Review logs for startup errors or out-of-memory signals. If file writes fail, verify the persistent storage mount is attached to the correct path and the app has write permission inside the container.

If a mount appears corrupted, remove and re-add the persistent storage mount from the panel, then redeploy. Data on the removed volume may be lost, so confirm backup needs before removal.

Limitations: containers have enforced resource caps. Free tier apps may be subject to inactivity sleep or throttling, affecting availability and startup latency. The ephemeral filesystem means any file written outside a mount is lost on redeploy or restart.